Re: SESSION_COOKIE_DOMAIN on multiple domains.
Thanks so much! That's very helpful.
On Thursday, August 1, 2013 11:46:27 AM UTC-4, Tomáš Ehrlich wrote:
Ah, sorry, I understand now.--
You can set up middleware, which modifies SESSION_COOKIE_DOMAIN based
on request.get_host() and put it before session middleware. I did
similar thing to set SITE_ID.
Only think you have to take care of is thread safety. You need to
override settings.SESSION_COOKIE_DOMAIN value with thread safe object,
and assign value to it.
Take a look at:
https://bitbucket.org/uysrc/django-dynamicsites/src/ e3c6cad807f0328ed3020d28158b3d 6ba0b67025/dynamicsites/ middleware.py?at=default
https://bitbucket.org/uysrc/django-dynamicsites/src/ e3c6cad807f0328ed3020d28158b3d 6ba0b67025/dynamicsites/utils. py?at=default
I took that idea there.
Cheers,
Tom
Dne Thu, 1 Aug 2013 08:40:18 -0700 (PDT)
"J. Cliff Dyer" <j...@sdf.lonestar.org> napsal(a):
> That doesn't make my use case impossible. I'm not looking for a session
> that works on both domains. I'm looking for a site that can create
> sessions for either domain.
>
> On Thursday, August 1, 2013 11:10:59 AM UTC-4, Tomáš Ehrlich wrote:
> >
> > This isn't possible. The problem is with cookies: You have to bind them
> > to certain domain ('example.com') or set of subdomains ('.example.com').
> >
> > About a month ago I've created app to bypass this limitation:
> >
> > - There is one "master" domain, where new session keys are created.
> > - When user access any of "slave" sites, his browser has to go through
> > several redirects:
> >
> > 1. First, it's redirected to "master" site. There he gets token
> > representing current session key.
> > 2. Then it's redirected back to "slave" site, where django sets
> > appropriate cookie with session key (extracted from token).
> > 3. After then, it's redirected back to original page (on slave site).
> > Session cookie is set so user can access the same session as on
> > master site.
> >
> > - Cookie needs to be set only once. When session (on any site) is
> > invalid, the other sites will notice that and automatically generates
> > new session key.
> >
> > Another solution I've seen was distributing session key through
> > iframes, but when you have lot of domains, it's easier to do it this
> > way.
> >
> > I could share the code, if you were interested. It isn't published
> > anywhere yet.
> >
> >
> > Cheers,
> > Tom
> >
> > Dne Thu, 1 Aug 2013 06:41:20 -0700 (PDT)
> > "J. Cliff Dyer" <j...@sdf.lonestar.org <javascript:>> napsal(a):
> >
> > > Is there a way to set the SESSION_COOKIE_DOMAIN for multiple domains,
> > > possibly using the contrib.sites framework?
> > >
> > > We deploy on AWS, and when we roll out an update to one of our site, we
> > > first create a new cloudformation stack, and attach a domain name to it
> > > like prod-oursite-20130801.devstacks.net .
> > >
> > > When we decide it's ready for production, we point www.oursite.com to
> > the
> > > stack. This causes problems with the SESSION_COOKIE_DOMAIN, as we need
> > to
> > > have the cookies domain set to .oursite.com if someone is visiting from
> > > www.oursite.com (or fl.oursite.com, or wa.oursite.com, etc, etc.), but
> > if
> > > they are visiting from prod-oursite-20130801.devstacks.net , we want to
> > > either set the SESSION_COOKIE_DOMAIN to
> > > prod-oursite-20130801.devstacks.net , or unset it altogether, and just
> > use
> > > the default session domain.
> > >
> > > I would love if SESSION_COOKIE_DOMAIN could be set to a dictionary, like
> > > this:
> > >
> > > SESSION_COOKIE_DOMAIN = {
> > > 'www.oursite.com': '.oursite.com',
> > > 'prod-oursite-20130801.devstacks.net ': '.devstacks.net',
> > > }
> > >
> > > but it doesn't seem like that's possible.
> > >
> > >
> >
>
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home