Visiting one Django server logs me out of another Django server, both behind the same proxy

45 views
Skip to first unread message

Stodge

unread,
Sep 29, 2016, 4:50:22 PM9/29/16
to Django users
I have two Django servers A1 and S1, which sit behind a simplistic NodeJS proxy. This is a silly attempt at single sign on.

I can log into and out of A1 (authentication server) just fine. If I log into A1, visit S1 (without being logged in to S1) and then revisit A1, I am no longer logged in. The S1 server doesn't set a new session ID in the cookie and I don't think from memory that the CSRF changes. The session ID cookie hasn't changed, the domain is the same etc.

I can't work out why I'm no longer logged into A1. I know this isn't much to go on but I'm assuming something is happening to the cookies set by S1 when I visit it. Any suggestions appreciated.

Michal Petrucha

unread,
Sep 30, 2016, 4:30:04 AM9/30/16
to django...@googlegroups.com
Are those two applications sitting on the same domain? If yes, then
you should probably configure them to use different session cookies.
Logging in or out causes the session to be reset, and if they try to
use the same session cookie, resetting for either application will
reset it for both.

It's hard to give you any more specific advice, because there are many
ways to go about implementing SSO, some of which would be affected by
this.

You might want to share some more information, such as:

- Are those two applications sharing one database?
- What session backend are you using?
- Are they on the same domain? (this one I've already asked above)
- Could you describe the SSO flow in a bit more detail?

Cheers,

Michal
signature.asc

Stodge

unread,
Sep 30, 2016, 9:00:31 AM9/30/16
to Django users
Thanks Michal,

The two servers are on the same domain and use different databases. At the moment I'm using the default Django session backend.

It's an experiment, nothing more really. I just wanted to see if I could make it work. I haven't really worked out the flow, but it's probably something like:

 - admin creates user account on A1, auto replicates it to S1
 - user U1 visits S1, not logged in
 - U1 redirected to A1 to generate auth token, not logged in
 - U1 logs into A1
 - U1 redirected back to S1 to accept authentication
 - S1 logs U1 in, creates session as normal

So the user is logged into both. It's a fairly naive attempt at reinventing the wheel, but that's how we learn, right? :)

Cheers
Mike

Stodge

unread,
Sep 30, 2016, 9:01:21 AM9/30/16
to Django users
I discovered JSON Web Tokens after I posted my original question. So I'll read about how they work.

Thanks
Mike

Michal Petrucha

unread,
Sep 30, 2016, 9:27:00 AM9/30/16
to django...@googlegroups.com
Hi Mike,

On Fri, Sep 30, 2016 at 06:00:30AM -0700, Stodge wrote:
> Thanks Michal,
>
> The two servers are on the same domain and use different databases. At the
> moment I'm using the default Django session backend.
>
> It's an experiment, nothing more really. I just wanted to see if I could
> make it work. I haven't really worked out the flow, but it's probably
> something like:
>
> - admin creates user account on A1, auto replicates it to S1
> - user U1 visits S1, not logged in
> - U1 redirected to A1 to generate auth token, not logged in
> - U1 logs into A1
> - U1 redirected back to S1 to accept authentication
> - S1 logs U1 in, creates session as normal
>
> So the user is logged into both. It's a fairly naive attempt at reinventing
> the wheel, but that's how we learn, right? :)

Sounds all right, at least from a higher-level point of view. So
basically, those two services are pretty much separate, just sharing a
domain. In this case, your problem should go away if you set a unique
SESSION_COOKIE_NAME for each of those sites.

It might be a different situation if those two sites were using a
shared database; then, the same session ID would be valid for both,
but since that's not the case here, they need to be separate.

Cheers,

Michal
signature.asc

Stodge

unread,
Sep 30, 2016, 6:01:05 PM9/30/16
to Django users
Thanks again. I set a different session cookie name for S1 and it seems to have worked.
Reply all
Reply to author
Forward
0 new messages