holtalanm

then you're hitting the db on every request just to do auth.

if you _had_ to do that, I would put the counter into something like redis instead.

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.

that would be insanely illegal.

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.

i have never seen anything anywhere advocating for moving away from RSA. i'm curious to see what their sources are for this claim.

> 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.

my question here is:

are we really concerned about console tools overreaching their telemetry? personally, I am not.

I would love to know why others think this is some kind of huge issue, without a bunch of 'what-if' scenarios.

I liked the Gatsby comment/suggestion a lot better: a tool for automatically setting the do-not-track env flags for all different dev tools.

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.

> The site is called "JavaScript Is Weird", not "Weird Javascript"

am i being punkd?