Changes to sending authenticated requests to Google Reader

[Brad Hawkes]

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.

Thanks for your attention.

Brad Hawkes
Google Reader Team

[Nick Bradbury]

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.

- Nick

[Brad Hawkes]

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

[Steve Conover]

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:
> 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/ClientLoginyou should get back as

[Mariano Kamp]

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.

[ubikdroid]

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? See
http://groups.google.com/group/android-developers/browse_thread/thread/7a6bf77910ca31e0?pli=1

3.) Can the auth token obtained from AccountManager.getAccounts() in
Android 2.0+ be used in this new header? See
http://groups.google.com/group/android-developers/browse_thread/thread/be16e3903442931b/7cc8f46739c6b3dc?#7cc8f46739c6b3dc

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/ClientLoginyou should get back as

[StefanK]

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:
> 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

[Nick Bradbury]

> 1.) Will there be an overlap where both the SID cookie and the
> new header will work for authorization?

My tests with FeedDemon show that both of these work right now - you
can authenticate using either the SID cookie or the auth token.

[Mihai Parparita]

On Thu, Feb 11, 2010 at 12:49 AM, Steve Conover <scon...@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.

Mihai

[Stefan Kyntchev]

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

[Mihai Parparita]

On Thu, Feb 11, 2010 at 6:42 AM, StefanK <skyn...@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 at http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html#Request)? Reader does not support hosted (Google Apps) accounts.

Mihai

[Mihai Parparita]

On Thu, Feb 11, 2010 at 10:59 AM, Stefan Kyntchev <skyn...@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?

Using only the new auth header should be OK.

Mihai

[Stefan Kyntchev]

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...

[Nick Bradbury]

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?

[Mihai Parparita]

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).

Mihai

[ubikdroid]

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?
>
> 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

[ubikdroid]

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.

> > > For those apps that area already obtaining authentication fromhttps://www.google.com/accounts/ClientLoginyoushouldget back as

[Jayesh]

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?

Thanks again.

[ubikdroid]

Unfortunately its undocumented. There is this thread but its more to
do with GoogleLoginServiceHelper.getCredentials():

http://www.google.com/url?sa=D&q=http://groups.google.com/group/android-developers/browse_thread/thread/7a6bf77910ca31e0%3Fpli%3D1&usg=AFQjCNEY7tMeOjckHBPv3qj3RnIylFqusQ

[Mariano Kamp]

Hey Stefan,

did you also get this to work with the Android 2.0 authentication?
Where do you specify "GOOGLE" thereß

Cheers,
Mariano

[Stefan Kyntchev]

Mariano,

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
>

[Mariano Kamp]

Hey Stefan,

thanks for sharing your insights.

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?

Does it work on Android 2.0/2.01 for you? I ran into an exception. The same code works fine on 2.1/Nexus though. It would be great to look at their code here too.

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

[ubikdroid]

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:

AccountManagerFuture<Bundle> accFut =
accountManager.getAuthToken(acct, "reader", false, null, null);
try {
if(accFut != null && accFut.getResult() != null){
Bundle bundle = accFut.getResult();

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

[Mariano Kamp]

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?

[ubikdroid]

Hi Mariano, I don't have an Android 2.0.1 device to test
unfortunately. Just my N1 and G1. I haven't tried hosted accounts.

My phone didn't prompt me to allow access. I have seen that behaviour
before though. Probably when I was hacking around with it a while ago.

You might be right about the cert. I used the same one to sign both
apps. I might try again with a different cert for each app.

On Mar 4, 9:09 pm, Mariano Kamp <mariano.k...@gmail.com> wrote:
> 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?
>

[Mariano Kamp]

I'll download your widget to a 2.0.1 widget tomorrow and feed back.

[Mariano Kamp]

widget -> device

[Stefan Kyntchev]

I can't agree more. Seems like at Google, blog posts are the primary
way to provide such documentation, so hopefully some of the Android
engineers will write how to authenticate against their own Google
services.

I have 2 apps (a test app and my main BeyondPod app) both were signed
with the same (debug) certificate at the time of the test. Both
prompted for access and both got the same token. (This is on Nexus One
2.1 device)

I wonder if you by any chance both widgets are installed under the
same OS account (there was something in the manifest that allows you
to make 2 apps run under the same OS account).

Stefan

On Mar 4, 4:09 pm, Mariano Kamp <mariano.k...@gmail.com> wrote:
> 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?
>

[Mariano Kamp]

Mark, I tried on 2.0.1/Milestone and didn't run into the same error my implementation hits. The currently released Widget in the Market sports the new authentication? I selected "use account on this phone" or similar.

Stefan, I also tried yours 2.2..9 with the same effect that I see (afterward it seems to just hang "Retrieving Account Details") :

V/BeyondPod( 2062): --- BeyondPod Global WiFi WakeLock released!  (21 ms. since last trace)   [BeyondPodApplication]

D/dalvikvm( 1244): GC freed 8769 objects / 505928 bytes in 146ms

E/WindowManager( 1170): Unknown window type: 2008

I/ActivityManager( 1170): Starting activity: Intent { act=android.intent.action.MAIN flg=0x10100000 cmp=mobi.beyondpod/.ui.views.Splash }

D/dalvikvm( 1517): GC freed 2388 objects / 109448 bytes in 107ms

W/ResourceType( 1230): No package identifier when getting name for resource number 0x00000000

E/JavaBinder( 1230): *** Uncaught remote exception!  (Exceptions are not yet supported across processes.)

E/JavaBinder( 1230): android.content.res.Resources$NotFoundException: String resource ID #0x0

E/JavaBinder( 1230): at android.content.res.Resources.getText(Resources.java:200)

E/JavaBinder( 1230): at android.content.res.Resources.getString(Resources.java:253)

E/JavaBinder( 1230): at android.content.Context.getString(Context.java:149)

E/JavaBinder( 1230): at com.google.android.googleapps.GoogleLoginService$AccountAuthenticatorImpl.getAuthTokenLabel(GoogleLoginService.java:586)

E/JavaBinder( 1230): at android.accounts.AbstractAccountAuthenticator$Transport.getAuthTokenLabel(AbstractAccountAuthenticator.java:155)

E/JavaBinder( 1230): at android.accounts.IAccountAuthenticator$Stub.onTransact(IAccountAuthenticator.java:123)

E/JavaBinder( 1230): at android.os.Binder.execTransact(Binder.java:287)

E/JavaBinder( 1230): at dalvik.system.NativeStart.run(Native Method)

Guys, btw., your login integrations look really nice.

Anyway, given that at least (2/3) of our implementations are also not working on Android 2.0, not for Google Apps accounts, not for re-login, to use them it was necessary to decompile proprietary Google classes to know what parameters too set, the Google provided GUIs look like prototypes and that there is absolutely zero documentation ... maybe it is a hint that despite the pressure to have such a solution, it is just not ready for prime time.

Maybe Android 2.2 will be better and maybe there will be documentation or at least the officially open sourced Google provided apps (Contacts, Calendar, ...) will use the new API without relying on closed source bits.

On Thu, Mar 4, 2010 at 10:26 PM, Mariano Kamp <marian...@gmail.com> wrote:

[Mark]

Thanks for testing on the Milestone. The current version of my apps in the market still use the old GoogleLoginServiceBlockingHelper.getAuthToken() method. I have just updated them to send the token in the new header instead of the cookie.

[Stefan Kyntchev]

Mariano, thanks for the test.
I had a small hope that that I may be using a slightly different
"attack vector" in my call, but I guess it all boils down to the same
authentication code.

Stefan

On Mar 5, 8:46 am, Mark <markst3v...@googlemail.com> wrote:
> Thanks for testing on the Milestone. The current version of my apps in the
> market still use the old GoogleLoginServiceBlockingHelper.getAuthToken()
> method. I have just updated them to send the token in the new header instead
> of the cookie.
>

> > On Thu, Mar 4, 2010 at 10:26 PM, Mariano Kamp <mariano.k...@gmail.com>wrote:
>
> >> I'll download your widget to a 2.0.1 widget tomorrow and feed back.
>

> >>> > >www.google.com/accounts/ClientLoginyoushouldgetback as

[Edwin Khodabakchian]

Thanks for the heads up. One question: ClientLogin seems to depend on
the application asking the user for their username and password. We
have been trying to stay away from that pattern. Will there be an
alternative OAuth or AuthSub mechanism we could use that would be
based on a redirect pattern?

Thank you!
-Edwin

On Feb 10, 5:12 pm, 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/ClientLoginyou should get back as

[jkramer]

Hi,

I'm currently changing my Google Reader app Unread to use the new
authentication method, but while testing it I think I found a problem.
I'm requesting the first set of cookies like this:

$ curl -s 'https://www.google.com/accounts/ClientLogin' -d
accountType=GOOGLE -d Email=exa...@googlemail.com -d Passwd=example -
d service=reader

This works fine, I get SID, LSID and Auth. However, when I try to
request the token needed for Google Reader, only SID seems to work,
not Auth:

$ curl -s https://www.google.com/reader/api/0/token -b Auth=$AUTH
<html><head><title>403 Forbidden</title>
[...]
Your client does not have permission to get URL <code>/reader/api/0/
token</code> from this server.
[...]

$ curl -s https://www.google.com/reader/api/0/token -b SID=$SID
[returns token code]

I also tried GOOGLE_OR_HOSTED for accountType, no change.

[jkramer]

Sorry, my fault. I should have read more carefully. This works:

curl -s https://www.google.com/reader/api/0/token -H
"Authorization:GoogleLogin auth"=$AUTH

On Mar 18, 10:30 am, jkramer <nexing...@googlemail.com> wrote:
> Hi,
>
> I'm currently changing my Google Reader app Unread to use the new
> authentication method, but while testing it I think I found a problem.
> I'm requesting the first set of cookies like this:
>
> $ curl -s 'https://www.google.com/accounts/ClientLogin'-d

> accountType=GOOGLE -d Email=exam...@googlemail.com -d Passwd=example -

> d service=reader
>
> This works fine, I get SID, LSID and Auth. However, when I try to
> request the token needed for Google Reader, only SID seems to work,
> not Auth:
>

> $ curl -shttps://www.google.com/reader/api/0/token-b Auth=$AUTH

> <html><head><title>403 Forbidden</title>
> [...]
> Your client does not have permission to get URL <code>/reader/api/0/
> token</code> from this server.
> [...]
>

> $ curl -shttps://www.google.com/reader/api/0/token-b SID=$SID

> [returns token code]
>
> I also tried GOOGLE_OR_HOSTED for accountType, no change.
>
> On Feb 11, 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 fromhttps://www.google.com/accounts/ClientLoginyoushould get back as

[Mihai Parparita]

Just as a heads up, we've finally rolled this out everywhere, authentication via SID cookie is no longer supported (ClientLogin and OAuth are the preferred methods).

Mihai

On Wed, Feb 10, 2010 at 8:38 PM, Brad Hawkes <bha...@google.com> wrote:

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.b...@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.

- Nick

[Mariano Kamp]

Thanks for giving us ample time before turning off the old way.

[Khash]

So far as I can see, OAuth is not officially supported either
(although it works). Is there a reason for that? Is it going to ever
be official? (well the whole API is unofficial!)

On Jun 22, 9:13 pm, Mihai Parparita <mih...@google.com> wrote:
> Just as a heads up, we've finally rolled this out everywhere, authentication
> via SID cookie is no longer supported (ClientLogin and OAuth are the
> preferred methods).
>
> Mihai
>
>
>
> On Wed, Feb 10, 2010 at 8:38 PM, Brad Hawkes <bhaw...@google.com> wrote:
> > 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
>