Replies: 2 comments 3 replies
-
|
how can I get access to create a pull request with my change to be reviewed? |
Beta Was this translation helpful? Give feedback.
-
|
Good that you achieved what you want 👍 However, I don't think it fits in the common library, since it's a quite specific requirement and can have unintended side effects (e.g. allow a user that's actually deleted in DB). Most authentication frameworks work like this. But feel free to share your changes in the Discussions forum :) |
Beta Was this translation helpful? Give feedback.
-
|
I am trying to understand how this could have unintended side effects that couldn't be checked later during runtime. In the example you gave a quick query with a user id against the db could tell me that the user doesn't exist or any rows that have this id as a FK don't exist and I can simply return that. Making a call against Users if we just need the id seems wasteful. |
Beta Was this translation helpful? Give feedback.
-
|
Well, technically yes, but you'll only find out late in the request logic; and it'll probably be hard to tell if it's because the user doesn't exist anymore. Worse, in some cases, you may even be able to fully process the request (if the user itself is not directly needed).
IMO, that's a micro-optimization. Avoid that request won't really make a difference in terms of performance. |
Beta Was this translation helpful? Give feedback.
-
|
I would argue the user manager should be able to clear sessions for users that are no longer active and that whole problem goes away. if the user is logged in and their account is deactivate the user manager will go clear the backend session store and now they are no longer auth'd. I consider you adding this feature because again having to make DB reads each time a user makes a request is not scalable and takes away so much bandwidth from the DB. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I have a use case where I want to use this library to the get current user but I do not want to fetch the user object on every request. This increases the number of DB calls and sometimes just the user id which is stored in the transport is all I need. I have a change to allow the current implementation of current_user and current_user_token to support this new feature where if you set an optional boolean
id_onlythen it will avoid fetching the user object from the user_manager.Beta Was this translation helpful? Give feedback.
All reactions