My $0.02: * For most applications, third-party auth should be a no-brainer. "conversion" rates will go up when users don't have to create Yet Another Account, and more than make up for any tiny amount of unavailability you are likely to experience.
* If your app is more "fun" and less "business", strongly consider Facebook auth. It's a bit harder to implement but it's quite a bit more javascript friendly - you can perform auth without redirects, getting a javascript callback when login or logout happens. Jeff On Tue, Feb 1, 2011 at 10:44 AM, Jeff Schwartz <[email protected]> wrote: > 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]. >>>>> 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]. >>>> 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. >> >> >> >> -- >> 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]. >> 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. > -- 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.
