This adds the following features to the postgres schema, which are propagated to the GraphQL API:
a private database schema for objects that shouldn't be exposed to the GraphQL API
a table for login credentials
functions for creating, logging in with, and testing login credentials
support for JWT (JSON Web Tokens)
Roles granting read access to all public objects
Roles granting row-based create/update/delete access to public objects, based on user's ID
This PR also cleans up an earlier DB migration file, fixes a bug with test data, and adds encrypted JWT support to the GraphQL service in docker-compose. The result of this mess is RBAC for our app :tada:.
Questions for you guys
Wanna jump on a call to talk about how the auth works or are you all good?
Do we want to make post reactions work like Slack (unlimited reactions, but only one of each type) or like Facebook (only one reaction total)? Partially related to #3 and #9.
Should we use usernames to identify users or is email address fine? Wondering how potential users would react to another app requesting their email address. (I went with email only because the docs I followed used email address as the unique user field.)
Do we care about federated logins for MVP1? Haven't started the research for it, don't know what it would take to add :man_shrugging:.
Partially closes #37.
This adds the following features to the postgres schema, which are propagated to the GraphQL API:
This PR also cleans up an earlier DB migration file, fixes a bug with test data, and adds encrypted JWT support to the GraphQL service in
docker-compose. The result of this mess is RBAC for our app :tada:.Questions for you guys
Bad screenshots because it's 12:30am