271–280 of 361 posts
Earlier quoted context omitted.
There’s no security gain from going to HTTPS if the site is served over HTTP, but there’s a small speed hit.
If the browser sends a Referer header, the page the user is currently on will be sent over plaintext.
Earlier quoted context omitted.
> Just make sure you apply the data-no-instant tag to your logout link, otherwise it'll logout on mouseover. Logout links should never be GETs in the first place - they change states and should be POSTs.
POSTs are not Links. And Logout service is indempotent even if you can consider it changes the state of the system
Sounds too good to be true, but also brilliant. Curious what others think. What are the downsides?
Assuming you use the script as suggested, letting a 3rd party site know your stats (and users) sounds like a non-trivial downside. I'd surmise the author is benevolent, but if this were to be turned into a business, some kind of data play seems like the trivial next step.
Earlier quoted context omitted.
> Just make sure you apply the data-no-instant tag to your logout link, otherwise it'll logout on mouseover. Logout links should never be GETs in the first place - they change states and should be POSTs.
POSTs are not Links. And Logout service is indempotent even if you can consider it changes the state of the system
Not sure how I feel about this. I often hover over a link to see where it is linking to, see if it has a title, etc. But that's probably not typical of most users. And I don't do it on sites I use often and am familiar with.
I feel this fails a user expectation that simply hovering over a link doesn't inform the server of anything. It's curious you mention checking where links link to, because I think that's also another user expectation failure. The url that appears in the status bar below (or what was once a status bar) is not necessarily the link's true destination. You can go to any google search results page, hover over the links in…
The validity of that expectation died with the advent of web analytics probably two decades ago now. The wholly general solution is to disable javascript, possibly re-enabling it on websites you trust. Sites that break without js are oftentimes not worth browsing anyway.
Earlier quoted context omitted.
A logout action is idempotent, though. You can't get logged out twice. In my opinion, that's the use case for a GET request. I just checked NewRelic, Twilio, Stripe and GitHub. The first 3 logged out with a GET request and GitHub used a POST.
Idempotency has nothing to do with it. Deleting a resource is idempotent as well. You wouldn't do that via GET /delete A GET request should never, ever change state. No buts. Just because a bunch of well known sites use GET /logout to logout does not make it correct. Doing anything else as demonstrated in this and other cases breaks web protocols, the right thing to do is: GET /logout returns a page with a form butto…
This is a feature available on most web frameworks today (for example Link's prefetch on Next.js), but still could be very useful for smaller website and other static pages not using such frameworks. I'd be a little wary of using a script from an unknown person without being able to look at the code - I'd rather see this open source before using. Especially being free and MIT licensed, I don't see why it wouldn't be…