Optimizely
Jun 22, 2010
visibility 5624
star star star star star
(0 votes)

Cookieless Session Support in EPiServer

No.

As in "No - we don't support cookieless sessions when using Friendly URLs". Your natural reaction is then probably to ask "Why not?". The basic design guidelines for our software is that we should build upon and extend the .NET / ASP.NET framework and that would imply that we should support cookieless sessions (CS from here on).

If you have never heard of CS before you probably want to check this article for some background information. http://msdn.microsoft.com/en-us/library/aa479314.aspx

As hinted in the article, the implementation of CS in ASP.NET is somewhat fragile in itself. There are a couple of guidelines that you have to follow in order for your site to work properly with CS. Basically you need to make sure that all yours that you put in the HTML response are relative or you need to call a special method (HttpResponse.ApplyAppPathModifier) to include the CS URL segment.

Another aspect of CS that is far from ideal is the fact that it is extremely easy to hijack an existing session - you simply need to copy the URL. Cookies are here to stay and my personal opinion is that CS is a leftover from the old "cookies are evil" debate.

Back to the techie stuff - why does this not work with FURL? All links that we generate from permanent links could be adapted to call ApplyAppPathModifier if we detect that CS is enabled. Unfortunately there is another thing that will break the solution. If you generate links in the standard ASP.NET way and that involves the System.Web.UI.Control.ResolveUrl method, you will implicitly call ApplyAppPathModifier and write the CS URL segment.

This is bad since there is no way for the FURL module to reliably detect the CS URL segment in a URL (short of doing nasty reflection tricks) and we need to do that in order to properly rebase all URLs when we do FURL rewriting.

Finally there are a lot of complications when dealing with CS links from JavaScript (which we do a lot from edit mode) which would require a significant investment to update and fully support CS.

To summarize: In order to support the somewhat brittle CS system we would need to introduce even more restrictions. Since there has been practically no requests for EPiServer to support CS we have decided to say "CS is unsupported" for the time being.

Jun 22, 2010

Comments

error Please login to comment.
Latest blogs
Why your GeoPoint never reaches Optimizely Graph, and how to fix it

Geo search lets Optimizely Graph match and rank content against geographic coordinates, so applications can deliver location-aware experiences such...

K Khan | Nov 11, 2026

Mark goes desktop: what's new in Optimizely Agent Platform, November 2026

Optimizely's November release for Mark, the Optimizely Agent Platform, is one of the most significant updates since the platform launched. Two...

Scott Reed | Nov 11, 2026

Upgrading Optimizely CMS 13 from .NET 10 to .NET 11

How to upgrade Optimizely CMS 13 to .NET 11, including a workaround for edit mode and an Azure gotcha.

Tomas Hensrud Gulla | Nov 11, 2026 |

Making Built-in CMS Categories Queryable in Optimizely Graph (CMS 13 PaaS)

With Optimizely CMS 13 PaaS, Optimizely Graph replaces Search & Navigation as the content query engine. However, if your existing CMS solution reli...

Mardy | Nov 10, 2026

Default to All Properties View for Non-Visual Content in Optimizely CMS 13

Optimizely CMS 13 opens every content item in Visual Builder by default. That works well for pages and

Adnan Zameer | Nov 10, 2026 |

The SharePoint Connector for Optimizely CMS 11 is Now Open-Source

Hello everyone, Today we are announcing that we have open-sourced Optimizely Connect for SharePoint, the connector that enables integration between...

Bien Nguyen | Nov 10, 2026