Any way to redirect on JWSError JWSInvalidSignature?

[TreyBoudreau]

My web app uses PostgreSQL to create the JWT tokens processed by PostgREST. I deliver the application entirely via /rpc calls. If the shared secret changes, or the JWT becomes invalid in any other way, PostgREST returns JWSError JWSInvalidSignature to the browser. This appears to happen before PostgREST calls dp-pre-request, leaving me no way to redirect the browser to re-authenticate. Have I missed some option to capture this behavior?

It would suffice to have a way to tell PostgREST to proceed with the request as the anonymous user, but I don't see how to accomplish this.

[wolfgangwalther]

Have I missed some option to capture this behavior?

It would suffice to have a way to tell PostgREST to proceed with the request as the anonymous user, but I don't see how to accomplish this.

There is no way to accomplish what you're asking for.

If the shared secret changes, or the JWT becomes invalid in any other way, PostgREST returns JWSError JWSInvalidSignature to the browser. This appears to happen before PostgREST calls dp-pre-request, leaving me no way to redirect the browser to re-authenticate.

Did you consider setting up some error handler on the client for all requests, which catches the JWSInvalidSignature error and triggers the re-authentication?

[TreyBoudreau]

Have I missed some option to capture this behavior?
It would suffice to have a way to tell PostgREST to proceed with the request as the anonymous user, but I don't see how to accomplish this.

There is no way to accomplish what you're asking for.

Drats. Feature request?

If the shared secret changes, or the JWT becomes invalid in any other way, PostgREST returns JWSError JWSInvalidSignature to the browser. This appears to happen before PostgREST calls dp-pre-request, leaving me no way to redirect the browser to re-authenticate.

Did you consider setting up some error handler on the client for all requests, which catches the JWSInvalidSignature error and triggers the re-authentication?
I had not considered it. I believe I can do so, but that won't work if the browser tries to reload a page and provides the malformed cookie.

Since I already have nginx running interference to convert the magic cookie to the Authorization: Bearer header I believe I can have it convert the offending 401 response. That seals up the hole, at the expense of requiring a more complicated proxy configuration.

This line from the Providing HTML Content Using HTMX tutorial hides so many pitfalls:

To simplify things, we won’t be using authentication

Between the ability to intercept this or continue as anon, and the ability to take the authorization from a cookie as per #3033, one could actually connect the dots between the SQL User Management and Providing HTML Content Using HTMX tutorials.

Anyone got a favorite guide on learning enough Haskel to contribute?

[wolfgangwalther]

Anyone got a favorite guide on learning enough Haskel to contribute?

Yes, I did https://learnyouahaskell.com/