I appreciate the work this author does to compile these posts, but man, every time I visit his site, I get frustrated that there’s no way to stop the map animations to inspect in detail what has actually changed. Invariably, I get frustrated by the constant flashing back and forth and just close the tab without getting the information I’d actually like to get.
“I don’t like to waste bytes” isn’t exactly a great reason to write off a widely accepted and deployed spec for transmitting data in a trustworthy manner and instead write your own implementation, which most likely hasn’t considered all the attack vectors the JWT (and broader JOSE) spec has considered and accounted for.
I get the motivation — and I hesitate a little bit to say this — but it’s 2019, and a few “wasted” bytes on your auth token are less than inconsequential in a world where your front-end codebase mostly like “wastes” thousands (if not millions) of bytes.
When it comes to securely transmitting data, it most often pays to lean on the work and research of others.
I've browsed hundreds of thousands of websites and used a computer daily for the better part of my life...and it took me ten seconds to figure out how to even scroll the horizontal version. PLEASE stop breaking scrolling, people.
VitalSource Bookshelf is the world's #1 digital content platform, serving more than 25 million users on over 7,000 campuses in 200+ countries with native apps running on iOS, Android, Mac OS X, Windows, as well as directly through the Web.
Our platform and APIs serve hundreds of millions of requests per day to meet the needs of those students — along with the largest institutions and publishers from around the globe — while exceeding 99.99% uptime and consistently handling exponential year-over-year growth.
Well, there are a number of reasons, but let me give you one of the more important ones:
If a browser were allowed to make cross-origin requests without restrictions, any site could take advantage of a user’s active session on any other site to perform unapproved actions on that user’s behalf. Without CORS, for instance, if you came to my site with an active Facebook session, I could get information about your account (by making cross-origin requests to Facebook) that I wouldn’t otherwise have access to. Or, if I were feeling a bit more nefarious, I could change information — possibly your password and gain control of your account.
The possibIlities for bad actors to do these types of things is also part of the reason CORS requests don’t include most headers by default, and you have to be very explicit about which headers to expose.