I will explore both options and I will also take a look at the Expenses GWT sample app you mentioned.
Thanks! Jeff On Tue, Feb 1, 2011 at 1:24 PM, David Chandler <[email protected]>wrote: > Yes, this is workable, but note that login with Google Accounts requires a > redirect to the Google Accounts login page. It may be easier (and more > secure) to see if the user is logged in on the server side using a JSP or > servlet filter, then redirect accordingly to the Google Accounts login page > or your app's host page. But either way works. > > /dmc > > > On Tue, Feb 1, 2011 at 12:14 PM, Jeff Schwartz <[email protected]>wrote: > >> Thanks, David. I would be the last person to think you are being biased as >> I have come to respect Google above all other hi tech companies out there. >> If I were offered an opportunity to work for Google I would jump at it :) >> >> I've read all the documentation that Google provides regarding using >> Google Accounts for authentication. I think the following scenario will >> suffice for my use case: >> >> In my application's EntryPoint I will immediately make an RPC call to >> check if the user has a Google Account and if they do I will use the Google >> Account ID to check to see if they have registered to use my application. In >> response to these outcomes I will generate and return a payload to the >> client which the client can then use to determine its next course of action. >> >> >> If the payload indicates the the user has registered then the member's >> view will be rendered to the browser. If the payload indicates that they >> have a Google Account but haven't registered or it indicates that they don't >> have a Google Account then the non members view will be rendered to the >> browser. If the user has a Google Account then the non members view will >> provide an option for the user to register. If the user doesn't have a >> Google Account it will provide a link to Google where they can register >> which I am thinking would be the URL to sign up for Gmail though I might >> look to automate this somewhat by using the User api to control the >> forwarding and return urls. >> >> Sound good to you? >> >> Jeff >> >> >> On Tue, Feb 1, 2011 at 11:55 AM, David Chandler >> <[email protected]>wrote: >> >>> Hi Jeff, >>> >>> I've been using Google Accounts for login in a GWT side project without >>> any trouble (granted, I'm a little biased :-) I choose Google auth for >>> exactly the reasons you mention. FYI, there are some classes in the Expenses >>> GWT sample app that implement login with Google Accounts on GAE. >>> >>> >>> http://code.google.com/p/google-web-toolkit/source/browse/trunk/samples/expenses/src/main/java/com/google/gwt/sample/gaerequest/ >>> >>> /dmc >>> >>> On Tue, Feb 1, 2011 at 9:08 AM, Jeff Schwartz >>> <[email protected]>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 >>>> [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]<google-web-toolkit%[email protected]> >>>> . >>>> For more options, visit this group at >>>> http://groups.google.com/group/google-web-toolkit?hl=en. >>>> >>> >>> >>> >>> -- >>> David Chandler >>> Developer Programs Engineer, Google Web Toolkit >>> w: http://code.google.com/ >>> b: http://googlewebtoolkit.blogspot.com/ >>> t: @googledevtools >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Google Web Toolkit" group. >>> To post to this group, send email to [email protected] >>> . >>> To unsubscribe from this group, send email to >>> [email protected]<google-web-toolkit%[email protected]> >>> . >>> 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 [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<google-web-toolkit%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> > > > > -- > David Chandler > Developer Programs Engineer, Google Web Toolkit > w: http://code.google.com/ > b: http://googlewebtoolkit.blogspot.com/ > t: @googledevtools > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
