I am invoking this endpoint using a CSRF token just like the Discourse UI does. Observing the backend logs seems to indicate that the session is deleted on some level, but this seems to have no effect on logging the user out. E.g. if I make this call to delete but do not wipe the user’s _t cookie, they are not logged out, even if I wipe the session cookie. It would seem that as long as I can wipe the browser’s _t cookie the user is logged out, and that making the call to DELETE /session/username is effectively useless. Is there any actual back end cleanup going on here, or is this endpoint just a way for the discourse backend to wipe the browser’s cookie?
AI-generated summary
The discussion revolves around the DELETE /session/username endpoint in Discourse. Kevin_Wildenradt is using this endpoint to log out a user but is finding that it doesn’t have the desired effect unless the _t cookie is also wiped. He questions the usefulness of this endpoint.
sam provides code references to explain the endpoint’s behavior and suggests that SiteSetting.log_out_strict might be what Kevin_Wildenradt is looking for. However, Kevin_Wildenradt clarifies that he only wants to log the user out on the current device, not all devices.
The conversation also touches on the idea of having unique login tokens per device, which would allow for individual revocation. riking mentions this, and sam notes that the user API provides unique tokens per device. Kevin_Wildenradt acknowledges the current limitation but finds the current system workable for his purposes.
I think what you are after is SiteSetting.log_out_strict
@sam thanks for your quick reply. I do not want log out strict. It logs the user out of every session on every device, I just want to log the user out on the current device. I am logging the user out of Discourse as part of my own site’s logout flow. Discourse is a subdomain of my domain, so my endpoint gets its cookies. My question is if it is good practice to simply set the user’s token cookie to empty myself without ever talking to discourse, which judging from the code you provided seems to be the case. Please correct me if that’s wrong, otherwise, thanks for your help!
Of course, it would be nice if every device got a unique login token; then they could be revoked/deleted individually.
With user api you get a unique token per device but protocol is somewhat more complex
@riking Thanks for bringing that up. It would be awesome if there were a way to invalidate a specific single session by making an API call from another back end server to the discourse back end, instead of having to redirect the client to the right discourse endpoint or wipe their token cookie. However the current system is workable for my purposes for now, and I am sure the discourse team is busy enough as it is. 