Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

read token from cookie #3050

Closed
mckinlde opened this issue Nov 13, 2023 · 2 comments
Closed

read token from cookie #3050

mckinlde opened this issue Nov 13, 2023 · 2 comments

Comments

@mckinlde
Copy link

mckinlde commented Nov 13, 2023

Environment

  • PostgreSQL version: 15 (stable)
  • PostgREST version: 11.2 (stable)
  • Operating system: AMI Linux 2023 on prod, macOS Monterey 12.7 in dev.

Description of issue

After literature review, it seems that to implement cookie-based auth requires a reverse proxy server for the sole purpose of handling requests. Specifically, a reverse proxy just for reading cookies and remaking requests with an Authorization bearer=token header. This is despite PostgREST already being capable of issuing JWTs to a cookie directly as in this snippet, and suggested in JWT Security.

As a result, novice end users fresh off SQL User Management and Tutorial 1 are unable to implement a persistent auth system without opening another port, and taking on configuration of reverse proxies. Currently both those tutorials and the resulting client-auth login system can be implemented such that PostgREST is serving all requests directly.

It is currently supported to serve the JWT to an HttpOnly cookie with a minor addition to the login(text, text) function outlined in SQL User Management using a PostgREST-native response header setting implemented in #986, but once that is done there is not a way to configure client-auth to check in a location other than the Authorization header for the JWT. With a configuration setting to read JWTs from a cookie, these users could secure their web sessions with only the PostgREST server.

This issue has been previously discussed in 2016 and 2017, specifically for the purpose of cookie-based auth.

Expected behavior

The Custom Validation section, or possibly a tutorial 2, would describe configuring the SQL User Management system to issue and check JWTs as cookies.

vs actual behavior

Issuing JWTs to cookies can be implemented in SQL User Management's login() function per the snippet, but a separate reverse proxy server must be configured and maintained to transcribe tokens from cookies to Authorization headers on all incoming requests.

(Steps to reproduce: Include a minimal SQL definition plus how you make the request to PostgREST and the response body)

Minimal SQL definition is more or less the content of SQL User Management and the snippet. The issue is not that PostgrREST responds with a malformed body, but that it does not (to my knowledge) support checking for a cookie, instead of an Authorization header.

I try to include all relevant documentation and previous discussions in this post, but the result is wordy. Editorial suggestions welcome!

@wolfgangwalther
Copy link
Member

This is basically a duplicate of #3033

@wolfgangwalther wolfgangwalther closed this as not planned Won't fix, can't repro, duplicate, stale Nov 15, 2023
@mckinlde
Copy link
Author

This is basically a duplicate of #3033

Yes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants