Setting domain of cookie

[mintyzzz]

Hi Experts,

We have a scenario whereby we have 2 portals of different domains and 1 portal is the leading portal that has a login page where when user logins, submits credentials to the 1st and 2nd portal and sign on simulatenously seamlessly.

This is done by creating a java servlet in the 1st portal that forwards the user details to the 2nd portal. 2nd portal returns the cookie to the servlet which passes it back to the browser. The servlet successfully receives the cookie, but cannot set the domain of it - cookie would disappear - i understand this is natural behaviour to disalllow setting of cookie that is of a different domain than where the servlet resides, is this correct? Can anyone confirm this?

If so, how else can i pass back the cookie to the browser?

Thanks,
ZM

[mruss]

Hello ZM,

I've dealt with this issue before... you have a couple of options for how to handle this.

The issue here is the "Same Origin Policy" with regard to cookies (there are similar concepts for Javascript and probably other things). Essentially, server "www.company1.com" can't set a cookie with the domain "www.company2.com" or "company2.com" (more precisely, most browsers will not accept this cookie). As you have guessed, this is for security reasons, and a good idea for the most part.

AFAIK, there are two ways to deal with this problem when you've got a front-end portal handling a session with another back-end server:

If both servers are in the same DNS domain, you can set the cookie domain to the common portion of the DNS names. I.E., if you have portal.company.com and otherserver.company.com, you can set the cookie with domain company.com. This is OK if you don't mind sharing your cookie with every other server inside the company.com domain; the security ramifications of that need to be considered. Obviously, setting a cookie with just a top-level domain like com is a terrible idea (and may not even work; I haven't tried it).

The other setup I've seen is where the users never interact directly with the back-end web server. Instead, the front-end portal acts as a proxy for all requests that go through to that other server. The advantage of this is that the portal gets complete control over the cookies - it can rename them, change the domain, etc. This can take care of any issues you would have setting the cookie in the client's browser.

Hope this helps.