but an open id is not a google account. On Tue, Feb 1, 2011 at 10:50 AM, Jan Mostert <j...@mycee.com> wrote:
> A google account is already an open-id: http://openid.net/get-an-openid/ > <http://openid.net/get-an-openid/> > -- > Jan Vladimir Mostert > BEngSci > > Mail: j...@mycee.com > MyCee Technologies > > > > On Tue, Feb 1, 2011 at 5:46 PM, Jeff Schwartz <jefftschwa...@gmail.com>wrote: > >> Thanks but I'd like to limit the discussion to Google Accounts. >> >> >> On Tue, Feb 1, 2011 at 10:19 AM, Jan Mostert <j...@mycee.com> wrote: >> >>> Spring Security should take care of most of those requirements since it >>> already has openID support built in, but that will require authentication to >>> happen outside your GWT application (I'm a bit paranoid exposing my >>> javascript if people aren't authenticated) and if you really need the login >>> to be in GWT, Vaadin does some serverside magic that will allow you to build >>> a secure login form using GWT. >>> >>> >>> >>> On Tue, Feb 1, 2011 at 4:08 PM, Jeff Schwartz >>> <jefftschwa...@gmail.com>wrote: >>> >>>> Hi all, >>>> >>>> I hope you don't mind me cross posting this to both the gwt and app >>>> engine groups since I'd really like to get the opinions of users on both >>>> platforms. >>>> >>>> I'm in the middle of developing a gwt application on app engine. The >>>> application's security requirements are that non members, meaning those >>>> that >>>> haven't registered, are restricted to viewing only the application's public >>>> 'page'. >>>> >>>> What I developed for authentication is home grown using my own login >>>> form, client side cookies and a User entity with password and email address >>>> stored in the application's data store. While my home grown implementation >>>> works perfectly I am not comfortable with the security implications of >>>> cookies and passing raw passwords to the server to authenticate my users. I >>>> also can not use SSL at this time as financial constraints unfortunately >>>> prohibit any expenditures on this project. >>>> >>>> As I place my users' privacy and security above all else I am therefore >>>> looking to implement a better solution; one that would if possible >>>> eliminate >>>> my responsibility altogether of having to store cookies and passwords and >>>> transport them via HTTP when authenticating. >>>> >>>> One alternative that I am currently considering is using Google Accounts >>>> to authenticate my users along with my own User entity that would store the >>>> additional information users must provide when registering to use the >>>> services of my application. My User entity (not to be confused with the >>>> User >>>> object provided by the User API) would store the user's Google Account ID >>>> and would provide the ability to determine if a user is registered simply >>>> by >>>> querying for their Google Accounts ID in my datastore. It would eliminate >>>> having to store client side cookies and sending raw passwords to the >>>> server. >>>> So far it seems like a win-win proposition as it appears to satisfy all my >>>> use cases. >>>> >>>> For those who already use Google Accounts for user authentication are >>>> you happy with the service? How about the services' availability track >>>> record and does it provide the security you had hoped it would? >>>> >>>> For those using Google Accounts along with GWT have you found any >>>> specific issues related to using it with GWT (I am using RPC BTW) that you >>>> can relate? >>>> >>>> I am looking forward to reading your feedback and responses and thanks >>>> in advance. >>>> >>>> Jeff >>>> >>>> >>>> >>>> >>>> -- >>>> *Jeff Schwartz* >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Google Web Toolkit" group. >>>> To post to this group, send email to >>>> google-web-toolkit@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> >>>> . >>>> For more options, visit this group at >>>> http://groups.google.com/group/google-web-toolkit?hl=en. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Google Web Toolkit" group. >>> To post to this group, send email to google-web-toolkit@googlegroups.com >>> . >>> To unsubscribe from this group, send email to >>> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/google-web-toolkit?hl=en. >>> >> >> >> >> -- >> *Jeff Schwartz* >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google Web Toolkit" group. >> To post to this group, send email to google-web-toolkit@googlegroups.com. >> To unsubscribe from this group, send email to >> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to google-web-toolkit@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- *Jeff Schwartz* -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
