search

jonra1993 / fastapi-alembic-sqlmodel-async

This is a project template which uses FastAPI, Pydantic 2.0, Alembic and async SQLModel as ORM. It shows a complete async CRUD using authentication and role base access control.
MIT License
879 stars 143 forks source link

Correct redis token initialization #30

Closed bazylhorsey closed 1 year ago

bazylhorsey commented 1 year ago

Currently a token cant be used unless it was set manually. If this if check is removed then multiple keys can be valid at the same time and share the expiry date under user:{id} This makes sure not more than one token can be used.

jonra1993 commented 1 year ago

Hello, @bazylhorsey thanks for the PR. The idea is that tokens are saved on Redis just if the password is changed, in such a way that they can invalidate as @dongfengweixiao suggested on this algorithm. https://github.com/jonra1993/fastapi-alembic-sqlmodel-async/issues/14#issuecomment-1271162874. There is not need to save all tokens on login.

What do you think?

bazylhorsey commented 1 year ago

I read through this, but still not seeing the purpose, why use redis and go through making a token only if they've changed their password before. If a user is logging in for the first time they'll never touch redis. I am thinking should be generally assured to be in the cache. Is this a particular case where you need the token stored somewhere centralized if they have changed the password? In the diagrams it says when they change passwords to give them new keys anyway. Is it intended that someone could have more than one set of keys at a time?

bazylhorsey commented 1 year ago

Wow okay, I'm starting to see it. You implemented redis specifically to capture if a password or other security related action is committed, that way you can invalidate other clients on the next request. If this is it, please close pr, sorry for wasted time.

dongfengweixiao commented 1 year ago

Wow okay, I'm starting to see it. You implemented redis specifically to capture if a password or other security related action is committed, that way you can invalidate other clients on the next request. If this is it, please close pr, sorry for wasted time.

hi, @bazylhorsey, Because jwt is stateless, the server should not normally spend time to determine whether a jwt token is valid.

If you need to modify the password, you should implement the whitelist mechanism. If you need to implement the offline of a single client, you should implement the blacklist mechanism. But in simple practice, the offline of a single client depends on a gentleman's agreement(The client directly deletes the valid token).

bazylhorsey commented 1 year ago

Thanks appreciate the clarification. I do not understand the blacklist functionality though, this is not in code from what I see, and I'm not sure what you mean by offline of single client.

dongfengweixiao commented 1 year ago

Thanks appreciate the clarification. I do not understand the blacklist functionality though, this is not in code from what I see, and I'm not sure what you mean by offline of single client.

emmm, like "logout".

jonra1993 commented 1 year ago

Hello, @bazylhorsey @dongfengweixiao thanks for the clarification.