We just wanted to let you know about changes coming for Reader authentication. We will be changing the details for how our normal web- browsing experience handles authentication. This change will break clients that are based on using the SID cookie to communicate with Reader (this seems to be many current clients). To ensure that your app continues to be able to access Reader data you should transition to using ClientLogin to access Reader. This is the general mechanism that is preferred for communication with many Google services. Details of how to use ClientLogin, along with some libraries that are available: http://code.google.com/apis/gdata/docs/auth/clientlogin.html
Here is a quick summary of how to make this change: For those apps that area already obtaining authentication from https://www.google.com/accounts/ClientLogin you should get back as part of your response an Auth= value. For every request you send to Reader you should provide that value as a HTTP header and things will work as usual. The header format is: Authorization:GoogleLogin auth=[value obtained from ClientLogin]
Also please keep in mind that both SID cookies and Auth tokens do expire. You should store your Auth token, but if you start to get 401 errors you may need to obtain a new Auth token. You should not do retries on 401 errors unless you have obtained a new Auth token.
Thanks for the update, Brad. Do you have any idea of when this change will be required (ie: when the SID cookie method will stop working)? I can certainly change authentication in the next build of FeedDemon, but would prefer to release that build in a few weeks rather than straight away.
Sorry I forgot to mention that. Our current plan will be activate this change in early April. We want to give everyone sufficient time to make the changes.
-Brad
On Wed, Feb 10, 2010 at 4:33 PM, Nick Bradbury <nick.bradb...@gmail.com>wrote:
> Thanks for the update, Brad. Do you have any idea of when this change > will be required (ie: when the SID cookie method will stop working)? > I can certainly change authentication in the next build of FeedDemon, > but would prefer to release that build in a few weeks rather than > straight away.
We use Google Reader to get access to the scrubbed / canonicalized Atom feeds. Could you please discuss how to access this capability without ClientLogin (or any login or that matter)?
This is an extremely valuable tool and it would be a real shame (somewhat debilitating, in fact) if it went unsupported. We'd really like some way to get at this without requiring GUI interaction with a real user.
Regards, Steve
On Feb 10, 4:12 pm, Brad Hawkes <bhaw...@google.com> wrote:
> We just wanted to let you know about changes coming for Reader > authentication. We will be changing the details for how our normal web- > browsing experience handles authentication. This change will break > clients that are based on using the SID cookie to communicate with > Reader (this seems to be many current clients). To ensure that your > app continues to be able to access Reader data you should transition > to using ClientLogin to access Reader. This is the general mechanism > that is preferred for communication with many Google services. Details > of how to use ClientLogin, along with some libraries that are > available:http://code.google.com/apis/gdata/docs/auth/clientlogin.html
> Here is a quick summary of how to make this change: > For those apps that area already obtaining authentication fromhttps://www.google.com/accounts/ClientLoginyou should get back as > part of your response an Auth= value. For every request you send to > Reader you should provide that value as a HTTP header and things will > work as usual. > The header format is: Authorization:GoogleLogin auth=[value obtained > from ClientLogin]
> Also please keep in mind that both SID cookies and Auth tokens do > expire. You should store your Auth token, but if you start to get 401 > errors you may need to obtain a new Auth token. You should not do > retries on 401 errors unless you have obtained a new Auth token.
That sounds really good. Maybe this will even work then with the Android authentication API.
April sounds reasonable. Having said that, I cannot force my users to upgrade and while 90%+ will upgrade within a couple of days of a release, some will take their sweet time due in part to the different Android markets used. So later would be better ;)
I have an already tested release that I will rollout this weekend, but will then aim to push the next update two to three weeks after.
On Thu, Feb 11, 2010 at 1:12 AM, Brad Hawkes <bhaw...@google.com> wrote: > Hello friends,
> We just wanted to let you know about changes coming for Reader > authentication. We will be changing the details for how our normal web- > browsing experience handles authentication. This change will break > clients that are based on using the SID cookie to communicate with > Reader (this seems to be many current clients). To ensure that your > app continues to be able to access Reader data you should transition > to using ClientLogin to access Reader. This is the general mechanism > that is preferred for communication with many Google services. Details > of how to use ClientLogin, along with some libraries that are > available: http://code.google.com/apis/gdata/docs/auth/clientlogin.html
> Here is a quick summary of how to make this change: > For those apps that area already obtaining authentication from > https://www.google.com/accounts/ClientLogin you should get back as > part of your response an Auth= value. For every request you send to > Reader you should provide that value as a HTTP header and things will > work as usual. > The header format is: Authorization:GoogleLogin auth=[value obtained > from ClientLogin]
> Also please keep in mind that both SID cookies and Auth tokens do > expire. You should store your Auth token, but if you start to get 401 > errors you may need to obtain a new Auth token. You should not do > retries on 401 errors unless you have obtained a new Auth token.
> We just wanted to let you know about changes coming for Reader > authentication. We will be changing the details for how our normal web- > browsing experience handles authentication. This change will break > clients that are based on using the SID cookie to communicate with > Reader (this seems to be many current clients). To ensure that your > app continues to be able to access Reader data you should transition > to using ClientLogin to access Reader. This is the general mechanism > that is preferred for communication with many Google services. Details > of how to use ClientLogin, along with some libraries that are > available:http://code.google.com/apis/gdata/docs/auth/clientlogin.html
> Here is a quick summary of how to make this change: > For those apps that area already obtaining authentication fromhttps://www.google.com/accounts/ClientLoginyou should get back as > part of your response an Auth= value. For every request you send to > Reader you should provide that value as a HTTP header and things will > work as usual. > The header format is: Authorization:GoogleLogin auth=[value obtained > from ClientLogin]
> Also please keep in mind that both SID cookies and Auth tokens do > expire. You should store your Auth token, but if you start to get 401 > errors you may need to obtain a new Auth token. You should not do > retries on 401 errors unless you have obtained a new Auth token.
Thanks for heads up Brad. I am the author of BeyondPod, a podcatcher for Android and Windows Mobile. Google Reader integration is widely used feature in both apps and when anything goes wrong there I get tons of support emails. I am really happy that for the first time I can be proactive about it.
For some reason, currently, if users use an e-mail that is hosted by Google Apps, they can't login in Reader using the https://www.google.com/accounts/ClientLogin. From my tests, it appears that when registering for a Reader account with Google Apps e-mail, a different account is created (they may or may not have the same password) and when using ClientLogin, it logs in to the Google App account and the SID token is invalid for Reader.
Will this change with the new Authentication changes, or is there another way to handle Google Apps logins?
Stefan
On Feb 11, 4:03 am, ubikdroid <markst3v...@googlemail.com> wrote:
> On Feb 11, 12:12 am, Brad Hawkes <bhaw...@google.com> wrote:
> > Hello friends,
> > We just wanted to let you know about changes coming for Reader > > authentication. We will be changing the details for how our normal web- > > browsing experience handles authentication. This change will break > > clients that are based on using the SID cookie to communicate with > > Reader (this seems to be many current clients). To ensure that your > > app continues to be able to access Reader data you should transition > > to using ClientLogin to access Reader. This is the general mechanism > > that is preferred for communication with many Google services. Details > > of how to use ClientLogin, along with some libraries that are > > available:http://code.google.com/apis/gdata/docs/auth/clientlogin.html
> > Here is a quick summary of how to make this change: > > For those apps that area already obtaining authentication fromhttps://www.google.com/accounts/ClientLoginyoushould get back as > > part of your response an Auth= value. For every request you send to > > Reader you should provide that value as a HTTP header and things will > > work as usual. > > The header format is: Authorization:GoogleLogin auth=[value obtained > > from ClientLogin]
> > Also please keep in mind that both SID cookies and Auth tokens do > > expire. You should store your Auth token, but if you start to get 401 > > errors you may need to obtain a new Auth token. You should not do > > retries on 401 errors unless you have obtained a new Auth token.
On Thu, Feb 11, 2010 at 12:49 AM, Steve Conover <scono...@gmail.com> wrote: > We use Google Reader to get access to the scrubbed / canonicalized > Atom feeds. Could you please discuss how to access this capability > without ClientLogin (or any login or that matter)?
> This is an extremely valuable tool and it would be a real shame > (somewhat debilitating, in fact) if it went unsupported. We'd really > like some way to get at this without requiring GUI interaction with a > real user.
How are you currently accessing these feeds? If you are using the http://www.google.com/reader/*public*/atom/feed/... path (which doesn't require authentication), then you shouldn't need to change anything on your end.
I also did a test with the new method this morning and it appears to work correctly (only Auth header and no SID cookie). As I am about to push a new public release of BeyondPod, is is safe to use only the new "Auth header", method or should I use both the header and SID for the time being?
Stefan
On Feb 11, 10:29 am, Nick Bradbury <nick.bradb...@gmail.com> wrote:
On Thu, Feb 11, 2010 at 6:42 AM, StefanK <skyntc...@gmail.com> wrote: > Thanks for heads up Brad. I am the author of BeyondPod, a podcatcher > for Android and Windows Mobile. Google Reader integration is widely > used feature in both apps and when anything goes wrong there I get > tons of support emails. I am really happy that for the first time I > can be proactive about it.
> For some reason, currently, if users use an e-mail that is hosted by > Google Apps, they can't login in Reader using the > https://www.google.com/accounts/ClientLogin. From my tests, it appears > that when registering for a Reader account with Google Apps e-mail, a > different account is created (they may or may not have the same > password) and when using ClientLogin, it logs in to the Google App > account and the SID token is invalid for Reader.
> Will this change with the new Authentication changes, or is there > another way to handle Google Apps logins?
On Thu, Feb 11, 2010 at 10:59 AM, Stefan Kyntchev <skyntc...@gmail.com>wrote:
> I also did a test with the new method this morning and it appears to > work correctly (only Auth header and no SID cookie). > As I am about to push a new public release of BeyondPod, is is safe to > use only the new "Auth header", method or should I use both the > header and SID for the time being?
> On Thu, Feb 11, 2010 at 6:42 AM, StefanK <skyntc...@gmail.com> wrote: > > Thanks for heads up Brad. I am the author of BeyondPod, a podcatcher > > for Android and Windows Mobile. Google Reader integration is widely > > used feature in both apps and when anything goes wrong there I get > > tons of support emails. I am really happy that for the first time I > > can be proactive about it.
> > For some reason, currently, if users use an e-mail that is hosted by > > Google Apps, they can't login in Reader using the > >https://www.google.com/accounts/ClientLogin. From my tests, it appears > > that when registering for a Reader account with Google Apps e-mail, a > > different account is created (they may or may not have the same > > password) and when using ClientLogin, it logs in to the Google App > > account and the SID token is invalid for Reader.
> > Will this change with the new Authentication changes, or is there > > another way to handle Google Apps logins?
I've changed over to using the auth token in FeedDemon, and my understanding is that if the auth token expires, the request will return HTTP 401, and the first time HTTP 401 is received the auth token should be re-requested. But since HTTP 401 can be received for other reasons, I'm wondering how to know for sure that the failure was due to a bad/expired token?
For example, in the case of a bad/expired T token (used with GRAPI calls), the request will return HTTP 400, and the HTTP headers will include "X-Reader-Google-Bad-Token: true." Is there anything similar for a bad/expired auth token?
The cleanest way to detect the bad/expired token state is to request /reader/api/0/user-info (which gets you information about the currently logged-in user). You shouldn't get a 401 in any other case there (I assume you're referring to 401s you could get when requesting a shared items stream that you don't have permission to see, as far as other reasons you could get it).
On Fri, Feb 12, 2010 at 4:59 PM, Nick Bradbury <nick.bradb...@gmail.com> wrote: > I've changed over to using the auth token in FeedDemon, and my > understanding is that if the auth token expires, the request will > return HTTP 401, and the first time HTTP 401 is received the auth > token should be re-requested. But since HTTP 401 can be received for > other reasons, I'm wondering how to know for sure that the failure was > due to a bad/expired token?
> For example, in the case of a bad/expired T token (used with GRAPI > calls), the request will return HTTP 400, and the HTTP headers will > include "X-Reader-Google-Bad-Token: true." Is there anything similar > for a bad/expired auth token?
It looks the token obtained using the getCredentials() method does not work in the new header. The token obtained from AccountManager on Android 2.0+ devices seems to work. Is there any way that Android 1.x devices can obtain a valid auth token automatically (i.e. without using Google ClientLogin)? Users can be funny about entering their password in apps so I would prefer an option for automatic login across the board.
On Feb 11, 9:03 am, ubikdroid <markst3v...@googlemail.com> wrote:
> On Feb 11, 12:12 am, Brad Hawkes <bhaw...@google.com> wrote:
> > Hello friends,
> > We just wanted to let you know about changes coming for Reader > > authentication. We will be changing the details for how our normal web- > > browsing experience handles authentication. This change will break > > clients that are based on using the SID cookie to communicate with > > Reader (this seems to be many current clients). To ensure that your > > app continues to be able to access Reader data you should transition > > to using ClientLogin to access Reader. This is the general mechanism > > that is preferred for communication with many Google services. Details > > of how to use ClientLogin, along with some libraries that are > > available:http://code.google.com/apis/gdata/docs/auth/clientlogin.html
> > Here is a quick summary of how to make this change: > > For those apps that area already obtaining authentication fromhttps://www.google.com/accounts/ClientLoginyoushould get back as > > part of your response an Auth= value. For every request you send to > > Reader you should provide that value as a HTTP header and things will > > work as usual. > > The header format is: Authorization:GoogleLogin auth=[value obtained > > from ClientLogin]
> > Also please keep in mind that both SID cookies and Auth tokens do > > expire. You should store your Auth token, but if you start to get 401 > > errors you may need to obtain a new Auth token. You should not do > > retries on 401 errors unless you have obtained a new Auth token.
I have found a solution to my issue with Android 1.x devices. It turns out the way I was obtaining the auth token was incorrect. I was using getCredentials() with a null service String. This meant I was actually getting a token for "OTHER_SERVICES". If I use GoogleLoginServiceBlockingHelper.getAuthToken() with the service set to "reader" I get a token that works in the new header.
On Feb 17, 11:38 am, ubikdroid <markst3v...@googlemail.com> wrote:
> It looks the token obtained using the getCredentials() method does not > work in the new header. The token obtained from AccountManager on > Android 2.0+ devices seems to work. Is there any way that Android 1.x > devices can obtain a valid auth token automatically (i.e. without > using Google ClientLogin)? Users can be funny about entering their > password in apps so I would prefer an option for automatic login > across the board.
> On Feb 11, 9:03 am, ubikdroid <markst3v...@googlemail.com> wrote:
> > Thanks for the heads up Brad. > > Can you answer these questions please?
> > 1.) Will there be an overlap where both the SID cookie and the new > > header will work for authorization?
> > On Feb 11, 12:12 am, Brad Hawkes <bhaw...@google.com> wrote:
> > > Hello friends,
> > > We just wanted to let you know about changes coming for Reader > > > authentication. We will be changing the details for how our normal web- > > > browsing experience handles authentication. This change will break > > > clients that are based on using the SID cookie to communicate with > > > Reader (this seems to be many current clients). To ensure that your > > > app continues to be able to access Reader data you should transition > > > to using ClientLogin to access Reader. This is the general mechanism > > > that is preferred for communication with many Google services. Details > > > of how to use ClientLogin, along with some libraries that are > > > available:http://code.google.com/apis/gdata/docs/auth/clientlogin.html
> > > Here is a quick summary of how to make this change: > > > For those apps that area already obtaining authentication fromhttps://www.google.com/accounts/ClientLoginyoushouldget back as > > > part of your response an Auth= value. For every request you send to > > > Reader you should provide that value as a HTTP header and things will > > > work as usual. > > > The header format is: Authorization:GoogleLogin auth=[value obtained > > > from ClientLogin]
> > > Also please keep in mind that both SID cookies and Auth tokens do > > > expire. You should store your Auth token, but if you start to get 401 > > > errors you may need to obtain a new Auth token. You should not do > > > retries on 401 errors unless you have obtained a new Auth token.
On Feb 19, 2:00 am, ubikdroid <markst3v...@googlemail.com> wrote:
> I have found a solution to my issue with Android 1.x devices. It turns > out the way I was obtaining the auth token was incorrect. I was using > getCredentials() with a null service String. This meant I was actually > getting a token for "OTHER_SERVICES". If I use > GoogleLoginServiceBlockingHelper.getAuthToken() with the service set > to "reader" I get a token that works in the new header.
Thanks ubikdroid. That's very useful tip. Do you know where GoogleLoginServiceBlockingHelper methods are documented (esp. getAuthToken). I use this class from the framework.jar file I got from @jbqueru (http://github.com/android/ platform_frameworks_opt_com.google.android/blob/master/framework.jar). But I suppose its source code is not available. Do you have a link where I can get more information about this library?
> On Feb 19, 2:00 am, ubikdroid <markst3v...@googlemail.com> wrote:
> > I have found a solution to my issue with Android 1.x devices. It turns > > out the way I was obtaining the auth token was incorrect. I was using > > getCredentials() with a null service String. This meant I was actually > > getting a token for "OTHER_SERVICES". If I use > > GoogleLoginServiceBlockingHelper.getAuthToken() with the service set > > to "reader" I get a token that works in the new header.
> Thanks ubikdroid. That's very useful tip. Do you know where > GoogleLoginServiceBlockingHelper methods are documented (esp. > getAuthToken). I use this class from the framework.jar file I got from > @jbqueru (http://github.com/android/ > platform_frameworks_opt_com.google.android/blob/master/framework.jar). > But I suppose its source code is not available. Do you have a link > where I can get more information about this library?
On Thu, Feb 11, 2010 at 9:15 PM, Stefan Kyntchev <skyntc...@gmail.com> wrote: > Thanks Mihai,
> Switching to "GOOGLE" did the trick. I was using "HOSTED_OR_GOOGLE" > which was "preferring" the hosted account. > Thank you very much for the help.
> Stefan
> On Feb 11, 11:01 am, Mihai Parparita <mih...@google.com> wrote: >> On Thu, Feb 11, 2010 at 6:42 AM, StefanK <skyntc...@gmail.com> wrote: >> > Thanks for heads up Brad. I am the author of BeyondPod, a podcatcher >> > for Android and Windows Mobile. Google Reader integration is widely >> > used feature in both apps and when anything goes wrong there I get >> > tons of support emails. I am really happy that for the first time I >> > can be proactive about it.
>> > For some reason, currently, if users use an e-mail that is hosted by >> > Google Apps, they can't login in Reader using the >> >https://www.google.com/accounts/ClientLogin. From my tests, it appears >> > that when registering for a Reader account with Google Apps e-mail, a >> > different account is created (they may or may not have the same >> > password) and when using ClientLogin, it logs in to the Google App >> > account and the SID token is invalid for Reader.
>> > Will this change with the new Authentication changes, or is there >> > another way to handle Google Apps logins?
The change that I made and worked was in the POST request to https://www.google.com/accounts/ClientLogin -one of the input parameters is "accountType" which I used to call with "HOSTED_OR_GOOGLE" and that caused the authentication to occur against the hosting account. Changing it to "GOOGLE" solved that issue. As you can tell this was part of the manual authentication (where I cache the "GoogleLogin auth=XXXX" token.)
As far as 2.0 accounts, in order to support both pre 2.0 and 2.0 devices, I decided to offer both options (you pick to enter user/name password or you pick an account to use. If you have 2.0 device you have both options, in 1.6 you have only the UN/PW option.
In my tests I found that 2.0 authentication works for the most part but hosted accounts are still an issue. Here are some observations:
1. If you manually add a Google account (using Settings > Accounts and sync) - everything works as expected. 2. If you manually add a hosted account (again using Settings > Accounts and sync), it will authenticate against the hosted account so the authentication token by default will be for the hosted account. If you try to retrieve the Reader subscription list with that token, the request does not fail but you get an empty list (looks like it is a brand new account with no subscriptions). 3. Poking in the source, I found that if you use AccountManager.getAuthTokenByFeatures(), you can, in the "Feature" array, supply "GOOGLE" as a feature, and that probably will get you the Google token (instead of the hosted). That may work if you have the same password for both Google and Hosted account, but I don't think it will work if you have different passwords. This same call will also provide an option to add (register) a new account (by prompting for UN/PW) which is probably the only way to get any hosted account to work.
I am still trying to find a way to get the hosted accounts working.
Stefan
On Feb 27, 1:38 pm, Mariano Kamp <mariano.k...@gmail.com> wrote:
> did you also get this to work with the Android 2.0 authentication? > Where do you specify "GOOGLE" thereß
> Cheers, > Mariano
> On Thu, Feb 11, 2010 at 9:15 PM, Stefan Kyntchev <skyntc...@gmail.com> wrote: > > Thanks Mihai,
> > Switching to "GOOGLE" did the trick. I was using "HOSTED_OR_GOOGLE" > > which was "preferring" the hosted account. > > Thank you very much for the help.
> > Stefan
> > On Feb 11, 11:01 am, Mihai Parparita <mih...@google.com> wrote: > >> On Thu, Feb 11, 2010 at 6:42 AM, StefanK <skyntc...@gmail.com> wrote: > >> > Thanks for heads up Brad. I am the author of BeyondPod, a podcatcher > >> > for Android and Windows Mobile. Google Reader integration is widely > >> > used feature in both apps and when anything goes wrong there I get > >> > tons of support emails. I am really happy that for the first time I > >> > can be proactive about it.
> >> > For some reason, currently, if users use an e-mail that is hosted by > >> > Google Apps, they can't login in Reader using the > >> >https://www.google.com/accounts/ClientLogin. From my tests, it appears > >> > that when registering for a Reader account with Google Apps e-mail, a > >> > different account is created (they may or may not have the same > >> > password) and when using ClientLogin, it logs in to the Google App > >> > account and the SID token is invalid for Reader.
> >> > Will this change with the new Authentication changes, or is there > >> > another way to handle Google Apps logins?
I also use ClientLogin with GOOGLE for the old OS versions too.
Regarding the feature/google-approach, that sounds good. I also found out that the GR responses are empty for hosted accounts when using HOSTED_OR_GOOGLE with ClientLogin. I will try out the feature/google-approach with the same and different pw this week and feed back. Besides this being support intensive I don't see a major downside with using the same password on both.
Btw. At what source did you poke? I wasn't aware that Google's implementation was open sourced?
Any thoughts on how to handle auto re-logins? It seems to be a real hot button for many users to re-login every two weeks. I can understand that to a degree. When this happens at night you might find out on the train that there are no news/podcasts this morning ;-( I think I will memorize the date/time when I asked for a token. When the user launches the app during the last two days before the token expires I will ask him to do the re-login right away interactively. I hope that solution is less annoying.
Cheers, Mariano
On Sun, Feb 28, 2010 at 10:59 PM, Stefan Kyntchev <skyntc...@gmail.com>wrote:
> The change that I made and worked was in the POST request to > https://www.google.com/accounts/ClientLogin -one of the input > parameters is "accountType" which I used to call with > "HOSTED_OR_GOOGLE" and that caused the authentication to occur against > the hosting account. Changing it to "GOOGLE" solved that issue. As you > can tell this was part of the manual authentication (where I cache the > "GoogleLogin auth=XXXX" token.)
> As far as 2.0 accounts, in order to support both pre 2.0 and 2.0 > devices, I decided to offer both options (you pick to enter user/name > password or you pick an account to use. If you have 2.0 device you > have both options, in 1.6 you have only the UN/PW option.
> In my tests I found that 2.0 authentication works for the most part > but hosted accounts are still an issue. Here are some observations:
> 1. If you manually add a Google account (using Settings > Accounts and > sync) - everything works as expected. > 2. If you manually add a hosted account (again using Settings > > Accounts and sync), it will authenticate against the hosted account so > the authentication token by default will be for the hosted account. If > you try to retrieve the Reader subscription list with that token, the > request does not fail but you get an empty list (looks like it is a > brand new account with no subscriptions). > 3. Poking in the source, I found that if you use > AccountManager.getAuthTokenByFeatures(), you can, in the "Feature" > array, supply "GOOGLE" as a feature, and that probably will get you > the Google token (instead of the hosted). That may work if you have > the same password for both Google and Hosted account, but I don't > think it will work if you have different passwords. This same call > will also provide an option to add (register) a new account (by > prompting for UN/PW) which is probably the only way to get any hosted > account to work.
> I am still trying to find a way to get the hosted accounts working.
> Stefan
> On Feb 27, 1:38 pm, Mariano Kamp <mariano.k...@gmail.com> wrote: > > Hey Stefan,
> > did you also get this to work with the Android 2.0 authentication? > > Where do you specify "GOOGLE" thereß
> > Cheers, > > Mariano
> > On Thu, Feb 11, 2010 at 9:15 PM, Stefan Kyntchev <skyntc...@gmail.com> > wrote: > > > Thanks Mihai,
> > > Switching to "GOOGLE" did the trick. I was using "HOSTED_OR_GOOGLE" > > > which was "preferring" the hosted account. > > > Thank you very much for the help.
> > > Stefan
> > > On Feb 11, 11:01 am, Mihai Parparita <mih...@google.com> wrote: > > >> On Thu, Feb 11, 2010 at 6:42 AM, StefanK <skyntc...@gmail.com> wrote: > > >> > Thanks for heads up Brad. I am the author of BeyondPod, a podcatcher > > >> > for Android and Windows Mobile. Google Reader integration is widely > > >> > used feature in both apps and when anything goes wrong there I get > > >> > tons of support emails. I am really happy that for the first time I > > >> > can be proactive about it.
> > >> > For some reason, currently, if users use an e-mail that is hosted by > > >> > Google Apps, they can't login in Reader using the > > >> >https://www.google.com/accounts/ClientLogin. From my tests, it > appears > > >> > that when registering for a Reader account with Google Apps e-mail, > a > > >> > different account is created (they may or may not have the same > > >> > password) and when using ClientLogin, it logs in to the Google App > > >> > account and the SID token is invalid for Reader.
> > >> > Will this change with the new Authentication changes, or is there > > >> > another way to handle Google Apps logins?
> > >> Have you tried setting accountType to GOOGLE (as described athttp:// > code.google.com/apis/accounts/docs/AuthForInstalledApps.html#R... > > >> Reader does not support hosted (Google Apps) accounts.
I think I might have found an issue with using AccountManager in Android 2.x devices. I have 2 apps in the market that use Google Reader: Reader Widget Pro and Reader Widget Free. I was updating them both to use AccountManager and the new authentication method. I noticed that on my Nexus One when one application (say the Free one) obtained a token using AccountManager.getAuthToken() with the service set to "reader" the other app (say the Pro one) was unable to obtain a token afterwards. Even using AccountManager.invalidateAuthToken in the first app did not work. Sample code:
authToken = bundle.getString("authtoken"); // This key is no longer in the bundle for the 2nd app } else { Log.e(TAG, "accFut null"); }
} catch (OperationCanceledException e) {
e.printStackTrace();
} catch (AuthenticatorException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
I don't know if this is supposed to happen but I will cross post this with the android dev google group. It could mean big problems if several apps are trying to get auth tokens for the same service on the same phone. One application could prevent others from working. I will stick to the old GoogleLoginServiceBlockingHelper method in my apps for now.
On Feb 11, 9:03 am, ubikdroid <markst3v...@googlemail.com> wrote:
> On Feb 11, 12:12 am, Brad Hawkes <bhaw...@google.com> wrote:
> > Hello friends,
> > We just wanted to let you know about changes coming for Reader > > authentication. We will be changing the details for how our normal web- > > browsing experience handles authentication. This change will break > > clients that are based on using the SID cookie to communicate with > > Reader (this seems to be many current clients). To ensure that your > > app continues to be able to access Reader data you should transition > > to using ClientLogin to access Reader. This is the general mechanism > > that is preferred for communication with many Google services. Details > > of how to use ClientLogin, along with some libraries that are > > available:http://code.google.com/apis/gdata/docs/auth/clientlogin.html
> > Here is a quick summary of how to make this change: > > For those apps that area already obtaining authentication fromhttps://www.google.com/accounts/ClientLoginyoushould get back as > > part of your response an Auth= value. For every request you send to > > Reader you should provide that value as a HTTP header and things will > > work as usual. > > The header format is: Authorization:GoogleLogin auth=[value obtained > > from ClientLogin]
> > Also please keep in mind that both SID cookies and Auth tokens do > > expire. You should store your Auth token, but if you start to get 401 > > errors you may need to obtain a new Auth token. You should not do > > retries on 401 errors unless you have obtained a new Auth token.
This whole Auth 2.0 thing is a total mess. Did you test it on Android 2.0.1 devices? It didn't crash for you there? Can you support hosted accounts?
I think I will give up on this until Google documents how to use their implementation (the Google one, not the Android framework). There is just already too much time sunk here.
Anyway, regarding your actual issue, did the Auth mechanism ask you twice to allow access to the selected account? I am not quite sure how it determines the caller, but maybe it might not be the calling app, but the certificate it was signed with that makes the difference. Did you use the same certificate to sign both apps?
On Thu, Mar 4, 2010 at 9:35 PM, ubikdroid <markst3v...@googlemail.com>wrote:
> I think I might have found an issue with using AccountManager in > Android 2.x devices. I have 2 apps in the market that use Google > Reader: Reader Widget Pro and Reader Widget Free. I was updating them > both to use AccountManager and the new authentication method. I > noticed that on my Nexus One when one application (say the Free one) > obtained a token using AccountManager.getAuthToken() with the service > set to "reader" the other app (say the Pro one) was unable to obtain a > token afterwards. Even using AccountManager.invalidateAuthToken in the > first app did not work. Sample code:
> authToken = bundle.getString("authtoken"); // This key is no > longer > in the bundle for the 2nd app > } else { > Log.e(TAG, "accFut null"); > } > } catch (OperationCanceledException e) { > e.printStackTrace(); > } catch (AuthenticatorException e) { > e.printStackTrace(); > } catch (IOException e) { > e.printStackTrace(); > }
> I don't know if this is supposed to happen but I will cross post this > with the android dev google group. It could mean big problems if > several apps are trying to get auth tokens for the same service on the > same phone. One application could prevent others from working. I will > stick to the old GoogleLoginServiceBlockingHelper method in my apps > for now.
> On Feb 11, 9:03 am, ubikdroid <markst3v...@googlemail.com> wrote: > > Thanks for the heads up Brad. > > Can you answer these questions please?
> > 1.) Will there be an overlap where both the SID cookie and the new > > header will work for authorization?
> > 2.) Can the auth token obtained from getCredentials() in Android be > > used in this new header? Seehttp:// > groups.google.com/group/android-developers/browse_thread/threa...
> > 3.) Can the auth token obtained from AccountManager.getAccounts() in > > Android 2.0+ be used in this new header? Seehttp:// > groups.google.com/group/android-developers/browse_thread/threa...
> > Thanks > > Mark
> > On Feb 11, 12:12 am, Brad Hawkes <bhaw...@google.com> wrote:
> > > Hello friends,
> > > We just wanted to let you know about changes coming for Reader > > > authentication. We will be changing the details for how our normal web- > > > browsing experience handles authentication. This change will break > > > clients that are based on using the SID cookie to communicate with > > > Reader (this seems to be many current clients). To ensure that your > > > app continues to be able to access Reader data you should transition > > > to using ClientLogin to access Reader. This is the general mechanism > > > that is preferred for communication with many Google services. Details > > > of how to use ClientLogin, along with some libraries that are > > > available:http://code.google.com/apis/gdata/docs/auth/clientlogin.html
> > > Here is a quick summary of how to make this change: > > > For those apps that area already obtaining authentication fromhttps:// > www.google.com/accounts/ClientLoginyoushould get back as > > > part of your response an Auth= value. For every request you send to > > > Reader you should provide that value as a HTTP header and things will > > > work as usual. > > > The header format is: Authorization:GoogleLogin auth=[value obtained > > > from ClientLogin]
> > > Also please keep in mind that both SID cookies and Auth tokens do > > > expire. You should store your Auth token, but if you start to get 401 > > > errors you may need to obtain a new Auth token. You should not do > > > retries on 401 errors unless you have obtained a new Auth token.
> This whole Auth 2.0 thing is a total mess. Did you test it on Android 2.0.1 > devices? It didn't crash for you there? Can you support hosted accounts?
> I think I will give up on this until Google documents how to use their > implementation (the Google one, not the Android framework). There is just > already too much time sunk here.
> Anyway, regarding your actual issue, did the Auth mechanism ask you twice to > allow access to the selected account? I am not quite sure how it determines > the caller, but maybe it might not be the calling app, but the certificate > it was signed with that makes the difference. Did you use the same > certificate to sign both apps?
> On Thu, Mar 4, 2010 at 9:35 PM, ubikdroid <markst3v...@googlemail.com>wrote:
> > I think I might have found an issue with using AccountManager in > > Android 2.x devices. I have 2 apps in the market that use Google > > Reader: Reader Widget Pro and Reader Widget Free. I was updating them > > both to use AccountManager and the new authentication method. I > > noticed that on my Nexus One when one application (say the Free one) > > obtained a token using AccountManager.getAuthToken() with the service > > set to "reader" the other app (say the Pro one) was unable to obtain a > > token afterwards. Even using AccountManager.invalidateAuthToken in the > > first app did not work. Sample code:
> > authToken = bundle.getString("authtoken"); // This key is no > > longer > > in the bundle for the 2nd app > > } else { > > Log.e(TAG, "accFut null"); > > } > > } catch (OperationCanceledException e) { > > e.printStackTrace(); > > } catch (AuthenticatorException e) { > > e.printStackTrace(); > > } catch (IOException e) { > > e.printStackTrace(); > > }
> > I don't know if this is supposed to happen but I will cross post this > > with the android dev google group. It could mean big problems if > > several apps are trying to get auth tokens for the same service on the > > same phone. One application could prevent others from working. I will > > stick to the old GoogleLoginServiceBlockingHelper method in my apps > > for now.
> > On Feb 11, 9:03 am, ubikdroid <markst3v...@googlemail.com> wrote: > > > Thanks for the heads up Brad. > > > Can you answer these questions please?
> > > 1.) Will there be an overlap where both the SID cookie and the new > > > header will work for authorization?
> > > 2.) Can the auth token obtained from getCredentials() in Android be > > > used in this new header? Seehttp:// > > groups.google.com/group/android-developers/browse_thread/threa...
> > > 3.) Can the auth token obtained from AccountManager.getAccounts() in > > > Android 2.0+ be used in this new header? Seehttp:// > > groups.google.com/group/android-developers/browse_thread/threa...
> > > Thanks > > > Mark
> > > On Feb 11, 12:12 am, Brad Hawkes <bhaw...@google.com> wrote:
> > > > Hello friends,
> > > > We just wanted to let you know about changes coming for Reader > > > > authentication. We will be changing the details for how our normal web- > > > > browsing experience handles authentication. This change will break > > > > clients that are based on using the SID cookie to communicate with > > > > Reader (this seems to be many current clients). To ensure that your > > > > app continues to be able to access Reader data you should transition > > > > to using ClientLogin to access Reader. This is the general mechanism > > > > that is preferred for communication with many Google services. Details > > > > of how to use ClientLogin, along with some libraries that are > > > > available:http://code.google.com/apis/gdata/docs/auth/clientlogin.html
> > > > Here is a quick summary of how to make this change: > > > > For those apps that area already obtaining authentication fromhttps:// > >www.google.com/accounts/ClientLoginyoushouldget back as > > > > part of your response an Auth= value. For every request you send to > > > > Reader you should provide that value as a HTTP header and things will > > > > work as usual. > > > > The header format is: Authorization:GoogleLogin auth=[value obtained > > > > from ClientLogin]
> > > > Also please keep in mind that both SID cookies and Auth tokens do > > > > expire. You should store your Auth token, but if you start to get 401 > > > > errors you may need to obtain a new Auth token. You should not do > > > > retries on 401 errors unless you have obtained a new Auth token.
