watched the whole thing. was very informative. Actually havent used RSA in any capacity in years (AES is a lot easier to use), but always viewed RSA as a battle-tested encryption method/alg. I suppose with anything there are ways to misuse it, and RSA appears to be really easy to misuse.
> 1. Massively increases server strain and bandwidth usage
A short-lived JWT that fits into an HTTP Header is not going to _massively_ increase your bandwidth usage. At most, you will end up with a single refresh request every few minutes as each short-lived JWT expires.
> 2. Has problems with users less reliable connections (they'll be randomly logged out all the time)
Usually if your request failed due to a bad connection, the client wouldn't be designed to automatically log out the user. That would be just terrible UX.
> 3. Makes "Remember Me" style features impossible (unless you use a server-side store for that, which brings us back to it not being stateless)
Incorrect. A short-lived JWT tied to a refresh token allows for a remember-me style feature by checking account access when issuing a new JWT token.
Yeah, if you need that kind of control over token access, then im not certain a jwt is the right tool for the job. For most use-cases a short-lived jwt is fine, as it expires in a matter of minutes, or even seconds, depending on configuration.
I can see that. I suppose when people say they need 'server-side session storage' I start thinking of app state, but in reality it could be as simple as storing a jwt refresh token that would be considered valid.
> in reality you still need server side state for useful features like logging out
im curious about this. normally 'logging out' just involves deleting the secure http-only cookie where the jwt was stored. is there something I'm missing here?
well, good luck getting buy-in from the cli tool devs, then? the other option requires absolutely zero buy-in from homebrew, gatsby, dotnet, or any other cli.
are there documented cases of these cli tools abusing their telemetry? are they entirely used to pinpoint performance issues and bugs within the tools that implement this telemetry tracking?
if it is the former, i can see there being cause for concern. if it is the latter, this is just pure fear-mongering.
you don't have to clone it. cloning the object and putting it in Vuex will still result in it being reactive.
`Object.freeze` is what I used. This causes Vuex to not traverse the object for changes. in my case, the objects I was pushing into the Vuex state were essentially immutable once I pushed them in, so this did the ticket.
well, that, and only pushing partials of the entire state, so the object model didn't get too unwieldy. To get the total state, i just replayed the changes on top of the base state. base state was reset once the number of changes got to a certain size.
> In my experience it has never, ever been the JS rendering layer which has caused unresponsiveness in an application.
Implemented a undo/redo stack on top of Vuex once that worked on some very large data structures.
Got unresponsiveness after only ~3 changes to the data. Purely due to how Vuex checks state for changes. No network, no database; purely in the frontend client.
Ended up needing to freeze the state as I pushed it into the Vuex store, so Vuex wouldn't check previously pushed state for changes.
My point is, there are multiple places where, if you are building an app of scale, you can run into client performance issues.
> Calling these things weird is fair enough but I can't help thinking this is code you'd never actually write outside of the context of a "Look how weird JS is!" post.
That is the whole premise of the site, though. They even say that these examples aren't common syntax or patterns before you start.
Doesnt this just mean that 80% of orgs that were hit with ransomware attacks just didn't bother to fix their infosec, and got hit again because they left the same holes open to be exploited?
Fool me once, shame on you. Fool me twice, shame on me.
if you _had_ to do that, I would put the counter into something like redis instead.