On Sun, Feb 27, 2011 at 6:15 PM, aspineux <[email protected]> wrote: Hi I have one web application and two instances: prod and dev running on two different ports
To summarize your scenario simply: You have two instances, one running at http://example.com:8080/ and another running at http://example.com:9090/ and they are sharing cookies. Unfortunately, this is simply a fact of life on the internet. Referencing the Google Browser Security Handbook<http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies> : * * > > *Scope:* by default, cookie scope is limited to all URLs on the current > host name - and *not* bound to port or protocol information. Scope may be > limited with path= parameter to specify a specific path prefix to which > the cookie should be sent, or broadened to a group of DNS names, rather than > single host only, with domain=. The latter operation may specify any > fully-qualified right-hand segment of the current host name, up to one level > below TLD (in other words, www.foo.bar.example.com may set a cookie to be > sent to *.bar.example.com or *.example.com, but not to *. > something.else.example.com or *.com); the former can be set with no > specific security checks, and uses just a dumb left-hand substring match. > ** > *Note: according to one of the specs, domain wildcards should be marked with > a preceeding period, so .example.com would denote a wildcard match for the > entire domain - including, somewhat confusingly, example.com proper - > whereas foo.example.com would denote an exact host match. Sadly, no > browser follows this logic, and domain=example.com is exactly equivalent > to domain=.example.com. There is no way to limit cookies to a single DNS > name only, other than by not specifying domain= value at all - and even > this does not work in Microsoft Internet Explorer; likewise, there is no way > to limit them to a specific port.* > Depending on the spec you reference, port may or may not be something that can be specified. Even if you *do* specify it, it won't work except on a very small number of browsers, and none of those are in use with more than 10% of web traffic. Despite this, TurboGears2 does have a pair of mechanisms in place to help prevent cookie sharing. In myapp.config.app_cfg you will see the following two lines: # YOU MUST CHANGE THIS VALUE IN PRODUCTION TO SECURE YOUR APP base_config.sa_auth.cookie_secret = "ChangeME" In production.ini/development.ini, you will see this line: beaker.session.secret = 52285e38-9ed9-441b-a2e8-9b6a6c2f62cc > The value after the equal sign will be different, of course. If you had changed these values in your production deployment, then the cookie presented by your browser would be invalid, and you would be forced to login again. Of course, there's also the entirely separate issue of doing development work on a production machine. That just leaves you open for entirely too many problems. TG should handle this situation ! > As you can see from my reply, we *do* handle this situation to the maximum extent that we can. Unless you know of a better way for us to deal with it? -- Michael J. Pedersen My IM IDs: Jabber/[email protected], ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/[email protected] -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
