fix: Make don't create and save new refresh token with None when refr…

[juchajam]

fix: Make don't create and save new refresh token with None when refresh token is not included in the request.

[iMerica]

Sorry I don't understand the intent of this change. Can you explain it in very simple terms? The grammar of your PR title is confusing.

[juchajam]

Sorry I don't understand the intent of this change. Can you explain it in very simple terms? The grammar of your PR title is confusing.

Sorry for my bad English.

When USE_JWT is True and logout without refresh token, response.status_code will be 401.

And create new refresh token and blacklist it.
I fixed this part.

[bartvanandel]

I think I can see a couple code paths which would indeed cause trouble, all requiring that USE_JWT is True:

• JWT_AUTH_HTTPONLY set to True, but no valid cookie, hence RefreshToken(the_cookie) will fail.
• JWT_AUTH_HTTPONLY set to False, and the request body either not containing a refresh value at all, or an invalid or expired one, causing RefreshToken(the_value) to fail.
• JWT_AUTH_HTTPONLY set to False, and a request body of {"refresh": null}. This will actually result in a valid RefreshToken, but obviously a new one. In this case, HTTP 401 isn't even triggered before the proposed fix.

In all these cases, a new token is being blacklisted. This indeed shouldn't happen.

The proposed PR fixes all of the above, as far as I can tell. Looking at the code, more can be improved, e.g. DRY (in this block, about half the lines are duplicates, both before and after the PR) never mind, different error message required

A bit further down (outside of the current scope of the PR), there are some changes needed as well to cope with newer versions of rest_framework_simplejwt, which has now split "Token is invalid" from "Token is expired". I'll have a look myself, we're running into this right now.

[bartvanandel]

@iMerica Does the above answer your question?