secular12 / joist Goto Github PK

Apply all 'all' scopes permissions to admin role and all 'own' to customer role

Create the roles schema, with name field and the resolver for roles.

forgotPassword
accepts uid
This should create a new token
with the same expiration time as other verification expiration

verifyForgotPassword
accepts token, password, and confirmPassword
Updates the password and deletes the token

login
deletes any forgot password token

Requires #2

A way to sign-up/create a user

This would also create a token in the tokens db
requires use of bcrypt for encrypting passwords
schema & resolver set up
validations set up

pass iterator to help with iterated ids

A table to represent the various types of modules for role/permission purposes.

Columns:

• id [an application-wide unique module identifier, provided by the module]
• name [string, human readable]

Initial dataloaders for users and roles

Requires being logged in

updatePassword
input of password and confirmPassword
delete/revoke refreshToken?
returns message that it was complete

Start with the following roles:

• Admin
• Customer

Create a scopes seeder starting with the following:

• any
• own

Change roles and roles permissions seeders to set up seeder rather than testData

Add ability for a user to basically cancel new user verification and delete their account.

Requires issue #40

Apply admin role to admin id 1
Apply customer role to all other users

Add cors middleware, and possibly config

Requires #2 and #7 to be completed first

add refreshTokenExpiration to Auth config
Upon login create a refresh token and save to tokens table in db

Add and update queries and mutations to AuthModule to utilize the refreshToken, test expiration against the refresh tokens expiration date.

Add auth to the app config folder.
pass the config into the context, as a provider
First add jwtTokenExpiration and implement it into the login resolver

For roles/permissions

columns:

• id
• name

In the ContextModule take out the jwt.verify and place it into a provider

Requires #19 & #23

For role/permissions

columns:

• module_id [reference to the modules table, is the namespace for the token]

• scope_id [reference to the scopes table, is the namespace for the token]

• action [string / int, action identifier provided by the module, unique in the scope of the module]

• name [string, human readable name]

• Primary Key: [module_id, action]

Perhaps it is GUI capable for, but usually with a disclaimer that adding a new permissions is intended for Dev access only as it should only appear as an option if it is actually in affect.
Could also be a separate GUI build.
Possibility is a permissions file that is scanned and added, modified, etc. to the database.
Could also have Scopes/Modules/Permissions "tables" as part of a flat file rather than DB tables.

Requires #20

For roles/permissions

Columns:

• role_id
• module
• action
• scope

PK: [role_id, module_id, action, scope]

Add permissions seeder as part of the set up seeding

Start with the following permissions

action: read, module: users, scope: all
action: create, module: permissions, scope: all
action: delete, module: permissions, scope: all
action: update, module: permissions, scope: all
action: read, module: permissions, scope: own
action: read, module: permissions, scope: all
action: create, module: roles, scope: all
action: delete, module: roles, scope: all
action: update, module: roles, scope: all
action: read, module: roles, scope: own
action: read, module: roles, scope: all

...scopes and modules are included as part of permissions since they go hand in hand

Add a tokens table migration. First, figure out what columns are required.

Use a unit testing library to test the api. Set up the initial unit tests to test the various endpoints and compositions.

Make a roles migration. With the following initial name column

Add role_id to the users table as a foreign key

IP address is not a useful way of telling if something is suspicious, especially due to mobile devices, remove IP addresses to basically rely on the user-agent rather than the IP address.

For role/permissions

• remove role_id from users table

Columns:

• user_id [FK:user_id, unsigned]
• role_id [FK:roles_id, unsigned]

Add seeder for modules
Start with the following modules:

• users
• roles
• permissions