When i make a DELETE /users/sign_out request without any or with an already revoked JWT in the header, i get a 204 No-Content response.
This is the same status code i get, when i sign out a user with a valid token.
Is this intended behavior?
Shouldn't it return a 400 Bad Request or similar, when trying to sign out without any token or with an already revoked one?
Returning a 204 in either case could lead to the false assumption that the user is logged out / the JWT is invalid from now on, when actually none of that actually happened and could be dangerous if you still have a valid JWT in the browser.
For example if the developer forgets to send the JWT in the header and your frontend ajax relies on the 204 code to display smth. like "Successfully signed out." it will display the message, even if you're not signed out and the token is still valid and can be reused.
One can argue it is up to the developer to make sure to include the JWT in the request. But in development there's no easy way to make sure you actually send the JWT in the request other than by making a new authenticated request again and see if it passes or constantly checking your request header.
And then you still can't be sure if you're token got revoked or be sure if you actually sent a fresh token and not a stale one, because you're always getting the same status code in any of these cases.
Additionally a 204 is in the 2xx Success range. Returning a 204 when actually nothing successfully ( regarding a sign out / revoking a token ) happened, is misleading in terms of http semantics too, if you want to be nitpicky :-)
This behavior is actually in plain devise too. Tried to make an unauthenticated sign_out request like described above to a browser based app and it returns a 204 too. If you're using devise like usual in a browser based app the problem of missing auth is not a big problem there, since the session cookie always gets send with your request automatically.
So this issue is maybe smth. for the devise issue tracker, but i don't think anyone would give it a closer look since it's only a problem in an api app. So I thought it will maybe get more resonance here.
If you think its an issue worth opening on devise, please let me know. I will open it there too then..
Thanks!
When i make a
DELETE /users/sign_outrequest without any or with an already revoked JWT in the header, i get a 204No-Contentresponse.This is the same status code i get, when i sign out a user with a valid token.
Is this intended behavior?
Shouldn't it return a
400 Bad Requestor similar, when trying to sign out without any token or with an already revoked one?Returning a
204in either case could lead to the false assumption that the user is logged out / the JWT is invalid from now on, when actually none of that actually happened and could be dangerous if you still have a valid JWT in the browser.For example if the developer forgets to send the JWT in the header and your frontend ajax relies on the 204 code to display smth. like "Successfully signed out." it will display the message, even if you're not signed out and the token is still valid and can be reused.
One can argue it is up to the developer to make sure to include the JWT in the request. But in development there's no easy way to make sure you actually send the JWT in the request other than by making a new authenticated request again and see if it passes or constantly checking your request header.
And then you still can't be sure if you're token got revoked or be sure if you actually sent a fresh token and not a stale one, because you're always getting the same status code in any of these cases.
Additionally a 204 is in the
2xx Successrange. Returning a 204 when actually nothing successfully ( regarding a sign out / revoking a token ) happened, is misleading in terms of http semantics too, if you want to be nitpicky :-)This behavior is actually in plain
devisetoo. Tried to make an unauthenticated sign_out request like described above to a browser based app and it returns a 204 too. If you're using devise like usual in a browser based app the problem of missing auth is not a big problem there, since the session cookie always gets send with your request automatically.So this issue is maybe smth. for the
deviseissue tracker, but i don't think anyone would give it a closer look since it's only a problem in an api app. So I thought it will maybe get more resonance here.If you think its an issue worth opening on
devise, please let me know. I will open it there too then..Thanks!