On 7/19/08, André Warnier <[EMAIL PROTECTED]> wrote: > I am not the ultimate specialist here, but I am interested, because I'd > like to make sure too. > > And there is still something that bothers me in the explanations above : > > I assume that what you mean by "accessing a site via a proxy" is this : > - your browser always uses URLs to "http://myproxy.mydomain.com"; > - but this proxy server, > - if the request is like > "http://myproxy.mydomain.com/amazon/item1";, issues a > request to "http://www.amazon.com/item1";, retrieves that page (and > associated cookies), and returns that page (and associated cookies) to the > browser > - if the request is like > "http://myproxy.mydomain.com/google/item1";, issues a > request to "http://www.google.com/item1";, retrieves that page (and > associated cookies), and returns that page (and associated cookies) to the > browser > - if the request is not like above, the proxy serves it from local pages > > And you would like that the cookies sent by the original sites, arrive to > the browser as set by the original site. In other words, you would like > that if "www.amazon.com" sets a cookie with a domain of "www.amazon.com" (or > ".amazon.com"), then that's how your browser should see it. Let's call > this alternative A. > > The alternative (apparently possible), would be that the proxy server > rewrites the cookies so that they all appear to originate from > "myproxy.mydomain.com" (or ".mydomain.com"). Let's call this alternative B. > > But as I see it, I see a problem with both options. > > Problem with alternative A : > The received cookie has a domain of ".amazon.com". > Thus, when your browser issues the next request to > "http://myproxy.mydomain.com/amazon/item2";, this cookie > will not be sent by the browser, because the domains don't match (and your > browser has no idea that this URL is ultimately destined for amazon). > > Problem with alternative B : > The received cookies all have a domain of ".mydomain.com". > Thus they will be sent by the browser for any subsequent request to > "http://myproxy.mydomain.com/amazon/*"; OR > "http://myproxy.mydomain.com/google/*";, because now the > domain matches always. > Now what if these two sites send a cookie with the same name ? > I mean : you visit > "http://myproxy.mydomain.com/amazon/item1"; and you receive > a cookie named "private-info" from the domain "mydomain.com". Then you visit > "http://myproxy.mydomain.com/google/item2"; and you receive > a cookie named "private-info" from the domain "mydomain.com". > The second cookie would overwrite the first one. > Then you access again > "http://myproxy.mydomain.com/amazon/item1";, and your > browser would attach the cookie "private-info" originally from the google > site (or the "JSESSIONID" cookie from Tomcat e.g.). > That does not sound right, does it ? > > At any rate, it seems to me that you'd have to do some more juggling to > keep things working as planned, no ? > At the very least, you would have to also rename the received cookie at the > proxy level (e.g. prefix the name with some original site-id) before sending > it to the browser, and vice-versa when the browser re-sends the cookie, > rename it again (strip the prefix) before sending it to the original site. > Plus, even so, when your browser accesses either > "http://myproxy.mydomain.com/amazon/item1"; or > "http://myproxy.mydomain.com/google/item1";, it will send > both cookies, because the domain ".mydomain.com" matches in both cases. So > the proy should also be smart enough to strip off the cookie that does not > belong to the real destination site. > > Is that thing smart enough to do that ? > Or am I not smart enough to see an obvious solution ? > André
Alternative A has the additional problem that browsers reject Cookies when the domain specified does not match the originating server. Yes, the Cookie would not be returned to the originating server because the Cookie is for a different domain, but the Cookie would not even be saved because that would create security issues. Your concerns for Alternative B are valid, but the solution is different than proposed. You do not rename Cookies to avoid conflicts, just set the path parameter. Alternative B is that one proxy server accesses multiple applications (or other websites) that set Cookies with the same name and different information. This is very common as many websites use Google's visitor tracking. (Check your browser's stored Cookies for the names "__utma" and "__utmz" for many websites.) With proper care, this is not a problem. Cookies include a path parameter. The cookie for http://www.example.com/google/... should have the path "/google". The cookie for http://www.example.com/amazon/...should have the path "/amazon". A Web reverse proxy using paths to specify which application handles the request should use the ProxyPassReverseCookiePath directive to translate the outbound Cookies. Inbound translation should not be needed as browsers will only send Cookies for the current path i.e. http://www.example.com/amazon/... will not include Cookies for path "/google". solprovider
