Enable logging in with STI subclass #26
Closed
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
Say you have a `User` model using STI, with an `Admin` subclass. Previously, if an `Admin` attempted to log in, their id would be saved in the `admin_id` key. Then, when calling `authenticate_by_cookie(User)`, no user would be loaded, since it would look for the `user_id` key. This changes the session keys to use the `base_class`, which is the root class of the STI hierarchy. That way, for the above scenario, the ID is both saved and loaded using the `user_id` key, so logging in works. This shouldn't affect non-STI models, since `base_class` would just return the class itself
|
This is great! Very nice description and solution 👍 |
Merged
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.
Say you have a
Usermodel using STI, with anAdminsubclass.Previously, if an
Adminattempted to log in, their id would be saved in theadmin_idkey.Then, when calling
authenticate_by_cookie(User)(since we don't know the subclass of the user until the record is loaded), no user would be loaded, since it would look for theuser_idkey.This changes the session keys to use the
base_class, which is the root class of the STI hierarchy. That way, for the above scenario, the ID is both saved and loaded using theuser_idkey, so logging in works.This shouldn't affect non-STI models, since
base_classwould just return the class itself