discoursesso
discoursesso copied to clipboard
Connection lost during callback
Hello,
we are having a very weird issue with our Discourse SSO. Ever since one user logged out of impersonation, he is unable to log back in. I appended a screenshot of the Network Connections, the user was logged into Nextcloud previously.
The Server just closes the connection. I am unable to find any error log. Not inside any of the nginx proxies, not inside Discourse, not inside Nextcloud.
Interestingly it has nothing to do with the network or device. It is just this user that fails to log in.
I also tried clearing out the SSO Data from Discourse, changed the Email Adress to force creation of a new Discourse Account. The Problem still persists. This is also the reason I am posting the issue here and not on the Discourse Forum.
I have also made a post in the Discourse forum: https://meta.discourse.org/t/sso-callback-closes-connection-0-bytes-sent-by-server-used-logged-out-of-impersonation-previously/229064
Hi! Unfortunately I also do not have a clue why this would happen. Can you elaborate a little bit more about what happened?
I understood: A user in discourse impersonated another user and then logged out of discourse. Then we wanted to log back in with is actual user. He was still logged in in nextcloud so nextcloud did not ask for authentification but just provided the sso info for discourse. Then discourse just terminated the connection.
Is this correct?
Generally I do not think this is related to the plugin because the user could log in before and only could not log in again after impersonating someone in discourse. As far as I understood there where no changes to the nextcloud side, so the sso payload would be exactly the same as before, but discourse seems to have a problem processing it.
Is this correct?
Yes. But in general the problem persisted through multiple browser, sessions and computers. I tried logging in by myself, the account is completely inaccessible from SSO. Luckily the person is an admin and can use the Email Based Login as a workaround.
Howevery the issue might be unrelated to the impersonation thing. Might be a coincidence.
Generally I do not think this is related to the plugin
That was my though as well, until I deleted the SSO Data from the Discourse Account and logged in with a different Email address. My goal was to force creation of a new user and then merge them both together. But the same issue persists, Discourse still terminates the connection.
So either Discourse still retains some SSO information that breaks the process somehow. Or the SSO dataset sent by Nextcloud has some issue in it. I don't see any other possibility.
The Problem is now spreading to other user, I have contacted Discourse Support.
I think I found the issue: https://meta.discourse.org/t/yahoo-login-for-discourse/74060/13
Okay, I found a (temporary) workaround:
/lib/Controller/DiscourseController.php
, comment line 131 to 137:
foreach($allGroups as $group) {
if (!($this->groupManager->isInGroup($this->userId, $group->getGID()))) {
$remove_groups = $remove_groups.$group->getGID().',';
} else {
$add_groups = $add_groups.$group->getGID().',';
}
}
We have so many groups, that the callback GET parameters are just too long. I couldn't increase the buffer so far. nginx just does not output any error and discards the connection silently.
@soudis A proper solution would probably be supporting POST as callback.
Unfortunately there is no way to do a POST as callback within the discourse API.
I just updated the app to NC23 and add a new parameter to exclude groups from the SSO payload. So, pls update the app and check the exclude groups option.
And let me know if it works
Unfortunately there is no way to do a POST as callback within the discourse API.
Oh, no. That is not good. We might have to switch to saml if I cannot increase the header size :scream:
I just updated the app to NC23 and add a new parameter to exclude groups from the SSO payload. So, pls update the app and check the exclude groups option. And let me know if it works
App is updated and Box activated, it works now. Thank you!
We have switched to SAML anyway and the original issue was solved with the group exclusion option.