On Tue, Feb 1, 2011 at 2:40 PM, Jeff Schnitzer <jeff@infohazard.org> wrote:
Yup!
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.
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 <jefftschwartz@gmail.com> 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 <drfibonacci@google.com>
> 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 <jefftschwartz@gmail.com>
>> 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 <drfibonacci@google.com>
>>> 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 <jefftschwartz@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+unsubscribe@googlegroups.com.
>>>>> 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
>>>> google-web-toolkit@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> google-web-toolkit+unsubscribe@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+unsubscribe@googlegroups.com.
>>> 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 google-web-toolkit@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-web-toolkit+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment