Take the community feedback survey now.


Nov 22, 2010
  9220
(2 votes)

Running multiple EPiServer sites on different ports on the same host/domain

A setup where you have multiple sites running on different ports on the same host/domain can be handy for quick deployment of sites for testing/demoing/etc and does work fine for the most part.

However, there is an issue that you will likely run into with this kind of setup for ASP.NET sites using Forms authentication: the Forms login cookie will be shared between all of the sites.

 

The reason for this behavior is that Forms authentication by default uses cookies and that the cookie mechanism in HTTP can limit the scope of cookies by domain and/or path, but not by port.

As an example, taken from a local EPiServer CMS installation, the Forms login cookie may look something like this:
Set-Cookie: .EPiServerLogin=encryptedandsignedvaluehere; path=/; HttpOnly

Which in turn means that the client is supposed to send back the cookie for subsequent requests to the same host (regardless of port) for paths under “/”.

 

The preferred solution is to assign different domain names to the different sites, but if this is not practical a possible workaround for this particular problem is to assign different names for the actual login cookie for each site (the latter solution has the downside that the different login cookies will still be sent with requests to all of the sites, just without the normal interference, so if there is any kind of trust issues between the different sites this is not the way to go).


Changing the name of the login cookie is done by changing the name attribute of the configuration/system.web/authentication/forms element in web.config.

Please see http://msdn.microsoft.com/en-us/library/1d3t3c61.aspx for further information on the Forms authentication configuration.

Nov 22, 2010

Comments

tost
tost Nov 23, 2010 01:17 AM

Nice one Håkan! Personally I always set up my local sites with hostnames, bind them all to port 80 and map them in the hosts file. I usually give them names with "local" top level domain, e.g. http://demo.local. But if you for some reason can't do this, your solution is awesome.

Please login to comment.
Latest blogs
Optimizely CMS platform bug in ErrorsController (EPiServer.CMS.Core 12.22.9 fix)

While checking  Application Insights earlier this year, I stumbled upon a strange exception in my Optimizely site. At first, I thought it might be ...

David Drouin-Prince | Nov 9, 2025 |

Avoid Using OnStatusChanged in Optimizely CMS – It Can Impact Database Performance

Beware of Overusing OnStatusChanged in Optimizely CMS Scheduled Jobs Optimizely CMS allows you to create scheduled jobs — a powerful feature often...

David Drouin-Prince | Nov 9, 2025 |

Optimizely CMS - Learning by Doing: EP06 - Create Header, Footer, Menu & Component/View for Blocks

  Episode 6  is Live!! The latest installment of my  Learning by Doing: Build Series  on  Optimizely CMS 12  is now available on YouTube! This vide...

Ratish | Nov 4, 2025 |

Going Headless: 3 Ways to Store Custom Data in Optimizely Graph

Welcome to another installment of my  Going Headless  series. Previously, we covered: Going Headless: Making the Right Architectural Choices Going...

Michał Mitas | Nov 3, 2025

A day in the life of an Optimizely OMVP - What's New in Optimizely CMS: A Comprehensive Recap of 2025 Updates

Hello and welcome to another instalment of a day in the life of an Optimizely OMVP. On the back of the presentation I gave in the October 2025 happ...

Graham Carr | Nov 3, 2025

Optimizely CMS Mixed Auth - Okta + ASP.NET Identity

Configuring mixed authentication and authorization in Optimizely CMS using Okta and ASP.NET Identity.

Damian Smutek | Oct 27, 2025 |