2009-06-16 13 views
22

Soy nuevo en la programación web, proveniente de un fondo de desarrollo de videojuegos (C++), y realmente estoy empezando a sentir una sobrecarga de información. ¡Hay tantas bibliotecas competidoras que eligen algo que no les gusta en alguna otra biblioteca y construyen una forma completamente nueva de hacer lo mismo! Estoy seguro de que hay buenas razones para esto, y no quiero quejarme, así que explicaré mi problema.Inicio de sesión en el sitio web en Java + Google App Engine

Para facilitar mi viaje, he decidido comenzar a aprender Google App Engine + GWT + Java. Me gusta porque es una arquitectura de servidor distribuida lista para usar, y he elegido Java por mi fondo de C++.

Para empezar escribí una pequeña aplicación similar a Twitter porque prueba varios aspectos del desarrollo web, a saber: REST, análisis/creación de JSON, comunicaciones AJAX y generación de HTML. No tardé mucho en crear un pequeño sitio que permite a un usuario ingresar su nombre y contraseña en la página del navegador, enviar los datos a mi aplicación, iniciar sesión en su nombre, tomar su lista de amigos y emitir volver al cliente como JSON, donde lo analizo y lo visualizo.

Cosas bastante simples.

Entonces, el siguiente paso fue que no me gustaba enviar la contraseña que el usuario ingresó a través de la red como texto sin formato (obviamente). Eso me hizo pensar en todas las cañerías que necesitaría:

  1. Autentico usuarios contra mi propia base de datos, no de Google. (Iniciar sesión/Perder contraseña/Cerrar sesión)
  2. Ingresar/salir (rastrear) una sesión (iniciar sesión/cerrar sesión).
  3. Almacenar datos de usuario en la base de datos de mi aplicación Google.

Todas las cosas bastante estándar que han existido por siempre. Bueno, comencé a buscar una biblioteca de autenticación Java y había bibliotecas grandes y monolíticas con enormes curvas de aprendizaje, y algunas ya son viejas o no están a favor ... ¡Me siento como un programador principiante total de nuevo! ¡Solo quiero tener una página de inicio de sesión! :)

Entonces, comencé a leer sobre cómo funciona la fontanería de la autenticación, y hay una gran cantidad para asimilar. Aparentemente, es bastante común que la gente (insegura) haga rodar la suya. Prefiero tomar una solución que existe y es sólida.

Entonces la pregunta es, ¿qué hace la gente al respecto? Twitter es compatible tanto con HTTP como con HTTPS, pero su API REST se configura de manera predeterminada como HTTP, ¿eso significa que las contraseñas de las personas están volando desprotegidas, listas para ser interceptadas por intermediarios intermedios?

También miré a OAuth, que se ve excelente, pero no tiene un caso para un buen viejo "No quiero saber o me importa lo que OpenID es". La gente no técnica a la que le he mostrado que OpenID es como "¿qué? Solo quiero poner mi nombre de usuario/contraseña".

Como nota al margen, ¿alguien ha tenido suerte con Spring.Security en Google App Engine?

De todos modos, estoy despotricando. Solo quiero saber qué hace la gente (no en Python, Rails, etc., sino en Java). Me gustaría tener una página de inicio de sesión como Digg, incluso con una opción de un día para OpenID :)

Saludos, Shane

Respuesta

12

No puedo hablar de la primavera de Seguridad junto con Google App Engine, pero puedo decir algunas cosas sobre él que pueden ser útiles.

En primer lugar, es muy simple de configurar, y tienen buenos tutoriales para ponerlo en marcha. Personalmente, utilicé el pet-clinic tutorial como una guía sobre cómo aplicar la seguridad de primavera a mi proyecto la primera vez. Logré configurarlo en cuestión de una o dos horas y tuve seguridad básica usando mi base de datos en algunas páginas diferentes. Su kilometraje puede variar, por supuesto, pero en el peor de los casos, si tiene su tutorial completo puede presionar y probar para ver cómo reacciona.

En segundo lugar, la biblioteca es muy configurable. Si busca a través del manual obtendrá una buena idea de las cosas que puede hacer, y no tuve problemas para volver a trabajar en las áreas que necesitaba cambiar para mi proyecto. Confío en que debería poder trabajar con Spring Security y Google App Engine juntos. En general, me ha complacido la previsión de la fuente Spring y su capacidad para interactuar con otras bibliotecas.

Finalmente, Spring Security es compatible con OpenID si eso es algo en lo que usted decide que desea capa. Todavía no he jugado con esta parte, pero desde el tutorial también se ve bastante intuitivo. Lo bueno aquí, es que deberías poder agregar eso después del hecho si resulta que deberías haber soportado OpenID después de todo.

¡Le deseo la mejor de las suertes!

+1

Gracias por sus comentarios, voy a cavar más profundo. Una cosa, ¿tengo que tomar todo el marco Spring, o puedo tomar el lado de la seguridad? Es solo que no quiero tener que aprender una gran biblioteca para usar una sola pieza. Si tengo que hacerlo, entonces que así sea, pero me pregunto por adelantado. – Shane

+1

Puede elegir entre las diversas bibliotecas de Spring Framework. Por lo general, juegan bien entre ellos, o con la mayoría de las otras bibliotecas que he visto también. Según entiendo, puede aplicar capas en Spring Security con otros frameworks, y lo hacemos localmente (técnicamente todavía estamos en Acegi, pero lo que sea), y funciona bien. –

0

que estoy tratando de hacer lo mismo usando security-constraint element de servlet. En mi aplicación básica/digest auth bajo https está bien.

Al día siguiente también intentaré implementar otra aplicación utilizando restlet y/o JAX-RS. Ambos marcos proporcionan ganchos de seguridad.

Ingresar/salir (rastrear) una sesión (iniciar sesión/cerrar sesión).

Esto se puede implementar fácilmente utilizando un filtro de servlet (de nuevo, el pleno apoyo de GAE)

Como nota al margen, ¿alguien ha tenido suerte con Spring.Security en Google App Engine?

de seguridad de resorte se apoya

+0

¿Es capaz de proporcionar un ejemplo de este – Shane

+0

de restricciones de seguridad Web.xml sí: mira esto: http: //stackoverflow.com/questions/995035/how-to-define-realms-for-using-by-google-app-engine – dfa

+0

Hola, he comprobado su .xml contra los documentos de Google aquí: http: // code .google.com/appengine/docs/java/config/webxml.html # Security_and_Authentication Noté que dicen: "App Engine no admite roles de seguridad personalizados () o mecanismos de autenticación alternativos () en el descriptor de despliegue. " Está utilizando en su .xml, ¿entonces este trabajo le sirve? Además, ¿solo permite la autenticación de usuario en una cuenta de Google? Porque eso es lo que sucederá si simplemente establece las restricciones de seguridad a través de web.xml. – Shane

1

Hola, si quieres trabajar con java, es posible que desees consultar WICKET ... es un marco de java bastante atractivo que ofrece una gran oferta. Está orientado a los componentes y, a través de los ejemplos, es bastante fácil de entender (vea el ejemplo de inicio de sesión en la página de ejemplo extendida ... Lo ejecuté bastante rápido). también funciona con otros js-frameworks, pero también ofrece su propia implementación de ajax. ¡también tiene una gran lista de correo!

+0

Gracias por la sugerencia. WICKET se ve muy bien, pero también imita una gran parte de la misma funcionalidad de GWT, que originalmente es compatible con Google App Engine. Aún así ... Se ve muy bonito y liviano ... Me pregunto si alguien ha intentado ver si pueden hacer que WICKET y GAE jueguen juntos. – Shane

+0

En realidad, parece que alguien ha intentado obtener Wicket en funcionamiento con GAE, con cierto éxito :) http://stronglytypedblog.blogspot.com/2009/04/wicket-on-google-app-engine.html – Shane

+0

Ah , por el enlace. ¡Pensé que lo había visto en alguna parte, pero no podía recordar! Tal vez te ayude un poco :) – doro

4

Acabo de tropezar con su publicación. Parecía (en tiempo pasado, ya que ha pasado mucho tiempo) confundido sobre el uso y la autenticación de HTTP/HTTPS. Si está utilizando HTTP, su contraseña no se rebotará en texto sin formato. Normalmente, la información de inicio de sesión se PUBLICA a través de HTTPS. En este momento, se ha establecido una sesión, que se rastrea a través de un gran identificador generado aleatoriamente en una cookie. El usuario se autentica en el servidor y su id. Se almacena en la sesión (almacenada en el servidor) para marcar que están iniciados.

A partir de ese momento, el usuario es rastreado a través de la sesión. Sí, es posible que un hombre en el medio pueda secuestrar la cookie y asumir su identidad. Este es el caso para el 100% de los sitios que funcionan a través de HTTP, pero es claro que no es un problema o si quiere saber más al respecto. Para HTTPS, la cookie de sesión se puede marcar como segura, lo que significa que solo se enviará a través de HTTPS desde el navegador.En el pasado, descubrí que los navegadores se comportan de manera diferente, a veces compartiendo el mismo valor para una cookie segura y no segura con el mismo nombre (lo cual es una idea tonta). Su mejor opción es usar una cookie segura por separado para garantizar que el usuario haya iniciado sesión para funciones seguras en su sitio web.

Estoy de acuerdo con usted en que el marco JAAS es horrible. Debe haber sido escrito por un grupo de lunáticos trastornados sin sentido común.

En cuanto al uso de Google App Engine, se encargarán de toda la autenticación por usted. Parece que no tiene más remedio que usar Cuentas de Google, lo cual es una pena. También es una pena que insistan en que se redirija a su página de inicio de sesión porque esto rompe la forma en que funciona una aplicación GWT. Actualmente estoy investigando la administración de mis propias cuentas porque no quiero que google las tenga y no quiero esa experiencia inconexa en mi sitio.

Sin embargo, parece imposible hacer un seguimiento de un usuario sin una sesión (las sesiones se pueden admitir en GAE, pero se desaconseja encarecidamente que promuevan la escalabilidad en GAE). Sin una sesión, literalmente necesito enviar la contraseña y autenticar al usuario con cada solicitud de RPC. Google está haciendo algunos trucos para que el método getUserPrincipal() funcione en todos sus clústeres de servidores, y parece que solo obtiene esa magia si va con Cuentas de Google.

Tal vez me falta algo, pero los documentos de Google acaba de deslizarse sobre este enorme agujero :(

+0

¿tienes enlaces a por qué se desaconsejan las sesiones? parece funcionar para nosotros? – HaveAGuess

+0

Quizás esta es una característica nueva para admitir sesiones. En general, si tiene una sesión en el servidor, sus solicitudes deben volver a la misma instancia de servidor. En caso de que la instancia falle, las copias de su sesión deben distribuirse a uno o más servidores de respaldo. La lógica debe estar integrada en un enrutador al frente de los servidores para saber dónde están las copias de seguridad para cada usuario.Esos enrutadores frontales también necesitan ser replicados para no ser un cuello de botella o un punto único de falla. Es una gran cantidad de gastos indirectos innecesarios para almacenar datos en una sesión ... ¡datos que probablemente debería persistir de todos modos! –

+0

continuación ... Utilice la fantástica base de datos distribuida de Google para hacer el trabajo de almacenar/recuperar datos y mantener la lógica del servidor front-end sin estado para que cualquier instancia de servidor pueda usarse para atender solicitudes. Use GWT para mantener el estado de la sesión en el cliente, no en el servidor. –

Cuestiones relacionadas