Hello @sam ,
Thanks for responding! Glad to hear you have visibility on the issue.
Unfortunately we do not have a test-passed instance with SSO, as we’ve always stuck with stable. I do have a test-passed branch without SSO and there are no issues there.
EDIT: I’ll give it a go to see if I can get a test-passed instance with SSO running
Hey @sam ,
I was able to spin up a tests-passed instance and it didn’t seem to be an issue for me on tests-passed.
Was able to accept invites. Hope this helps!
I saw that Discourse had an update: 2.8.11: Security Release
Is there any chance this update fixes this issue? 
Yes we will update, thanks heaps for reporting, we will let you know once done. Give us a week or 2.
That’s awesome! Thanks @sam ! 
EDIT:
Just an FYI for others who may be experiencing this:
Version 2.8.11 of stable does not fix the issue. Clicking on Accept Invitation spews out a console log error now though:
PUT https://<DOMAIN>/invites/show/<INVITE_CODE>.json 404
The .json url takes you to:
// https://<DOMAIN>/invites/show/<INVITE_CODE>.json
{
"errors": [
"The requested URL or resource could not be found."
],
"error_type": "not_found"
}
Hi @hyphalos I’ve started taking a look at this today. I’m unfamiliar with our SAML setup so please bear with me.
This is a little strange, the “Accept Invitation” button should only show for logged in users. Can you please post a screenshot of what both logged in and logged out users see for a specific invitation, and also what options are you choosing for the invitation here:
Hello @martin !
Thanks for getting back to me. Sorry for the delayed response, I was out sick.
I did some more testing and what I’ve observed is after updating to v2.8.11 is that people can only accept an invitation once no matter the create invite settings. I’ve tested it with Arrive at topic, without arrive at topic, add to group, without add to group, etc. and people can only accept invites once. Is this intended behaviour?
What if a guest signs up but uses the same invite URL again, they’ll get stuck in the invite page (no redirection with arrive at topic). When they click Accept Invitation, this error pops up:
EDIT: Just wanted to add that if it is intended behaviour, there is no error that shows up that “You’ve accepted this invitation before” or something along those lines, or just redirect to wherever the arrive at topic is set to in the invitation.
Yes this is expected. Not the error, the part where they are unable to Accept Invitation multiple times. We discussed this over at New 'accept invitation' prompt feature causing issues with invitation links - #14 by martin where I did a fix, but I see now I will need to backport that fix to stable as well cc @sam
I just committed this fix to stable here:
Hey @martin !
Thanks again for the fix!
I’ve updated to 2.8.12 (which according to the commit tag in the admin panel includes the fixes) and I now see an error message (on a test account) for attempting to accept an invite I’ve once accepted on the test account:
Which is great!
Although as someone already logged in, I didn’t expect the “Okta SSO” button to be displayed. When the button is clicked, it loops into SSO and then brings be back to the invite page. As the user is logged in, shouldn’t the login button be hidden to avoid confusion?
This topic was automatically closed after 4 days. New replies are no longer allowed.
Yes I see the issue here now, we are still showing the Discourse Connect button even if the invitation has already been redeemed, and also for an existing user who has not redeemed the invite.
Invite not yet redeemed for existing user with DiscourseConnect enabled:
Invite already redeemed for existing user with DiscourseConnect enabled:
I think the correct thing is to hide the “Accept Invitation” button in the first case and the “Continue” button in the second case though I am not entirely sure, since going via the SSO login path accepts the invitation as well discourse/session_controller.rb at 13db6234940e50f66bc712a054003e362ae9dbcd · discourse/discourse · GitHub . @sam do you have any thoughts on this? I am just a little reluctant to make more changes to this UI/system at the moment…
The UI change sound pretty straight forward, I know how annoying this is, but if it is just hiding a button conditionally I recommend doing it, but not backporting.
The problem here for @hyphalos is that they are using stable, so in this case we would have to backport the fix.
So sorry, I think @hyphalos can simply use CSS here to work around, no? Hide the elements that are a problem? I would prefer not to backport anything we are too close to 3.0 release.
This is not really doable since a different button needs to be hidden depending on state:
However if its too risky before 3.0 then there is not much we can do here, I will just make the fix in main and it will trickle down to stable in the new year.
We are about to release 3.1, this is no longer relevant.
