This should work fine, Jeff. I didn't mean to suggest that login redirects are automatic, only that you must send the user to the Google Accounts login page in order to login, as you have described.
Ideally, all service calls should be authenticated, which you can do with a servlet filter and a wrapped Callback object that catches the exception thrown by the filter. The Apache Hupamail project has an example of this using gwt-dispatch, and the Expenses sample I referenced earlier does the same using RequestFactory. /dmc On Wed, Feb 2, 2011 at 7:19 AM, Jeff Schwartz <[email protected]>wrote: > Hi David, > > I believe that automatic redirects to the sign-in page is optional and is > only enforced if specified by establishing a security constraint in the > application's deployment descriptor for those pages where that behavior is > desired. Without this option I believe I can use the following technique via > RPC: > > In an RPC implementation I call the request object's getUserPrincipal() > method. If that returns null then I know the user isn't logged in so I then > call the UserService method createLoginURL(java.lang.String destinationURL) > where destinationURL is the url for my application and pass the generated > login url back to the client which will then navigate the browser to the > login page using the returned login url. > > The login page will redirect the user back to my app after they have logged > in and again my rpc implementation is called but this time the user is > logged in so then a query is made to the datastore to determine if the user > has registered to use the application (using the user's Google Accounts ID) > and if they haven't that is communicated back to the client in the payload, > otherwise the user is logged in and they have already registered to use the > app and that is communicated back to the client via the payload. > > The call to the above RPC implementation would be done in the module's > entry point which means there is no way the user can bypass the login > mechanism, even when the login page redirects the user back to the > application after they have logged in. This cycle is key to the > implementation. > > What do you think about using this approach? > > Jeff > > > > > page is onl is available but that it isn't required as > > 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. > -- 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.
