C2DM Google login?

[Mark Murphy]

I am attempting to get C2DM working. I am able to register from a
custom-written Android app, using my C2DM account name. However, all
attempts to send a message are failing with a 401 Unauthorized error.
I know how to get a Google auth token -- I am using code that works
successfully with Gmail. However, two separate implementations of the
send logic get the 401 error, suggesting my token may look valid but
be broken, somehow.

I cannot find where in the chrome2phone project you actually do the
login. I see where you use the login for the C2DM send operation, but
it is only being loaded from a cache. It is not clear where the code
is that populates this cache.

Any suggestions on where I can find code that correctly logs me into the C2DM?

Thanks!

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

Android Consulting: http://commonsware.com/consulting

[Costin Manolache]

The token must be requested for 'ac2dm' service ( and not 'mail', 'cl', 'lh2', etc ), and the user ID you use should be the 'role account', as you specified in the form - the one we whitelisted. 

You can retrieve this with 'curl' or any other mean - it is then configured into the server. We want to avoid storing username/password in the server, and the server wouldn't be able to answer captchas. I suggest getting it first with curl, there are examples in the ClientLogin documentation (ex: http://code.google.com/apis/gdata/articles/using_cURL.html ) - again, make sure you specify service=ac2dm

It should also match the role account specified in the android application - for 'cloud to device' sample app it's specified in DeviceRegistrar.SENDER_ID.

If you used 'ac2dm' service and the account matches the one used by the android application - please respond to the invitation email with more details, I'll double check the whitelist. 

Costin

[Mark Murphy]

On Mon, Jul 5, 2010 at 1:45 PM, Costin Manolache <cos...@google.com> wrote:
> The token must be requested for 'ac2dm' service ( and not 'mail', 'cl',
> 'lh2', etc ), and the user ID you use should be the 'role account', as you
> specified in the form - the one we whitelisted.
> You can retrieve this with 'curl' or any other mean - it is then configured
> into the server.

OK, the curl stuff helped point out where I was making an error in
getting the authorization -- thanks!

> We want to avoid storing username/password in the server,

Please bear in mind that this would appear to run counter to the
documentation, which says:

"The server should store the token and have a policy to refresh it
periodically."

It is not possible to both "have a policy to refresh it periodically"
and "avoid storing username/password in the server".

Now I just need to figure out why I get Error=NotRegistered on a
registration_id I just generated...

Thanks again!

[Costin Manolache]

On Mon, Jul 5, 2010 at 11:27 AM, Mark Murphy <mmu...@commonsware.com> wrote:

On Mon, Jul 5, 2010 at 1:45 PM, Costin Manolache <cos...@google.com> wrote:
> The token must be requested for 'ac2dm' service ( and not 'mail', 'cl',
> 'lh2', etc ), and the user ID you use should be the 'role account', as you
> specified in the form - the one we whitelisted.
> You can retrieve this with 'curl' or any other mean - it is then configured
> into the server.

OK, the curl stuff helped point out where I was making an error in
getting the authorization -- thanks!

> We want to avoid storing username/password in the server,

Please bear in mind that this would appear to run counter to the
documentation, which says:

"The server should store the token and have a policy to refresh it
periodically."

It is not possible to both "have a policy to refresh it periodically"
and "avoid storing username/password in the server".

The token should be stored - it's different than user/password in that 

it's tied to a particular service, someone who gets it can only use it 

to send c2dm messages.

Regarding 'refresh periodically' policy - it means every few weeks you should 

update with a new token, using curl or something else to get a new token and

upload the new token to your app.

There is also code in the appengine sample that looks for a UPDATE_CLIENT_AUTH 

header ( in C2DMMessaging for appengine ), the server may provide you with 

a fresh auth token - you should update your config with the new token. 

Costin

[Mark Murphy]

On Mon, Jul 5, 2010 at 2:41 PM, Costin Manolache <cos...@gmail.com> wrote:
> There is also code in the appengine sample that looks for a
> UPDATE_CLIENT_AUTH
> header ( in C2DMMessaging for appengine ), the server may provide you with
> a fresh auth token - you should update your config with the new token.

Ah! Automatically handling the token is far better than some manual process.

Thanks!

[debajit]

On Mon, Jul 5, 2010 at 11:48 AM, Mark Murphy <mmu...@commonsware.com> wrote:

On Mon, Jul 5, 2010 at 2:41 PM, Costin Manolache <cos...@gmail.com> wrote:
> There is also code in the appengine sample that looks for a
> UPDATE_CLIENT_AUTH
> header ( in C2DMMessaging for appengine ), the server may provide you with
> a fresh auth token - you should update your config with the new token.

Ah! Automatically handling the token is far better than some manual process.

yeah, our intent is for this to be an automatic/programmatic process, except for the case where you change the password for the role account.  in that case, you'll need to get/store a new auth token manually.