We have a discourse setup with the following configuration
Looks like a Bug - When the site is accessed as https://sitename/login, it is not showing the login modal.
Expected - When the site is accessed as https://sitename/login, it should show the login modal. This works correctly for https://sitename/signup where it shows the signup modal.
It has traditionally been that way as far as my memory goes!
For the sites requiring login i.e. private forums, anons are redirected to /login and from there, they have to click the log in button (generally displayed twice) to key in their login details and then they can continue from there.
I’m not sure if that’s a longstanding bug or something but it has been this way for the last 1 year at least.
This doesn’t sound intentional to me. The behavior of /login should be consistent regardless of how login_required is set. It should always show the login modal.
Are you sure that you’re logged out when you access that URL? If you’re logged in, well, you don’t need to log in.
You can also check in an incognito window or whatever your browser calls that.
Yeah, I tested this. Here’s a random login required site: https://forums.anki.com/login. Loading that in incognito does not make the login modal appear. However, loading https://meta.discourse.org/login in incognito does make the login modal appear.
So this is a confirmed bug @jomaxro?
I can’t think of a reason for the inconsistency, so yes, I’d say confirmed bug. But there could be history that I’m not aware of that would account for the difference…
@techAPJ can you add this to your list?
This is intentional as per:
Should we create a new site setting to control this behaviour or just make login modal show consistently for normal and “login required” sites alike?
Why can’t you simply link to the regular login page? Why do you NEED to pop the modal?
I’m reducing this to a feature request discussion, because I am very unclear here what the “problem” is.
We have similar issue at Travis CI community forum. We have only GitHub authorization enabled, because all our users obviously have Gtihub account. So it just opens a popup whenever user clicks on “Login” button. But when the login page is accessed directly by the link (e.g. https://travis-ci.community/login), the popup is blocked by browser as it isn’t triggered by user action. And login looks broken because of that.
The same happens when unauthorized user is directed to the new post page (http://travis-ci.community/new-topic?title=topic%20title). The forum tries to authorize the user, but popup gets blocked by browser and nothing actually happens.
This is an interesting and legit edge case, we should force full screen login for cases like this.
@techAPJ can you take this, we already have all the code for “full screen login” so if we do stuff like /new-topic it should force you through that flow and not pop windows up.
Done in:
I’ll try to repro this on my local dev instance and will push a fix.
I think that happens because the login needs to be on github, so it tries to open the oauth window to login with github, but the popup should be opened with a user action.
When it tries to open the popup when the user just accessed the link, I think the browser blocks the popup because the user haven’t clicked in anything yet (it needs a user interaction, otherwise blocks the popup).
If you try to access the login link (https://travis-ci.community/login) the popup is blocked, but if you click the login button at the top of the page, it isn’t blocked.
For the most common login flow, where the user can login with just the email (even if there social login options), like here in meta, the popup to another domain for the oauth is not triggered when the user access /login, but only after the user clicks in the social login option. The first “popup” that shows is just a modal in the same page.
A possible solution is to show in a modal, or in a page (if don’t want to be in a modal), that has a button (like Login with Github), and only after the user clicks this button the oauth window show (not the best solution, because there is one more step, but I don’t know if this is possible without another step).
Yeah we got to review our auth code and make sure we always check that a “click” happened prior to doing any pop up logging in.
I think just defaulting to “full screen log in” if there was no click should be fine as a general solution. (eg we could simply default to full screen, and then on the “github/google” etc. buttons opt for non full screen)
We now default to full screen login (unless there’s an explicit click) via: