Pergunta

Eu sou novo em programação web, vindo de um fundo de desenvolvimento de jogos de vídeo (c ++), e estou realmente começando a sentir a sobrecarga de informações. Há tantas bibliotecas concorrentes que tudo Escolha algo que eles não gostam de alguma outra biblioteca, e construir uma maneira inteiramente nova de fazer a mesma coisa! Estou certo de que há boas razões para isso, e eu não quero reclamar, então eu vou explicar o meu problema.

Para aliviar a minha jornada, eu decidi começar a aprender o Google App Engine + GWT + Java. Eu gosto dele porque ele é uma arquitetura de servidor distribuído fora da caixa, e eu escolhi Java por causa da minha C ++ fundo.

Para começar eu escrevi pouco Twitter-like aplicação porque testa vários aspectos do desenvolvimento web, a saber: REST, JSON análise / criação, comms AJAX, e geração de HTML. Ele não me levar muito tempo para criar um pequeno site que permite que um usuário insira seu nome e senha na página no navegador, enviar os dados através de meu aplicativo, eu entro em seu nome, pegue sua lista de amigos, e emitem -lo de volta para o cliente como JSON, onde eu analisá-lo e exibi-lo.

Pretty coisas simples.

Assim, o próximo passo foi que eu não gostava de enviar a senha que o usuário tenha entrado através da rede como texto simples (obviamente). Isso me fez pensar sobre todas as canalizações eu iria precisar:

  1. usuários autenticar em meu próprio banco de dados, não o Google é. (Password Login / Perdido / Sair)
  2. Digite / saída (pista) uma sessão (logado / desconectado).
  3. armazene dados do usuário no banco de dados do meu Google aplicativo.

Todas as coisas bastante normal que tem sido em torno de sempre. Bem, eu comecei a olhar ao redor para uma biblioteca de autenticação Java e havia tais, bibliotecas monolíticas grandes com enormes curvas de aprendizado, e alguns são velhos ou não em favor mais ... Eu me sinto como um programador total de iniciante tudo de novo! Eu só quero ter uma página de login! :)

Então eu comecei a ler sobre como o encanamento de obras de autenticação, e há uma enorme quantidade de tomar. Aparentemente é bastante comum as pessoas (insegura) rolar seus próprios. Eu prefiro ter uma solução que existe e é sólida.

Portanto, a questão torna-se, o que as pessoas fazem sobre isso? O Twitter suporta HTTP e HTTPS, mas o padrão é HTTP para a sua API REST, faz senhas que das pessoas médios estão voando por aí desprotegida, pronto para ser interceptado por hacks man-on-the-middle?

Eu também olhou para OAuth, que parece excelente, mas ele não tem um caso para apenas um bom e velho "Eu não quero saber ou se importar o que OpenID é". as pessoas não técnicas que eu mostrou OpenID para são como "wha? Eu só quero colocar o meu nome de usuário / senha no".

Como uma nota lateral, alguém teve alguma sorte com Spring.Security no Google App Engine?

De qualquer forma, eu estou ranting. Eu só quero saber o que as pessoas fazem (e não em Python, Rails etc, mas no bom e velho Java). Eu adoraria ter uma página de login, como Digg, mesmo com uma opção de um dia para OpenID:)

Cheers, Shane

Foi útil?

Solução

Eu não posso falar com Spring Security juntamente com o Google App Engine, mas posso dizer algumas coisas sobre ele que podem ser úteis.

Em primeiro lugar, é muito simples de configurar, e eles têm bons tutoriais para começá-lo para cima e indo. Pessoalmente, eu usei a pet-clínica tutorial como um guia para como aplicar segurança primavera para o meu projeto pela primeira vez. Eu era capaz de obtê-lo configuração em questão de uma ou duas horas e teve a segurança básica usando meu banco de dados sobre algumas páginas diferentes. Sua milhagem pode variar, claro, mas pior cenário você tem o seu tutorial de pleno direito você pode picar e prod para ver como ele reage.

Em segundo lugar, a biblioteca é muito configurável. Se você pesquisar através da manual de você vai ter uma boa idéia das coisas que você pode fazer, e eu não tinha problemas retrabalhando as áreas que eu precisava para mudar para o meu projeto. Tenho confiança de que você deve ser capaz de trabalhar aqueles Spring Security e Google App Engine juntos. Em geral I foram satisfeito com previsão da fonte de Primavera e capacidade de interagir com outras bibliotecas.

Finalmente, suportes Spring Security OpenID se isso é algo que você decidir que quer camada. Eu não tenho jogado com esta parcela ainda, mas a partir do tutorial também parece bastante intuitivo. O bom aqui é que você deve ser capaz de acrescentar que após o fato se ele sair que você deveria ter suportado OpenID depois de tudo.

Desejo-lhe a melhor sorte!

Outras dicas

Eu só tropeçou em seu post. Você parecia (passado, uma vez que tem sido um longo tempo) para ser confundido sobre HTTP / HTTPS uso e autenticação. Se você estiver usando HTTP, sua senha não está sendo devolvida ao redor em texto simples. Normalmente, as informações de login é postado via HTTPS. Por esta altura, uma sessão foi estabelecida, que é monitorado através de um grande identificador gerado aleatoriamente em um cookie. O usuário é autenticado no servidor e sua ID é armazenado na sessão (armazenado no servidor) para marcar que eles estão conectados.

A partir daí, o usuário é monitorado através da sessão. Sim, é possível que um man-in-the-middle poderia roubar o cookie e assumir a sua identidade. Este é o caso de 100% dos sites que funcionam através de HTTP, mas é evidente que não é apenas um problema ou você iria ouvir mais sobre ele. Para HTTPS, o cookie de sessão pode ser marcado como seguro, o que significa que só vai ser enviado via HTTPS a partir do browser. No passado, eu descobri que os navegadores se comportam de forma diferente, às vezes compartilhando o mesmo valor para um cookie seguro e não-seguro mesmo nome (que é uma idéia idiota). Sua melhor aposta é usar um cookie seguro chamado separadamente para garantir que o usuário está logado para funções seguras em seu site.

Eu concordo com você que o quadro JAAS é simples terrível. Ele deve ter sido escrito por um bando de lunáticos enlouquecido sem bom senso.

Quanto a usar o Google App Engine - que vai cuidar de toda a autenticação para você. Parece que você não tem escolha a não ser usar as Contas do Google que é uma vergonha. Também é uma pena que eles insistem que você redirecionar a sua página de login, pois isso quebra a forma como um aplicativo GWT funciona. Atualmente estou olhando para gerir as minhas próprias contas, porque eu não quiser que o Google a eles próprios e eu não quero que a experiência desarticulada no meu site.

No entanto, parece impossível de rastrear um usuário sem uma sessão (sessões podem ser apoiadas no GAE, mas estão fortemente desencorajado para promover a escalabilidade em GAE). Sem uma sessão eu literalmente não precisa enviar a senha e autenticar o usuário com todas as solicitações RPC. Google está puxando alguns truques para fazer a getUserPrincipal () método de trabalho através de seus clusters de servidor - e parece que você só tem que a magia se você ir com as Contas do Google.

Talvez eu estou faltando alguma coisa, mas o Google docs apenas roçar sobre este buraco: (

hey lá, se você quiser trabalhar com java você pode querer olhar para WICKET ... isso é um muito arrumado java-estrutura que oferece uma grande quantidade. é componente-orientado e através dos exemplos muito fácil de entender (veja o login-exemplo na página de exemplo estendida ... Eu tenho que correr muito rápido). ele também funciona com outros js-estruturas, mas também oferece a sua própria ajax-implementação. ele também tem um grande mailing-list!

Eu estou tentando fazer elemento security-constraint o mesmo usando o servlet . Na minha básica application / digerir auth sob https está bem.

No dia seguinte, eu também vai tentar implementar outro aplicativo usando Restlet e / ou JAX-RS. Ambos os quadros fornece ganchos de segurança.

entrar / sair (pista) uma sessão (logado / desconectado).

isso pode ser facilmente implementado usando um filtro de servlet (novamente, totalmente suportado pelo GAE)

Como uma nota lateral, alguém teve alguma sorte com Spring.Security no Google App Engine?

Spring Security é suportado

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top