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

Feature/6207 Endpoint api/v1/sign_in now outputs randomized tokens in response upon sign-in #6216

Draft
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

7riumph
Copy link
Collaborator

@7riumph 7riumph commented Feb 6, 2025

What github issue is this PR for, if any?

Resolves #6207

What changed, and why?

How is this tested? (please write tests!) 💖💪

Note: if you see a flake in your test build in github actions, please post in slack #casa "Flaky test: " :) 💪
Note: We love capybara tests! If you are writing both haml/js and ruby, please try to test your work with tests at every level including system tests like https://github.com/rubyforgood/casa/tree/main/spec/system

Screenshots please :)

Run your local server and take a screenshot of your work! Try to include the URL of the page as well as the contents of the page.

Feelings gif (optional)

What gif best describes your feeling working on this issue? https://giphy.com/
How to embed:

very stranget

@github-actions github-actions bot added ruby Pull requests that update Ruby code Tests! 🎉💖👏 labels Feb 6, 2025
@7riumph 7riumph changed the title Feature/6207 Feature/6207 Endpoint api/v1/sign_in now outputs randomized tokens in response upon sign-in Feb 6, 2025
@7riumph 7riumph marked this pull request as draft February 6, 2025 23:17
@7riumph 7riumph changed the title Feature/6207 Endpoint api/v1/sign_in now outputs randomized tokens in response upon sign-in Feature/6207 Endpoint api/v1/sign_in now secured via randomized tokens in response upon sign-in Feb 6, 2025
@7riumph 7riumph changed the title Feature/6207 Endpoint api/v1/sign_in now secured via randomized tokens in response upon sign-in Feature/6207 Endpoint api/v1/sign_in now secured with randomized tokens in response upon sign-in Feb 6, 2025
@7riumph 7riumph changed the title Feature/6207 Endpoint api/v1/sign_in now secured with randomized tokens in response upon sign-in Feature/6207 Endpoint api/v1/sign_in now outputs randomized tokens in response upon sign-in Feb 6, 2025
@7riumph 7riumph requested a review from xihai01 February 6, 2025 23:27
@xihai01
Copy link
Collaborator

xihai01 commented Feb 7, 2025

looks good to me so far 🔥

I think instead of storing the token and refresh token as plaintext in the db, we can store it as a hash
like what shen suggested

Then the client would be provided the plaintext versions of the tokens and whenever they call the api, the hash versions will be compared

@@ -2,6 +2,10 @@ class Api::V1::Users::SessionsController < Api::V1::BaseController
def create
load_resource
if @user

@user.regenerate_session_token!
@user.regenerate_refresh_token!
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't do this twice?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is actually for two separate tokens. The plan is the session_token expires quickly and is repeatedly replaced for as long as the refresh_token is valid to maintain access.

@@ -81,10 +81,13 @@ def recently_unassigned_volunteers
# receive_email_notifications :boolean default(TRUE)
# receive_reimbursement_email :boolean default(FALSE)
# receive_sms_notifications :boolean default(FALSE), not null
# refresh_token :string
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe make a new type of user, ApiUser?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking into this, may complicate authorization. I'll just create a completely new table for api/v1 credentials so the user model and roles inheriting from it aren't overloaded.

Additionally, will attempt to do more compartmentalizing this PR through a concern :)

after_create :skip_email_confirmation_upon_creation
after_create :create_preference_set
before_update :record_previous_email
has_secure_token :token, length: 36
has_secure_token :refresh_token, length: 36
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

36 what? seconds, minutes, days, weeks?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Vague syntax refers to token length, in this case. The token is 36 characters long.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ruby Pull requests that update Ruby code Tests! 🎉💖👏
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Enhance endpoint security for /api/v1/users/sign_in with randomization
3 participants