Como fazer um login em ASP sem banco de dados

Buenas povo!

Aqui vai um exemplo prático de como fazer um sistema de login simples em ASP[bb] , com dois níveis de usuários (e apenas dois usuários) mas sem utilizar Banco de Dados[bb]

Vamos iniciar fazendo o formulário de login, que ficará no arquivo default.asp, e será assim:

 

<form action="login.asp?a=login" method="post" name="flogin" id="flogin">
<p>Usuário
<input type="text" name="usuario" id="usuario">
</p>
<p>Senha
<input type="text" name="senha" id="senha">
</p>
<input type="submit" name="Login" id="Login" value="Login">
</form>
<%
response.write session("mensagem")
session("mensagem") = ""
%>

 

 

Perceba que a página do formulário imprime a sessão "mensagem", logo você vai entender o motivo. Com o formulário criado, precisamos de uma página que vá:

  1. Receber os dados do formulário
  2. Verificar o usuário e a senha
  3. Criar os cookies ou sessões para autenticar o usuário

A página que fará isso se chamará login.asp, e o código dela:

<%
if request.querystring("a") = "login" then
    dim user
    dim senha
    user = request.form("usuario")
    senha = request.form("senha")
    ´Verifica se é o administrador
    if user = "andafter" then
        if senha = "senhaaqui" then
            ´ Se usuário e senha conferem cria as sessões e redireciona para a página logado.asp
            session("usuarioOD") = "andafter"
            session("nivelOD") = 10
            response.redirect "logado.asp"
        else
            ´ Se a senha não conferir manda devolta para o formulário, com a sessão mensagem informando erro no usuário ou senha
            session("mensagem") = "Usuário ou senha não encontrados"
            response.redirect "default.asp"
        end if
    end if
    if user = "odesenvolvedor" then
        if senha = "blabla" then
            session("usuarioOD") = "odesenvolvedor"
            session("nivelOD") = 5
            response.redirect "logado.asp"
        else
            session("mensagem") = "Usuário ou senha não encontrados"
            response.redirect "default.asp"
        end if
    end if
    ´Se não veio com ação nenhuma envia para o formulário
    session("mensagem") = "Usuário ou senha não encontrados"
    response.redirect "default.asp"
end if
%>

Agora o usuário já está "logado" e o que falta é impedir o acesso as páginas restritas para quem não estiver logado. Vamos fazer isso verificando a existência da session "nivelOD".

Como essa verificação é necessária em todas as páginas, vamos criar um arquivo chamado seguro.asp que fará a verificação, depois usando include vocêd eve adicionar esse arquivo em todas as páginas restritas do site.

Código do seguro.asp:

<%
if session("nivelOD") = "" then
    session("mensagem") = "Você não está autorizado a acessar esta página."
    response.redirect "default.asp"
end if
%>

Pronto, os usuários que não estiverem logados serão redirecionados para a default.asp, tudo o que você precisa fazer é dar um include da página seguro.asp no início de todas as página protegidas.

Fácil, não?

Se tiverem dúvidas perguntem pro Chris Benseler, críticas e sugestões utilizem os comentários.

Criando um auto-completar (ajax) com PHP e MYSQL

Escrevi esse texto acho que um ano atrás, para um outro site (acabou não dando em nada). Estou reeditando o mesmo 🙂

Vamos ver como fazer o básico para um auto-completar de um input (parecido com o Google Suggest). No nosso caso, vamos procurar por usuários em uma tabela de um banco de dados. Para isso, utilizarei PHP[bb] no lado do servidor. Mas, a linguagem do lado do servidor não é o que realmente importa. Uma funcionalidade que utiliza a metodologia o modelo ajax[bb] deve ser: um cliente javascript acessando um serviço que está no servidor (tanto faz a tecnologia).

No nosso caso, criei uma página PHP (name.php) que:

  • recebe um parâmetro para ser utilizado como filtro na nossa consulta: $name = $_GET["name"];
  • conecta ao banco de dados (no caso, utilizei o MySQL), acessando uma base que contenha uma tabela pm_users (essa tabela tem duas colunas, id e fullName);
  • efetua uma consulta à tabela utilizando $name como filtro na busca pelo campo fullName;
  • monta um array com os registros que satisfazem a busca;
  • retorna esse array no formato JSON (http://json.org/). JSON é um tipo de formato de troca de dados amplamente utilizado na web hoje em dia (tem vantagens e desvantagens com relação ao XML. Em um post futuro falo a respeito de cada um. Por hora, pode-se achar na web bons textos a respeito). Para transformar o array no formato JSON, utilizei uma classe do Zend Framework (http://framework.zend.com/).

Feito o nosso serviço no lado do servidor, vamos nos preocupar agora com a apresentação: criei uma página simples, que contém um formulário com um label e um campo input. E ainda uma área (div), a qual será usada para mostrar os resultados do auto-completar.

Depois, foi criada a formatação CSS. O mais importante no CSS é ver que a div#usersList tem sua posição definida como absoluta, e não está visível quando se entra na página.
Ela só ficará visível quando o usuário estiver digitando na caixa de texto e retornarem resultados.

Agora, temos toda a parte de layout pronta. Falta ligarmos isso com o serviço.
Como faremos? Há inúmeras formas.
A grande maioria das pessoas que utiliza PHP no lado do servidor, ou usa algum frameworks como o Sajax e o Xajax para criar a chamada às funções automaticamente, ou cria arquivos PHP que geram arquivos XML e no lado do cliente, criam na mão javascript para ler e tratar esse XML.
Eu quis, nesse nosso exemplo, dar uma outra forma a vocês de como fazer; na página 1, fiz uma página em PHP que retorna dados no formato JSON. Se eu fiz isso lá, no cliente vou ter que ler os dados também no formato JSON.

Antes de chegar lá, vamos ver como fazer para chamar o serviço criado.

  • um listener foi criado no onload do documento: sempre que o evento onkeyup for disparado na nossa caixa de texto, faremos a requisição no servidor;
  • caso o campo de texto não tenha pelo menos 3 caracteres, garantimos que a lista de resultados seja escondida e saímos da função (esperando que tenhamos 3 caracteres pelo menos);
  • se tiver pelo menos esses três, caracteres, definimos a URL do nosso serviço (no caso, a página PHP name.php) e os parâmetros a serem passados na requisição (no caso, o parâmetro name com o valor a ser usado para filtrar); Obs.: no caso, passamos um parâmetro "rnd=" + Math.round()*4 , isso é necessário para evitar cache na requisição, problema comumente encontrado nos browsers IE6-;
  • então, usamos o método Request do objeto Ajax da biblioteca Prototype (http://prototype.js). Note que esse método é uma espécie de wrapper para a criação do (objeto) XMLHttpRequest. Se você, usuário, quiser, pode continuar com sua implementação na mão do XMLHttpRequest. O impacto é mínimo. Segue link da documentação da API, dessa classe utilizada: http://www.prototypejs.org/api/ajax;
  • em caso de sucesso na requisição, a função de callback onSuccess é chamada, passando transport como parâmetro; transport possui o conteúdo do que foi retornado pelo request. No nosso caso, lembram-se dos dados no formato JSON? Por isso que utilizamos o método evalJSON(boolean) para transformar esses dados em formato compreensível pelo javascript. Obs.: evalJSON(boolean) é um método da Prototype. Se você tiver implementado o XMLHttpRequest, deve fazer a conversão utilizando uma biblioteca adequada. Uma boa procurada no Google lhe trará ótimos resultados a respeito.
  • uma vez com os dados transformados num formato compreensível pelo javascript (no caso, um array), só o que nos é necessário é percorrer esse array, sabendo que cada item do array possui um array de duas posições, onde a primeira é o id e a segunda o nome do usuário (olha só aí o porque o JSON é um belo formato de troca de dados: os dados que vieram do SELECT lá no PHP seguem a mesma ordem agora no javascript; não é preciso criar um XML, usar um DTD, percorrer nós, ver atributos, etc…). Voltando ao nosso array, ao percorrê-lo, criamos um elemento do tipo a para cada registro, e vamos definindo seus atributos (href, title, innerHTML…) e adicionando (appendChild) à lista, formando assim o nosso auto-completar

Pessoal, no final teremos uma página (ok, layout está bem simples, mas o propósito é mostrar a funcionalidade) onde o usuário vai digitando num campo input e através de uma rotina em PHP vão sendo feitas consultas no banco de dados, com filtro de usuários

Os arquivos estão disponíveis para

download

. Podem mexer, utilizar onde quiserem, modificar.

Google Chart

No post sobre estatísticas de uso de browser que fiz semana passada, usei o serviço de gráficos do Google.

O Google Chart (http://code.google.com/apis/chart/) é um serviço free para que você, desenvolvedor, possa embarcar no seu site, blog, whatever, um gráfico sem precisar de uma biblioteca server-side que faça isso – no final do artigo vamos considerar alguns pontos a respeito.



O uso do Google Chart é bem simples: você coloca na sua tag img do html o caminho da imagem que o serviço gera como gráfico (não é necessário importar nenhuma biblioteca javascript, nada de requisições assíncronas, etc…).

O serviço disponibiliza uma grande variedade de gráficos, desde os mais simples (de linhas), até os mais complexos (tipo radar) passando pelos muito utilizados gráficos de pizza.

Sendo que há, também, uma boa quantidade de opções de customizações que vão além do tipo do gráfico: dimensões, cores, visão 2D ou 3D, tipos de preenchimentos de barras, etc…

Um exemplo: como montar um gráfico como os que estão no artigo referenciado ali em cima?

O formato da url que deve ser usada para gerar o gráfico é o seguinte:

http://chart.apis.google.com/chart?cht=[tipo de gráfico]&chd=[valores]&chs=[dimensões]&chl=[rótulos]



O tipo de gráfico a ser usado é o de pizza 3D, logo [tipo de gráfico]=p3

Os valores, são representados por uma lista separada por vírgula, precedida pelo tipo de encoding a ser utilizado (ver a referência aqui). Pegando os dados de Abril/2008, são eles:

IE7: 19,4%

IE6: 61,2%

Firefox: 14,4%

Outros: 4%

Logo, [valores] será igual a t:38.6,39.8,18.8,2.8
Nota: t é o tipo de encoding. Na documentação da API, existe uma explicação completa sobre ele e outros tipos

Se não forem definidades dimensões, são usadas as padrão do sistema. No caso, setei [dimensões] como um par de valores igual a 250×100

Os rótulos (conhecidos popularmente entre programadores como labels) são definidos por uma lista que utiliza o caracter | (pipe) como divisor.

Com isso, chegamos a url http://chart.apis.google.com/chart?cht=p3&chd=t:38.6,39.8,18.8,2.8&chs=250×100&chl=IE7|IE6|Firefox|Outros

Colocando em uma tag img, seria o equivalente a <img src="http://chart.apis.google.com/chart?cht=p3&chd=t:38.6,39.8,18.8,2.8&chs=250×100&chl=IE7|IE6|Firefox|Outros" alt="Acessos por Browser / 2008" />



Vale a pena dar uma explorada nessa API, ver o que dá pra fazer (existem muitas outras customizações possíveis) e até onde é possível ir 🙂



E, como havia dito lá em cima, vale a pena ponderar rapidamente um assunto: quando usar o Google Chart e quando usar uma biblioteca server-side?

Vou dar a minha opinião: o Google Chart é bom por ser uma aplicação free – apesar de que pode-se achar em PHP e Java, por exemplo, uma infinidade de bibliotecas free (já em ASP eu não conheço do assunto) -, ser de rápido aprendizado, ser desenvolvida por uma empresa que é sinônimo de excelência em serviços web. E ajuda muito quando você não tem uma linguagem de server-side disponível para ser utilizada (por exemplo, está escrevendo um artigo em um sistema de terceiros ao qual você não tem acesso às funcionalidades do mesmo).

Por outro lado, eu ainda sou favorável a utilizar bibliotecas embarcadas na sua aplicação, por motivos óbvios: não fica dependente de um serviço que está fora do seu servidor sem necessidade (o mesmo não se aplica ao Google Docs, né?), tem certeza que o serviço estará disponível sempre que seu site estiver no ar, pode customizar o serviço (se a licensa da biblioteca lhe permitir) se necessário….
Mas, essa é uma discussão que deve ficar para um artigo mais específico, só sobre "usar ou não webservices e APIs de terceiros?".

Por enquanto, é isso 😉

IE6, 7 e Firefox nos últimos anos

Fiz um levantamento usando as estatísticas de um site no qual trabalho, pegando os dados de acesso dos últimos anos. Só por curiosidade mesmo, para ver a evolução no uso dos browsers.

Em Abril de 2006:

Browsers - 2006

IE7: 0,1%
IE6: 84,5%
Firefox: 11,5%
Outros: 5.4%

 

Em Abril de 2007:

Browsers - 2007

IE7: 19,4%
IE6: 61,2%
Firefox: 14,4%
Outros: 4%

 

Em Abril de 2008:

Browsers - 2008

IE7: 38,6%
IE6: 39,8%
Firefox: 18,8%
Outros: 2.8%

 

Nota-se que o Firefox vem tendo um crescimento gradativo – 3% no primeiro período, 4% no segundo. E a plataforma Windows, usando ou o IE6 ou 7, ainda manda no mercado.

Lembrando que isso é a análise de um site apenas, no Brasil. Não deve corresponder fielmente às estatísticas globais (na Europa, pelo que sei, o uso dos browsers IE vem caindo). Serve apenas para termos uma idéia da participação de cada navegador.

Netvibes ou iGoogle?

De todos essas Start Pages (páginas de início, onde você, usuário, pode customizar a mesma, agregar feeds, usar widgets, etc…), as que mais caíram no gosto do público aqui no Brasil, pelo que posso ver, são o Netvibes e o iGoogle.

Basicamente, eles tem as mesmas funcionalidades, o mesmo conceito.

Aí que pinta a dúvida: qual deles usar?



Não vou esconder que há tempos tenho predileção pelo Netvibes (o que parece ser estranho, uma vez que pessoalmente sou um fã do Google e seus serviços). E eis os motivos:

– maior quantidade de widgets disponíveis

– maior flexibilidade em termos de customizações

– carregamento mais leve da página

– aparentemente, maior rapidez nas atualizações (imagino eu que isso ocorra não por o Google deixar de lado o iGoogle, mas sim por o Netvibes se focar exclusivamente no desenvolvimento da sua start page)

– preguiça de migrar tudo (RSSs, widgets, etc…) para outro serviço



Sei, também, que o Google tem uma forte estrutura para fazer sua start page crescer muito, principalmente na área de widgets (que o Google chama da gadgets) usando os seus serviços (Docs, Maps, Calendar, etc…) – sem falar no know-how deles em inovações.



E você, o que acha de um e de outro? Qual sua preferência? Ou tem alguma outra start page com ótimos benefícios?



PS: @biab (usuária de Netvibes) e @rulico (do iGoogle) poderiam dar suas opiniões 😉

Vale a pena ler…  http://www.mitchelaneous.com/2007/10/01/netvibes-vs-igoogle/