Part 2 of this answer explains it fairly well: https://stackoverflow.com/a/477578 Also, this was a nice read: https://web.archive.org/web/20180819014446/http://jaspan.com/improved_persistent_login_cookie_best_practice
It depends on your threat model, but the use of public computers in libraries, internet cafΓ©s or similar is probably the most relevant here, when arguing against activating "remember me". These days, shared computer use is declining I'd assume. With twtxt being a niche for more computer-affine folks, I'd reckon this threat is not that high up the list. On the hand, you want to bring yarnd to the average non-nerd user, so this threat might actually rank more important.
It's probably okay and safe enough to remove "remember me" entirely and just issue a long-lived session cookie and be done with that. Optionally, power users or the administrator could benefit from configurable cookie lifetime(s).
I'll check logging in etc tomorrow, time for bed lol π΄
EDIT: Okay, convo works properly now at least
126.0.1 π€£
126.0.1 π€£
127.0.1 (64-bit) tonight and tested and it worked just fine. Try upgrading and roll that commit back and see if it still repros? π€ I'm almost willing to bet this is a bug π
127.0.1 (64-bit) tonight and tested and it worked just fine. Try upgrading and roll that commit back and see if it still repros? π€ I'm almost willing to bet this is a bug π
* aa2f3ae9 - (HEAD -> main, origin/main) Workaround for this invalid Referer BS (6 seconds ago) <James Mills>
* aa2f3ae9 - (HEAD -> main, origin/main) Workaround for this invalid Referer BS (6 seconds ago) <James Mills>
>server {
listen 80;
server_name we.loveprivacy.club;
location / {
return 301 https://$host$request_uri;
#proxy_pass http://127.0.0.1:8000;
}
}
server {
listen 443 ssl http2;
server_name we.loveprivacy.club;
ssl_certificate /etc/letsencrypt/live/we.loveprivacy.club/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/we.loveprivacy.club/privkey.pem;
client_max_body_size 8M;
location / {
proxy_pass http://127.0.0.1:8000;
}
}
>
Referer is /post then consider that total bullshit, and ignore? π€
Referer is /post then consider that total bullshit, and ignore? π€
Referer header incorrectly?! π€
Referer header incorrectly?! π€
POST /post followed by a GET <from> where ever I was coming from. Hmmm π§ 
This is nuts π°
POST /post followed by a GET <from> where ever I was coming from. Hmmm π§ This is nuts π°
You can see here, at least, htmx knows what the current URL is:
HX-Current-URL: https://we.loveprivacy.club/conv/vcpt7gq
Referer: https://we.loveprivacy.club/post
But the freak'n browser is setting the wrong value for
Referer. There is simply no way to be on the /post endpoint normally anyway.
You can see here, at least, htmx knows what the current URL is:
HX-Current-URL: https://we.loveprivacy.club/conv/vcpt7gq
Referer: https://we.loveprivacy.club/post
But the freak'n browser is setting the wrong value for
Referer. There is simply no way to be on the /post endpoint normally anyway.
kept it in zone 2 pretty well
#running #treadmill
kept it in zone 2 pretty well
#running #treadmill
kept it in zone 2 pretty well
#running #treadmill
POST /post XHR (_that is being run by htmx_) should never, ever be Referer: .../post π€¦ββοΈ
POST /post XHR (_that is being run by htmx_) should never, ever be Referer: .../post π€¦ββοΈ
/post) on either the POST or the GET π€
POST /post request itself. That's the Referer that's looked up and used as the redirect.
POST /post request itself. That's the Referer that's looked up and used as the redirect.