...
This cookie is tied to the domain which is it came from, and it is impossible for the browser to send the same cookie to another domain.
...
Note that the browser is able to send to the same cookie to both www.server1.site.com, and www.server2.site.com since they are just different servers on the same domain, which is site.com.
So, the browser does not share cookies between different domains.
Cross-Domain Cookie Sharing
Often, it is necessary to share information between servers running on different domains, even though the browser does not support it directly, fortunately there is a way to fool the browsers into obtaining the same cookie value for each domain, even E-Business and e-Commerce has changed requirements, so all companies now need to conduct online business with users and business partners alike. This means that companies are forced to deploy a multitude of different servers, applications and services. These servers are now mission critical and support the companies business requirements, and therefore companies depend on these servers to be operating, and it is of the utmost overwhelming importance that clients see the company as a whole, and not as a number of different parts.
...
The secured cookie contains the PP session ID, as well as the userid and username, this means that you can share the users user's identity with a 3rd party, even if they do not run PortalProtect.
...
Configuration
In order to use cross-domain cookie sharing PortalProtect must be configured to do so.
...
Be sure to keep the private key protected, and only give away the public key to others.
If you need cross session controller domain logon some extra configuration in addition to the above is needed. What you need to configure is the enablement of cross-domain login and the rules applied to it.
...
| Code Block | ||
|---|---|---|
| ||
<group name="crossdomain" description="Cross-domain session support"> <property name="domain.www.primary.dk.crossdomain.enable" value="true" description="Enable/disable cross -domain for this domain"/> <property name="domain.www.primary.dk.crossdomain.transfergroups" value="true" description="Enable/disable group transfer"/> <property name="domain.www.primary.dk.crossdomain.transferanonymoussessions" value="true" description="Enable/disable anonymous transfers"/> <property name="domain.www.primary.dk.crossdomain.transferstatenames" value="state1,state2,state3" description="List of state names to transfer"/> </group> |
...
| Code Block |
|---|
<group name="crossdomain" description="Cross-domain session support"> <property name="domain. www.secondary.dk.crossdomain.enable" value="true" description="Enable/disable cross -domain for this domain"/> <property name="domain. www.secondary.dk.crossdomain.overwriteloggedonsessions" value="false" description="Enable/disable overwriting of logged on sessions"/> </group> |
On the receiver site you also need to configure the cross-domain authentication plugin as part of you authentication plugin list.
...
If you need to do cross session controller domain logins you can generate the ticket for a cross-domain login with the following code. It is shown here as a standard JSP HREF link. This does however have limitations on Internet Explorer since it only handles 1024 byte request strings. So you should use a POST mechanism to send the request instead if you are transferring groups and/or state variables since they quickly take up space:
...