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/

[blockchaind]

@TreyBoudreau checkout https://github.com/edgeflare/pgo. It's not yet as robust and reliable (please do give your feedback to make it so) as PostgREST, but enhances postgrest in a few ways:

• fixes JWKS: load public keys from a well known endpoint #1130 (JWSError JWSInvalidSignature)
• supports basic-auth (along-side OIDC auth and anonymous/public access

    rest:
      listenAddr: ":8080"
      pg:
        connString: "host=localhost port=5432 user=postgrest password=secret dbname=testdb"
      oidc:
        issuer: https://iam.example.org
        clientID: example-client-id
        clientSecret: example-client-secret
        roleClaimKey: .policies.pgrole
      basicAuth:
        admin: adminpw
        user1: user1pw
      anonRole: anon