cybertooth-io / ermahgerd-rails-api-jwt Goto Github PK

New table off of a session that tracks user last seen. Can write this information using sidekiq task. What information to store with each record?

• ip_address - the ip address that the session originated from
• resource_path - the resource request path

• Logout Action
• Refresh token expiry should prevent access token refreshes but it doesn't
• Blacklist a refresh token
• Do we store the session creation payload in the user table
• Do we keep a history of sessions? Store host name, browser name, and browser signature?

It would be ideal to create a worker that tracks the success or failure of refresh tokens. On malicious refresh attempts, we should also find the Session from the supplied RUID and mark it as invalidated.

On Update, we should permit the password and password_confirmed fields. Put it in the self.updatable_fields override. Test it.

On Create, we should build a before a hook that automatically creates a password and password_confirmed field should it have not been passed in the payload. Put it in the self.creatable_fields override.

@bradf83 has recommended we just go full OAuth. Doorkeeper might be our ticket.

https://github.com/doorkeeper-gem/doorkeeper

WIKI: https://github.com/doorkeeper-gem/doorkeeper/wiki

It's always nice to have the last of some user. For example, last seen would be the USERS' most recently created SESSION_ACTIVITIES record. This could be a column derived in a VIEW and could easily be rendered as a relationship to a USERS record.

CREATE VIEW users_last_activities AS
SELECT users.id,
(
  SELECT MAX(sa.created_at) 
  FROM session_activities sa INNER JOIN sessions s
  ON sa.session_id=s.id
  WHERE s.user_id=users.id
),
...
FROM users

Other last ideas from projects I've worked on:

• last emailed
• last IP
• last browser

See https://github.com/mperham/sidekiq/wiki/Monitoring

Record the date that an account was activated on. Could also record when the account is deactivated. How about when reactivated?!? Vicious circle.

Originally posted by @nadnoslen in #3

https://github.com/stuyam/bootstrap-email/

Right now this simply raises a JWTSessions::Errors::Unauthorized

Originally posted by @nadnoslen in #3

This will be used to collect the user that is authenticated. Keeps it clean from the User model.

Make room for authenticating in one of two ways:

1. Cookie-based authentication will store your access token in a cookie and a CSRF token will be required for every PATCH/PUT/DELETE (CookieAuthenticationsController)
2. Token authentication will return you the access token which you are responsible for saving safely and then passing with every request to protected resources (TokenAuthenticationsController)

Worth a shot to see what the big deal is. Probably a performance blip

Search and replace: cppdist-com-rails

Originally posted by @nadnoslen in #3

We already store the RUID inside the database's Session table. When a request to invalidate occurs, we ask JWTSessions::Session to locate the refresh token by RUID and invalidate it. We could at the same time effectively expire/destroy the associated access token as the refresh token maintains a reference to the access token.

If that doesn't work, we could store both the RUID (refresh) & UID (access) in our Sessions table.

Check out https://github.com/tuwukee/jwt_sessions#flush-sessions in the jwt_sessions gem.

Is this even possible with JWTSessions? What do we need? I think we will need to save the UID (access token identifier) in the Sessions table.

Originally posted by @nadnoslen in #3

Invitation should expire.
Expired invitations should permit visiting user to click a link to send additional invitation to self.
New invitation_status enum on User model with the following choices: Uninvited, Invited, and Accepted. This is a system status, it will never be updated through the API

Administrator - no brainer. Can do pretty much everything CRUD-wise
Member or User or Authenticated User or Guest - a basic authenticated user that is restricted in some manner

Dan doesn't love the role named User because it seems redundant. Brad doesn't like Guest as he associates anonymous access with the phrase. Brad also dislikes Member.