Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

SameSite workaround using second cookie

Description

Chrome having essentially confirmed they plan to yank the 2 minute rule, we have no choice but to implement a Safari workaround to avoid a total mess.

All but the session cookie are explicitly SameSite None, so we need to implement a forcible workaround with a second parallel cookie name for RelayState and post preservation.

The session and recovery cookies really aren't meant to be SameSite, but should be handled with a separate setting to make it an option if people want to open up the session to CSRF.

The best way to implement this is probably going to be API changes via additive methods on the HTTPRequest/Response interfaces in xmltooling to automatically implement the lookaside logic.

Environment

None

Activity

Scott CantorFebruary 4, 2020 at 5:18 PM

Implemented with sameSiteSession and sameSiteFallback properties added. Other cookies are automatically SameSite=None. Will document the breaking change for broken Safari in release notes.

Scott CantorFebruary 4, 2020 at 12:34 AM

Prototyped successfully. After considering the future implications I think we need to future proof this by adding two defaulting parameters to HTTPResponse::setCookie to explicitly control SameSite and to toggle the backup cookie workaround.

The SP would explicitly set SameSite to None via the API for the relay state and POST data cookies, and would get a new opt-in flag to enable the Safari workaround. I think the Safari hack should be opt-in to force people to explicitly turn on the hack so they know they should turn it off in the future.

An additional setting would control SameSite for session and recovery cookies, since those shouldn't be exposed cross-site by default.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Created February 3, 2020 at 2:42 PM
Updated April 13, 2020 at 5:49 PM
Resolved February 4, 2020 at 5:18 PM

Flag notifications