We are hoping to have a community where you only get an account as part of our product registration process, but we want to make the content of the forum visible so that way if people are trying to self help via google they can get an appropriate result while being unauthenticated. (also so we can potentially hit some SEO targets for our content)
Is this possible or is it a pipe dream? It seems like I’m not the first person to ask this question, or desire this product capability.
So the issue is that some users will be logged in to your cognito and you don’t want them to get a login dialog if they try to reply? I thought that with discourse connect that was the default behaviour.
You can make the site open to anonymous users and Google.
In an ideal world a user viewing Discourse that has an account should be logged in at all times, this way we can capture all their viewing data. I will be making it so if a product user clicks a link in the product to view the community it will auth them, as well as any links that the user should only see if they are auth’d elsewhere (account page, for instance).
However if a user attempts self help via Google and ends up in the community, we can’t capture that data until they attempt to interact directly with the community, even if they’re auth’d elsewhere in our system. It seems the only way to solve for that is to have the login_required site setting enabled, which if I understand effectively makes the site private.
Thanks. I did not know this. I am a CM trying to understand all the ins and outs of three seperate products and it is melting my brain trying to get the particulars down for each one! Expect to see a few more posts from me trying to sort everything out, and I thank you for being patient.
In the general case that is going to be impossible (how can you tell if an anonymous user has an account without prompting them to log in?). However, it should be possible to detect if a user already has an active session in your SSO site.
That topic is quite old, but I think the principle should still apply. Basically, add a URL with appropriate CORS support that returns a JSON response indicating whether the user has an active session. Then add some JS to your discourse theme that queries that URL and triggers the SSO process if an active session exists.
I’m afraid the general answer is still largely the same as last time
The spec I was talking about is OpenID Connect Session Management. Unfortunately, that iframe-based solution is becoming increasingly less useful because many browsers are now blocking third-party cookies by default. It now only works reliably if your identity provider and Discourse have the same ‘origin’.
As @simonk said, depending on your identity provider it might be possible to implement something custom via a theme component, but I’m not aware of any general solution we could add to Discourse itself.
You’re absolutely right that clicking ‘reply’ will trigger the login flow. And if DiscourseConnect (or any other single login provider) is being used, then the Discourse login modal will be skipped
However, I think the OP wants to have people automatically logged in, without them needing to click reply or ‘login’. With that kind of setup, it would be totally seamless for users to move between the main site and the community. We’ve achieved this for a couple of customers, but these have been bespoke implementations which can’t be easily generalised.
To give an example of one approach: if your forum is on forum.example.com, and your main site is on example.com, then the forum is allowed to read cookies from example.com. So a theme component can check for the existence of a cookie and do something like this:
const cookie = require("discourse/lib/cookie").default;
if(cookie('name_of_example_com_auth_cookie') && !api.getCurrentUser()){
// User has an auth cookie for example.com. They are almost certainly
// logged in there, so let's run the auth flow
window.location = "https://forum.example.com/auth/oidc"
}
(various conditions apply here. e.g. the cookie must not be http_only, must not be a host-only cookie, etc.)
That is indeed the case. It’s good to know it’s possible, but custom.
Also since I did not know that a user hitting reply would skip the login dialog depending on implementation, that will alleviate a lot of my concerns in the first place. That is the major barrier to entry that I want to avoid, and I’m glad that it can be implemented.
Of course the data nerd in me wants the ideal version, and it’s possible we might aspire towards that. Knowing it’s possible for now is good enough. Thank you once again everyone for your time.
