Submit Documentation FeedbackJoin Developer Community
HomeGuidesAPI Reference
Submit Documentation FeedbackJoin Developer CommunityOptimizely GitHubOptimizely NuGetLog In
Optimizely GitHubOptimizely NuGet

## How it works

A cookie is a small piece of data sent from a website and stored by the web browser on the computer of a visitor, while browsing a website. The main purpose of a cookie is for websites to remember stateful information, or to record a visitor's browsing activity.

Cookies are usually small text files that are stored locally in the browser directory or program data subfolders. The website stores a corresponding file (with same ID tag).

## Cookies and Optimizely 

Select the following sections to see how cookies are user in parts of the Optimizely platform.

  • [DXP cloud services](🔗) 

  • [Optimizely Content Management System (CMS)](🔗) 

  • [A/B testing](🔗) 

  • [Forms](🔗) 

  • [Optimizely Content Recommendations](🔗) 

  • [Tracking, Profile Store (CDP), Visitor Intelligence]\([https://docs.developers.optimizely.com/personalization/v1.3.0-tracking/docs/optimizely-tracking-cookies"Optimizely](🔗) Tracking Developer Guide") 

  • [Marketing Automation connectors](🔗)

## SameSite cookies attributes 

With version 80, Google Chrome implemented the changes the IETF has proposed for the SameSite cookie attribute. These are:

  • The default setting for cookies without a SameSite attribute changes from SameSite = None to SameSite = Lax.

  • When using SameSite = None, you must also specify **Secure**. Otherwise, the cookie is rejected. **Secure **requires communication over HTTPS.

To comply to these changes, Microsoft ASP.NET emits a SameSite cookie header when HttpCookie.SameSite value is **None**. As part of this change, **FormsAuth** and **SessionState** cookies are also issued with SameSite = Lax instead of the previous default value **None**.

See [Work with SameSite cookies in ASP.NET](🔗) for documentation on the changes in ASP.NET.

### Known issues - PDF preview for secured PDF

A bug in Chrome affects large PDFs with restricted access when SameSite = Lax for forms authentication. See the blog by Linus Ekström: [Issues with PDF preview for secured PDF:s in Google Chrome due to .NET security patch](🔗).

### Troubleshooting

The new policy should work for most websites and cookies. Websites that cannot comply with the requirements of **Lax** have to change the default values. An example of a limitation with **Lax** is that you cannot iframe the site under another domain and still use cookie-based features such as authentication and session state.

Note

Older browsers might not support SameSite or implement a different behavior on SameSite.

#### Configuring SameSite for anti-forgery

Configuring the built-in anti-forgery used in Optimizely user interface (requires **EPiServer.CMS.Core** 11.15):



#### Configuring SameSite for forms authentication
Configuring forms authentication to using **None** and HTTPS\:


#### Configuring SameSite for session state
Configuring session state to using **None**:


#### Configuring SameSite default values for cookies
Configuring the default for all cookies that do not explicitly use SameSite:


#### Revert behavior of sending SameSite = None to browsers
Revert to the previous behavior of not sending SameSite = None to browsers:


### References
  • [SameSite cookies explained](🔗)
  • [Azure App Service—SameSite cookie handling and .NET Framework 4.7.2 patch](🔗)
  • [Cumulative Update for .NET Framework](🔗)