Authorization cookie for multiple versions: A Google change since yesterday

[OferR]

Hi,

My Android app gets an authorization cookie from one version (e.g. v1.myapp.appspot.com) and uses it for accessing other versions (e.g. v4.myapp.appspot.com).

This has worked fine for many years until yesterday, when all my users fail to access the server.

Does anyone know anything about this?

Is there a way to get an authorization cookie which is valid for the entire app engine application (all versions)?

TIA
Ofer

[Nick (Cloud Platform Support)]

Hi Ofer,

Google Groups isn't the place to post specific technical issues, as this forum is meant more for general discussion of the platform and services. 

If you would like help with a technical issue, you should post to stackoverflow [1] or serverfault [2]. 

If you believe you've found an issue with the platform itself (behaviour is different from documentation or error occurs during normal use), then you should proceed to open a public issue tracker [3] issue with enough detail to reproduce the issue on our side, or if possible, an attached app that can be used to directly observe the behaviour. 

Your issue report contains not enough information to determine what is happening, even in the event that you did post it to one of those other locations, so I suggest adding more detail before doing so. Some examples of the information you might include:

* What kind of cookie is this? 
* How is the cookie generated?
* How is the cookie received, where it is being sent, and what does it authorize/authenticate?

If you would like to open a thread in this forum discussing the platform or services in more broad terms, starting a discussion that would be useful for other users to join in to, feel free to do so.

Finally, if you want to simply have users sign-in to your app, you might want to take a look at the resource gae-login-explainer.appspot.com. As you'll read there, login cookies using the App Engine "login/logout" URLs are scoped to the domain, so that might be why they don't pass between versions. You could try to set a default version and have users simply visit "myapp.appspot.com", where the cookies would transfer. Another option would be to use the Google sign-in button for websites option.

Have a great day!

[1] http://www.stackoverflow.com/

[2] http://www.serverfault.com/

[3] http://code.google.com/p/google-appengine/issues/list

[OferR]

Hi Nick,

Thank you for your comments.
I'll continue here with some more info (and promise to take the next technical issue to stack exchange).

My client is an Android device.
I'm after a SACSID cookie.

With Android, I am getting an authentication cookie from AccountManager and use it in the following URI:

https://v1-dot-myapp.appspot.com/_ah/login?continue=v1-dot-myapp.appspot.com&auth=XXX

where XXX is the retrieved authentication cookie from Android's AccountManager .

As a response, I get the SACSID cookie (response status is 302)

v1-dot-myapp.appspot.com is set as the default version. There is no standard myapp.appspot.com version at all.

As mentioned in the previous post, I could, until a few days ago, use the SACSID cookie received above to access all other versions.

It may also be worth mentioning that it seems that my app engine application had been changed to a Module Based application.
This has happened recently, but I'm not sure when.
(I was always careful not to change to Module Based application because 1) I didn't require the functionality 2) I was worried about unforeseen side effects)

Any help would be very much appreciated.
Ofer

[Nick (Cloud Platform Support)]

Hey Ofer,

Two things to note: 

• Auth cookies of this kind tend to be scoped to a given domain, so I'm surprised it worked before at all. The only scenario I can see it working is if you deployed a series of versions to the same domain (the default appspot domain), and the cookies were transferred and valid between these versions as you deployed new versions, since you were always visiting on the same default appspot domain.

• SACSID cookies are for https, and this gives me an even stronger suspicion that it would only be valid for the one domain.

I would consider this expected behaviour. If you absolutely need to have users authenticated across various domains, I don't think there's a simple way to do this, and if you really don't want to refactor, you might want to look into using a dispatch file to serve different modules (and a module can just as easily be a version, it just means an app engine app) on different routes, so you can use just one domain yet still serve multiple separate apps.