On Tue, Feb 1, 2011 at 2:40 PM, Jeff Schnitzer <[email protected]> wrote:
> 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. > > Yup! > * 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. > The application is a rewrite of an application that I had written and successfully marketed back in the early 2000s so it is definitely more business than fun - though it will be fun for me to make some money with it (please please please lol) as it will be fun for me to see it providing a service to its users. > 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]<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]<google-web-toolkit%[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]<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.
