Clipper On Line • Ver Tópico - Mini tutorial mod_harbour
Mudar para estilo Clássico
Aqui você poderá oferecer suas Contribuições, Dicas e Tutoriais (Texto ou Vídeo) que sejam de interesse de todos.
Postar uma resposta

Mini tutorial mod_harbour

30 Ago 2020 23:23

Dando uma olhada nas tendências para o futuro:





Ironicamente, dos 3 primeiros, o que tem tido uma aceitação maior (Vue.js) é justamente o que é desenvolvido por uma pessoa, não por uma empresa. Detalhe: essa pessoa trabalhou para o Google, saiu há uns anos, e agora recebe $$$ para continuar desenvolvendo.

Mini tutorial mod_harbour

31 Ago 2020 00:39

Mais um pequeno passo: a autenticação. Só o básico.

Até agora eu deixei o arquivo do grid/form com a extensão HTML para mostrar que é possível separar o HTML do código Harbour.
Isso é bom porque abre uma possibilidade para que você possa :

(1) tornar o seu código mais claro e fácil de manter.
(2) firmar uma parceria com um profissional da área de design ou até mesmo contratar alguém para tratar da parte visual.

*
Só um pequeno parênteses :
*
Hoje em dia tem muito curso técnico profissionalizante que forma jovens com esse conhecimento.
Muitas escolas estaduais ou institutos federais incluem um curso de formação que pode ser de até 3 anos, e com estágio supervisionado.
É mão-de-obra barata, embora não seja experiente.
Se você for seguir esse caminho, procure saber se o jovem gosta mesmo da área, pois muitos foram direcionados para a informática
muito jovens e por insistência dos pais, que vêem essa área como de fácil empregabilidade e retorno financeiro.
Geralmente os cursos profissionalizantes dos institutos federais e escolas profissionalizantes são bem genéricos, o aluno aprende redes,
hardware, programação e um pouco de design. Durante uma entrevista de seleção, você pode perguntar qual a área que ele mais se identifica.
Se você é empresário, pense nessa parceria.
Você não vai precisar ser um expert em Javascript, apenas precisa entender um pouco como o modharbour interage com o html (ajax + json).
*
Fim do parênteses.
*

O nosso projeto vai continuar nessa mesma linha, mas a autenticação exige que a página onde fica o HTML tenha que realizar um tipo de processamento
no servidor:

(1) A página vai verificar se o usuário logado tem direitos de acesso.
(2) Se o usuário não tiver manda para uma página de login
(3) Se tiver exibe o conteúdo

Pelo que observei até agora, isso pode ser feito apenas através de cookies. Você já deve ter ouvido falar das sessões, principalmente se você já
desenvolveu rotinas de autenticação em PHP, mas as sessões são, na verdade, cookies. O seu navegador só reconhece cookies, a implementação de sessões
é feita só no lado do servidor.

Conclusão: vou renomear index.html para index.prg antes de mais nada.
Nós já vimos isso no início. Basta fazer assim :

Código:
function main

TEMPLATE

   Sua página HTML

ENDTEXT

return nil



O código de autenticação vai ficar no início.

Código:
function main

Aqui você verifica...

TEMPLATE

   Sua página HTML

ENDTEXT

return nil



Se você já sabe o que é um cookie pode pular essa parte, se você não sabe, vou tentar explicar de uma forma bem simples.

Um cookie é simplesmente um arquivo que o seu aplicativo envia, através do servidor, para o seu navegador. Esse arquivo é um
arquivo simples, em modo texto, que contem um conjunto de pares do tipo chave=valor.

Por exemplo, você começa a pesquisar sobre "Notebook" e de repente, como se fosse uma mágica, você passa a
receber anúncios desse tipo de produto. Essa propaganda direcionada pode durar vários dias e é feita através de cookies.

https://support.google.com/chrome/answer/95647

Trabalhar com cookies exige um cuidado especial pois eles podem ser lidos por terceiros e podem conter informações valiosas.
Mas vamos deixar as coisas simples e abstrair essa questão.

P. Como o modharbour cria os cookies ?
R. Na prática o modharbour apenas envia comandos para o servidor. A tecnologia de criação/envio/recebimento de cookies é feita pelo servidor http.
O processo é o mesmo para PHP, Javascript, Python, ASP, Java, etc. Isso faz parte do protocolo HTTP, não é de uma linguagem específica, felizmente.

P. Como faço para criar um cookie ?
R. Envie uma ordem para o servidor http através do comando setcookie.

P. Como faço para ler o cookie ?
R. Use o comando getcookie

Antes de prosseguirmos vamos esquecer um pouco do index.html (ou index.prg) e
vamos começar com calma.
Crie o arquivo protegido.prg com o seguinte conteúdo :
Código:

function main

   local hCookie := GetCookies()

   ?? "Cookies : " , hb_valtoexp( hCookie )

return nil


Acesse esse arquivo pelo navegador.
O conteúdo exibido será :
Código:
Cookies : {""=>""}


A função GetCookies() lê todos os cookies do servidor e os exibe em forma de hash. Hashs são ideais porque também são chave -> valor.

Agora crie o arquivo autentica.prg com o seguinte conteúdo :
Código:

function main

setCookie( "login" , "joao" )

?? "Criando um cookie"

return nil


Agora, execute de novo o protegido.prg
Veja que temos um valor agora:
Código:
Cookies : {"login"=>"joao"}


Basicamente é isso.

Como pensar em um sistema de login ?

1. Quando o usuário fizer o login, salve um cookie com o seu ID, por exemplo. Use a função setcookie().

2. Todas as páginas que você quer proteger devem ter, no seu início, uma função GetCookie(). Você procurar o
ID, gravado anteriormente, com o GetCookie().

Você pode criar rotinas de verificação e liberar alguns recursos da página de acordo com o ID do usuário, por exemplo. Apenas uma ideia.

Uma curiosidade : para ver o cookie desse exemplo gravado no navegador Chrome digite na barra de endereços : chrome://settings/cookies/detail?site=localhost

2020-08-28_231007.png


Para excluir o cookie faça assim :
Código:
function main

setCookie( "login" , NIL , 0 )

?? "Excluindo um cookie"

return nil


O terceiro parâmetro é um valor, em segundos, que determina o tempo de vida do cookie. Se você colocar zero você vai "criar" um cookie com tempo
de vida de zero segundos.
Anexos
autentica.zip
(404 Bytes) Baixado 17 vezes

Mini tutorial mod_harbour

01 Set 2020 01:03

Agora vamos concluir o login.

Eu baixei um formulário de login do site do bootstrap. Lá no site deles tem uma página com vários modelos básicos para
que a gente não comece do zero.

https://getbootstrap.com/docs/4.5/examples/

O template deles de login não vai funcionar com o nosso exemplo. Veja porque :

Código:

<form class="form-signin"> <---- Aqui você tem que colocar o método e o endereço de destino

...

... Logo mais, os campos que vão ser enviados não possuem a tag "name", apenas a tag "id"
 
  <div class="form-label-group">
    <input type="email" id="inputEmail" class="form-control" placeholder="Email address" required autofocus>
    <label for="inputEmail">Email address</label>
  </div>

 


Nunca se esqueça: se você for usar um formulário, não esqueça de criar a tag "name" para cada campo que você quer enviar.

1. Sem a tag "name" o campo não será incluído no método serialize() que nós vimos;
2. Se você for usar o método tradicional, o botão "submit" só vai enviar os campos com a tag "name" definida.

Engraçado é que cada elemento do DOM pode ser referenciado através da tag "id", mas para enviar o formulário usando
o método tradicional (ou via serialize), a tag "name" precisa estar definida. Acho que por razões históricas.
A tag name é a mais antiga, data das primeiras versões do HTML.
Por isso é muito comum vc ver nos formulários a tag "name" e a tag "id" contendo o mesmo valor.

No nosso caso ficou assim no formulário :
Código:
<form class="form-signin" action="autentica.prg" method="post">


E assim para cada campo dele,
Código:
                                                    **Precisa do name, senão não vai enviar os dados
<input type="email" value="x@x.com" id="inputEmail" name="inputEmail" class="form-control" placeholder="Email address" required autofocus>


No nosso caso a tag ID não é obrigatória, mas ela é bastante usada por bibliotecas e frameworks. Ela é como se fosse um código único
para que o elemento possa ser acessado diretamente dentro da árvore DOM. Você verá muitos formulários com as duas tags preenchidas com
o mesmo valor para ambas (uma redundância necessária na maioria dos casos)

O processo todo, basicamente é :
(1) Na página login.html o usuário informa seu e-mail (login) e a senha
(2) A página autentica.prg recebe os dados via post
(3) Se estiver correto direciona para protegido.prg
(4) Se estiver errado direciona para login.html

P. Mas, como vou fazer para redirecionar ?
R. Use a tag <META HTTP-EQUIV=refresh CONTENT="0;URL=protegido.prg">

Essa TAG é enviada para o navegador que faz um "refresh" (redireciona) para o conteúdo definido em CONTENT.
O CONTENT tem um número informando quantos segundos deve aguardar antes de redirecionar. É aquelas páginas que
preferem exibir uma mensagem antes de redirecionar. Tipo: "Você está sendo redirecionado para outro domínio", ou uma
página temporária com opções, tipo o Fórum "Clipper On Line" após você enviar uma postagem.

O código do autentica.prg fica mais ou menos assim :
Código:
function main

local hPost := AP_PostPairs()

if hPost["inputEmail"] == "x@x.com" .and. hPost["inputPassword"] == "123"
    setCookie( "login" , hPost["inputEmail"] )
    ? '<META HTTP-EQUIV=refresh CONTENT="0;URL=protegido.prg">'
else
    setCookie( "login" , NIL , 0 )
    ? '<META HTTP-EQUIV=refresh CONTENT="0;URL=login.html">'
endif

// Importante!
// Qualquer comando aqui definido será executado!!
// Um redirecionamento não interrompe o script!
// Ele apenas envia uma mensagem para o navegador via HTTP, mas essas linhas aqui serão executadas.

return nil


A observação que vou fazer parece boba: mas você não deve confundir o redirecionamento feito acima com um desvio no fluxo do seu programa.
Redirecionamento não equivale a um comando RETURN.

Nesse caso aqui não é problema, porque nada é feito após o bloco IF.
Mas existem casos onde o redirecionamento é usado.
Certa vez, quando estava começando, usei o redirecionamento pensando que o restante do script não seria
executado. Era um script PHP que gerava um boleto. No início do script tinha uma críticas, tipo "e-mail
está incorreto" ou "nome faltando", essas coisas...
Enfim, eu usei o redirecionamento para voltar para a página anterior mas não interrompi o script, apenas redirecionei.
Daí a rotina prosseguia e sempre gerava um número sequencial a mais quando o usuário errava algo.
Felizmente não teve consequências graves, apenas uma quebra na sequência. O erro foi descoberto logo no início e a pessoa
que me contratou era gente boa.

A programação web tem essa vantagem: os seus princípios podem ser aplicados a qualquer linguagem.

Nota final : Existem outra forma de redirecionamento, ele se processa diretamente no servidor. Não encontrei como fazer no mod-harbour, mas deve ter. Optei por colocar o formato ? '<META HTTP-EQUIV=refresh CONTENT="0;URL=protegido.prg">'

Nota final-2 : O zip contém apenas o formulário de login. Tive que zipar para o servidor aceitar, por questões de segurança.
Anexos
login.zip
(973 Bytes) Baixado 12 vezes

Mini tutorial mod_harbour

02 Set 2020 03:08

* Agora finalizo o nosso projeto integrando a autenticação com o grid.

Pode ser melhorado, com certeza :

1. Um logout pode ser criado. Essa página deve excluir o cookie do usuário e redirecionar para o formulário de login.
2. O formulário de login pode exibir uma mensagem explicando a causa do erro. Nesse caso ele deve receber algum parâmetro informando que um erro ocorreu. Aí não seria mais login.html, mas login.prg
3. Com certeza essas duas não são as únicas modificações. Com relação aos scripts criados com mod-harbour eles podem ser unificados em uma classe.
4. Do lado cliente um framework pode ser adotado. Um de baixa curva de aprendizado é o Vue.js
5. Um framework que seja especializado em aplicações mobile, como o Ionic 5.

Vou deixar um zip com a versão final. Sem o bootstrap.

ex27 - finalizando.zip
(30.42 KiB) Baixado 24 vezes
Postar uma resposta