Address how cookies are handled on Portal and Ingest Board login

[maxsibilla]

https://developers.google.com/privacy-sandbox/cookies/prepare/overview

[libpitt]

“You need to prepare your site for users who choose to browse without third-party cookies.” Looks like this is just for 3rd party cookies. The primary usage of cookies for us provides a seamless login experience; When a user logs in on the data ingest board, ingest-api is actually setting a cookie in the user’s browser.

response.set_cookie('info',
                    base64_json_str,
                    max_age=86400,
                    domain=current_app.config['COOKIE_DOMAIN'],
                    samesite='Lax',
                    secure=True)

We set the cookie based on domain, so a user logged in on the portal doesn’t need to log in again for the data ingest board.

[libpitt]

Problems can arise when cookies are set for components that exist on different domains than the embedding document, such as images, or other documents embedded via <iframe>s. These cross-site cookies are commonly referred to as third-party cookies—but the behavior and potential issues are the same whether you own all the involved sites or not

https://developer.mozilla.org/en-US/blog/goodbye-third-party-cookies/

[libpitt]

https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API

The Storage Access API is intended to solve this problem; embedded cross-site content can request unrestricted access to third-party cookies and unpartitioned state on a frame-by-frame basis via the Document.requestStorageAccess() method. It can also check whether it already has access via the Document.hasStorageAccess() method

Since Document.requestStorageAccess() only applies at the moment to iframes, this does not apply to us.

[libpitt]

Conclusion:
It seems this has to do with cross-site cookies in the context of iframes.

https://developers.google.com/privacy-sandbox/cookies/storage-access-api