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

Support WALRUS (Postgres RLS) Integration with Realtime Server #51

Open
w3b6x9 opened this issue Oct 22, 2021 · 6 comments
Open

Support WALRUS (Postgres RLS) Integration with Realtime Server #51

w3b6x9 opened this issue Oct 22, 2021 · 6 comments

Comments

@w3b6x9
Copy link
Member

w3b6x9 commented Oct 22, 2021

Feature request

Is your feature request related to a problem? Please describe.

Currently, Realtime server sends all database changes to all connected clients despite Postgres Row Level Security policies. This poses security concerns when developers wish to broadcast database changes containing sensitive data to an authorized subset of connected clients based on tables with RLS enabled and row security policies.

Realtime server will integrate WALRUS (Write Ahead Log Realtime Unified Security), which means there are some changes that lib clients need to make in order to support this new security functionality.

Describe the solution you'd like

The following changes will need to be made:

  • Pass user auth token, if available, as channel params with key user_token when subscribing client to Realtime channel.
  • Update Realtime transformers to pass through changes when they're already arrays.
    Realtime w/ WALRUS will pass Postgres array types as [1, 2, 3], _int4, and ["a", "b", "c"], _text, instead of "{1,2,3}" (_int4/_text) so this can be forwarded without any transformations. However, clients should maintain backward compatibility so they should still be able to handle stringified Postgres array (e.g. "{1,2,3}") cases.

The changes have already been applied to supabase-js and realtime-js and their PRs can be referenced while making the necessary changes:

  • Passing user auth token as user_token

feat: add user_token when creating realtime channel subscription supabase-community/supabase-py#270

  • Update Realtime transformers (including bug fixes)

feat: update transformers to accept already transformed walrus changes supabase-community/realtime-py#50

fix: error parsing JSON when transforming array data types supabase-community/supabase-py#113

The bug fixes include longstanding issues with transformers in realtime-js where range types are first JSON parsed (which results in an error sometimes due to Postgres' range exclusive and inclusive bounds) and how stringified (e.g. "{1,2,3}") array types are split (can't always split on "," in cases like _daterange). Please see PR for additional context.

Additional context

We're looking to launch WALRUS in Realtime at the end of November, and all developers using the JS client will have to do is version bump their supabase-js to v1.2.0, which contains all the changes described above.

Please reach out if there's any questions and definitely tag me to confirm PRs if you'd like! Thank you!

@J0
Copy link
Collaborator

J0 commented Oct 26, 2021

Hey @w3b6x9,

Thanks for posting this! Will give this a read and reach out if needed :)

@J0
Copy link
Collaborator

J0 commented Jun 8, 2022

It's been a while since this was posted. Just adding context here in case anyone ones to pick this up -- off the top of head things we need to get this in.

  1. Patch realtime-py so that the installation works across platforms
  2. Update GoTrue-py(and other libraries) to be able to emit events and notify all subscribers when events come in
  3. Convert Supabase-py to run realtime-py on a separate thread or process so that realtime-py can run concurrently with the rest of the libs.

There are probably more tasks as well feel free to add/comment below

@anand2312
Copy link
Contributor

We need some more discussion on the implementation of realtime-py. Imo we should only provide an async interface (because the underlying websockets stuff is inherently async). Right now we do some hacky wrap-every-async-call stuff but I think that'd just be an easy spot for bugs to arise, and if we expose that as public API we'd be obligated to provide support for it.

@J0
Copy link
Collaborator

J0 commented Jun 8, 2022

That makes sense -- I'll open up a doc or a thread of sorts for further discussion

@anand2312 anand2312 mentioned this issue Jul 11, 2022
@J0 J0 transferred this issue from supabase/supabase-py Jan 23, 2023
Copy link
Contributor

github-actions bot commented May 2, 2024

This issue is stale because it has been open for 365 days with no activity.

@github-actions github-actions bot added the Stale label May 2, 2024
@J0
Copy link
Collaborator

J0 commented May 7, 2024

Wow this is old and I confess I don't recall the context around this - @mansueli just looping you in case relevant to the implementation of the lib

@github-actions github-actions bot removed the Stale label May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants