Hacker News Reader

Maybe it takes less than 2 hours to add such a configuration knob?

That’s a good idea except it is in another team’s service and I’m not very familiar with their code. But I can try

Well, the hard part isn’t actually the code change (reasonably obvious) it is deploying my own copy of their service…

Can you just set the local time two hours into the future?

Or modify the expiry time locally / not use the one from the token at all.

The token isn’t being verified in my service it is being verified in a remote service. I can’t easily change the clock on the remote service. It runs in a K8S pod and (AFAIK) K8S doesn’t support time namespaces. And even if it does, the pod is deployed by a custom K8S operator so unsure if I could make the operator turn that on even if it is available. And the remote service is a complex monolith which uses lots of RAM so trying to run it on my own laptop will be painful

Reminds me of the classic adage that "everything can be solved by another layer of abstraction, except for the problem of too much abstraction layers".

Or modify the token itself so it's no longer valid? (Although that might come back with "invalid token" rather than "expired token.")

Reply on news.ycombinator.com