Closed anjackson closed 2 years ago
It seems not to be the specific JSESSIONID
cookie, but perhaps that there are so many cookies from archived websites the browser is discarding the one we care about.
I've made DEV copy the auth cookie into every response, as I'm assuming this will mean it is considered 'fresh' and should not be dropped. I've asked Carlos to check if it helps.
Specifically:
add_header 'Set-Cookie' 'PLAY_SESSION=$cookie_PLAY_SESSION; Domain=$http_x_forwarded_host; Path=/act; SameSite=Strict; HttpOnly; Secure; Priority=High';
As per https://github.com/ukwa/w3act/issues/662#issuecomment-940948374 the add_header
hack seems to work.
Wayback * forwarding appears to work fine on DEV.
Amusingly, because the settings of the from-W3ACT and copied cookies are slightly different, it's currently not possible to log out of W3ACT! 👎 The app sets
Set-Cookie
PLAY_SESSION=; Max-Age=-86397; Expires=Mon, 11 Oct 2021 12:59:55 GMT; Path=/act; HTTPOnly
This does not overwrite the cookie that is copied for pywb
.
Original cookie...
Copied cookie...
Removing the Domain=$host
part (i.e. the bit with the leading dot .
in the copied cookie) seems to restore the expected behaviour.
Deferring SameSite to next quarter. Calling this done but leaving original ticket open until W3ACT is deployer.
This is to note any outcomes from https://github.com/ukwa/w3act/issues/662
/wayback/*/
to/wayback/archive/*/
redirect is not working, ended up athttp://prod1/act/wayback/archive//https://www.scottishpower.co.uk/
JSESSIONID
Set-Cookie
headers are what's tripping up everything else - see e.g. this page.Deal with the SameSite warning (see below, and https://github.com/ukwa/w3act/issues/663).