You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Operating system: AMI Linux 2023 on prod, macOS Monterey 12.7 in dev.
Description of issue
Afterliteraturereview, 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!
The text was updated successfully, but these errors were encountered:
Environment
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 anAuthorization bearer=token
header. This is despite PostgREST already being capable of issuing JWTs to acookie
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 theAuthorization
header for the JWT. With a configuration setting to read JWTs from acookie
, 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
toAuthorization
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 anAuthorization
header.I try to include all relevant documentation and previous discussions in this post, but the result is wordy. Editorial suggestions welcome!
The text was updated successfully, but these errors were encountered: