Hi Frank, If my understanding of AuthSub authentication is right, it takes user to a Google login page where the user can enter his Google credentials. However, in our case this will not work as we have to update user's calendars in our local data store on a scheduled basis. The scheduler will run approximately 10 times a day. The only solution I can think of for this is to save the user's credentials in our system, fire the scheduled job at a specified time, do a clientLogin first on the basis of UserToken, if it is not valid then on the basis of the stored credentials (and post authentication, update the UserToken), retrieve the calendar data.
If you think there can be or there exist any better solution for the scheduled jobs on the Google calendar service then please let me know. Cheers, Nitin -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Mantek Sent: Friday, April 18, 2008 2:53 PM To: [email protected] Subject: Re: Google Calendar service credentials If this is a server app we can not really encourage using client login for a webservice application,. That is what Authentication for Webapplications is for (authsub). Have you evaluated using this? There you get a long lived token and you do not have to worry about encrypting the credentials. Furthermore your user does not have to overcome "trust" issues with your app, as he remains in control of his credentials. Does that make sense to you? Regards Frank Mantek On Apr 18, 2008, at 9:18 AM, Nitin Gupta wrote: > > HI Frank, > > I am working on a server application. My server, basically needs to > frequently fetch the user's Google calendar Events and update them > in a > local data store. This will always happen in background as a daemon. > > I would like to know if there is any option I can use so that I can > save > time during authentication. My server will authenticate the user on > his > behalf. > > Instead of user, my application can definitely re-authenticate the > user > after every couple of weeks. We are keeping user's Google > credentials within > our application. > > Cheers, > Nitin > > -----Original Message----- > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of > Frank > Mantek > Sent: Wednesday, April 09, 2008 7:02 PM > To: [email protected] > Subject: Re: Google Calendar service credentials > > > Is this a client desktop app or a server app? Is it acceptable that > the user has to reauthenticate every couple of weeks? > > Frank Mantek > Google > On Apr 9, 2008, at 1:31 AM, Nitin Gupta wrote: > >> Hi all, >> >> >> >> This question is not exactly related to the Google Calendar API. It >> is >> releated to its usage in an application and hence is for the >> developers who >> at some point in time may have faced the same problem. >> >> >> >> I am working on an application in which I have to frequently poll >> the Google >> calendars of the registered user. This means that I have to keep >> their >> credentials in my system. I can only use ClientLogin authentication. >> >> >> >> I would like to know about the options which can be used to keep >> the Google >> credentials of the user secured in our system. Can I use some sort of >> encryption? Please share with me the best possible approach which I >> can use >> so that application users can share their credentials without much >> hesitation. >> >> >> >> On the Gdata forum, I was told that something like OS X's Keychain >> mechanism >> should be used. I am working in Java and my platform can be either >> Windows >> or Unix. So, a non-OS based solution is good for me. >> >> >> >> As always, thanks for all the help. >> >> >> >> Cheers, >> >> Nitin >> >> >>> > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Calendar Data API" 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-calendar-help-dataapi?hl=en -~----------~----~----~----~------~----~------~--~---
