chore: Refresh session on request #520
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
digitalcora
reviewed
Oct 11, 2024
digitalcora
approved these changes
Oct 11, 2024
|
@digitalcora Just realized that there is some |
This reverts commit 879513c.
|
If you express it this way it may work better: - @idle_time Application.compile_env!(:screenplay, __MODULE__)[:idle_time]
+ @idle_time Application.compile_env!(:screenplay, [__MODULE__, :idle_time])The difference should be that with the latter, |
digitalcora
added a commit
to mbta/screens
that referenced
this pull request
Jan 13, 2025
Using the admin UI was previously plagued by auth errors that would occur after just a few minutes of idle time and required refreshing the page, losing any work in progress. These changes should improve how we handle authentication, allowing an admin to be idle for up to 30 minutes and signed in for up to 12 hours before needing to reauthenticate, following the TID Session Management guidelines and the prior art of mbta/screenplay#520.
digitalcora
added a commit
to mbta/screens
that referenced
this pull request
Jan 13, 2025
Using the admin UI was previously plagued by auth errors that would occur after just a few minutes of idle time and required refreshing the page, losing any work in progress. These changes should improve how we handle authentication, allowing an admin to be idle for up to 30 minutes and signed in for up to 12 hours before needing to reauthenticate, following the TID Session Management guidelines and the prior art of mbta/screenplay#520.
digitalcora
added a commit
to mbta/screens
that referenced
this pull request
Jan 13, 2025
Using the admin UI was previously plagued by auth errors that would occur after just a few minutes of idle time and required refreshing the page, losing any work in progress. These changes should improve how we handle authentication, allowing an admin to be idle for up to 30 minutes and signed in for up to 12 hours before needing to reauthenticate, following the TID Session Management guidelines and the prior art of mbta/screenplay#520.
digitalcora
added a commit
to mbta/screens
that referenced
this pull request
Jan 16, 2025
Using the admin UI was previously plagued by auth errors that would occur after just a few minutes of idle time and required refreshing the page, losing any work in progress. These changes should improve how we handle authentication, allowing an admin to be idle for up to 30 minutes and signed in for up to 12 hours before needing to reauthenticate, following the TID Session Management guidelines and the prior art of mbta/screenplay#520.
digitalcora
added a commit
to mbta/screens
that referenced
this pull request
Jan 21, 2025
Using the admin UI was previously plagued by auth errors that would occur after just a few minutes of idle time and required refreshing the page, losing any work in progress. These changes should improve how we handle authentication, allowing an admin to be idle for up to 30 minutes and signed in for up to 12 hours before needing to reauthenticate, following the TID Session Management guidelines and the prior art of mbta/screenplay#520. Also, when an admin's session has expired and they try to load new data in the admin UI, they will get a message indicating they need to refresh the page, instead of the generic "an error occurred".
digitalcora
added a commit
to mbta/screens
that referenced
this pull request
Jan 21, 2025
Using the admin UI was previously plagued by auth errors that would occur after just a few minutes of idle time and required refreshing the page, losing any work in progress. These changes should improve how we handle authentication, allowing an admin to be idle for up to 30 minutes and signed in for up to 12 hours before needing to reauthenticate, following the TID Session Management guidelines and the prior art of mbta/screenplay#520. Also, when an admin's session has expired and they try to load new data in the admin UI, they will get a message indicating they need to refresh the page, instead of the generic "an error occurred".
digitalcora
added a commit
to mbta/screens
that referenced
this pull request
Jan 21, 2025
Using the admin UI was previously plagued by auth errors that would occur after just a few minutes of idle time and required refreshing the page, losing any work in progress. These changes should improve how we handle authentication, allowing an admin to be idle for up to 30 minutes and signed in for up to 12 hours before needing to reauthenticate, following the TID Session Management guidelines and the prior art of mbta/screenplay#520. Also, when an admin's session has expired and they try to load new data in the admin UI, they will get a message indicating they need to refresh the page, instead of the generic "an error occurred".
digitalcora
added a commit
to mbta/screens
that referenced
this pull request
Jan 21, 2025
Using the admin UI was previously plagued by auth errors that would occur after just a few minutes of idle time and required refreshing the page, losing any work in progress. These changes should improve how we handle authentication, allowing an admin to be idle for up to 30 minutes and signed in for up to 12 hours before needing to reauthenticate, following the TID Session Management guidelines and the prior art of mbta/screenplay#520. Also, when an admin's session has expired and they try to load new data in the admin UI, they will get a message indicating they need to refresh the page, instead of the generic "an error occurred".
digitalcora
added a commit
to mbta/screens
that referenced
this pull request
Jan 23, 2025
Using the admin UI was previously plagued by auth errors that would occur after just a few minutes of idle time and required refreshing the page, losing any work in progress. These changes should improve how we handle authentication, allowing an admin to be idle for up to 30 minutes and signed in for up to 12 hours before needing to reauthenticate, following the TID Session Management guidelines and the prior art of mbta/screenplay#520. This also revises and unifies how data fetching works in the admin UI, to allow showing admins a message indicating their session has expired when that happens (regardless of the interaction), rather than a generic error message.
digitalcora
added a commit
to mbta/screens
that referenced
this pull request
Jan 23, 2025
Using the admin UI was previously plagued by auth errors that would occur after just a few minutes of idle time and required refreshing the page, losing any work in progress. These changes should improve how we handle authentication, allowing an admin to be idle for up to 30 minutes and signed in for up to 12 hours before needing to reauthenticate, following the TID Session Management guidelines and the prior art of mbta/screenplay#520. This also revises and unifies how data fetching works in the admin UI, to allow showing admins a message indicating their session has expired when that happens (regardless of the interaction), rather than a generic error message.
digitalcora
added a commit
to mbta/screens
that referenced
this pull request
Jan 23, 2025
Using the admin UI was previously plagued by auth errors that would occur after just a few minutes of idle time and required refreshing the page, losing any work in progress. These changes should improve how we handle authentication, allowing an admin to be idle for up to 30 minutes and signed in for up to 12 hours before needing to reauthenticate, following the TID Session Management guidelines and the prior art of mbta/screenplay#520. This also revises and unifies how data fetching works in the admin UI, to allow showing admins a message indicating their session has expired when that happens (regardless of the interaction), rather than a generic error message.
digitalcora
added a commit
to mbta/screens
that referenced
this pull request
Jan 24, 2025
Using the admin UI was previously plagued by auth errors that would occur after just a few minutes of idle time and required refreshing the page, losing any work in progress. These changes should improve how we handle authentication, allowing an admin to be idle for up to 30 minutes and signed in for up to 12 hours before needing to reauthenticate, following the TID Session Management guidelines and the prior art of mbta/screenplay#520. This also revises and unifies how data fetching works in the admin UI, to allow showing admins a message indicating their session has expired when that happens (regardless of the interaction), rather than a generic error message. In support of the above feature being able to distinguish HTML page requests from API requests, this _also_ disentangles some pipelines in the router where some API endpoints were piped through both "browser" and "api", causing their format to be improperly set as HTML.
digitalcora
added a commit
to mbta/screens
that referenced
this pull request
Jan 24, 2025
Using the admin UI was previously plagued by auth errors that would occur after just a few minutes of idle time and required refreshing the page, losing any work in progress. These changes should improve how we handle authentication, allowing an admin to be idle for up to 30 minutes and signed in for up to 12 hours before needing to reauthenticate, following the TID Session Management guidelines and the prior art of mbta/screenplay#520. This also revises and unifies how data fetching works in the admin UI, to allow showing admins a message indicating their session has expired when that happens (regardless of the interaction), rather than a generic error message. In support of the above feature being able to distinguish HTML page requests from API requests, this _also_ disentangles some pipelines in the router where some API endpoints were piped through both "browser" and "api", causing their format to be improperly set as HTML.
digitalcora
added a commit
to mbta/screens
that referenced
this pull request
Jan 24, 2025
Using the admin UI was previously plagued by auth errors that would occur after just a few minutes of idle time and required refreshing the page, losing any work in progress. These changes should improve how we handle authentication, allowing an admin to be idle for up to 30 minutes and signed in for up to 12 hours before needing to reauthenticate, following the TID Session Management guidelines and the prior art of mbta/screenplay#520. This also revises and unifies how data fetching works in the admin UI, to allow showing admins a message indicating their session has expired when that happens (regardless of the interaction), rather than a generic error message. In support of the above feature being able to distinguish HTML page requests from API requests, this _also_ disentangles some pipelines in the router where some API endpoints were piped through both "browser" and "api", causing their format to be improperly set as HTML.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Screenplay is very often left open in people's browser. This will eventually lead to an outdated session failing in our request pipeline and cause a CORS error due to a redirect. I followed this Notion doc to get a sense of what our session best practices are and that helped me find this PR. I followed in that PR's footsteps for the solution to our problem. We now set an idle time of 30 minutes (although the plug will prevent users from exceeding that) and a max session age of 12 hours.