discussion.stg.fedoraproject.org/login redirects me to id.stg.fedoraproject.org/login/gssapi/negotiate, whereupon entering my valid id.fedoraproject.org/login/gssapi/negotiate credentials returns “Authentication failure”. Considering that it links to the standard password reset URI, I presume that it utilises the same account system. [1] Consequently, does anyone know why it denies my credentials?
There is a separate account system for the staging side of Fedora Infra:
Have you created a staging account?
@glb, I haven’t; whether they are separate is what I wanted to know. Ideally, it should state that… If I ever ascertain where a report would be best submitted to about that, I’ll request a “Staging accounts only” banner.
However, if they are separate, why does id.stg.fedoraproject.org/login/gssapi/negotiate#:~:text=Forgot%20password? direct the user to accounts.fedoraproject.org/forgot-password/ask? (Surely, that shall request a password for a non-staging account?)
I can imagine that you have to be in a separate FAS (Fedora Account System) group for getting acces. Normally we do use single login over FAS.
To just read, you not need special access (login). Just for testing (create, edit, delete) you need a separate access in discourse on the staging instance. Generally this is solved with FAS. As you not are in such a special FAS group, the system believes you have a login issue and redirects you to the validation page.
It sounds like you found an error. You’d probably have to notify someone on the Fedora Infra team to get it corrected.
Maybe file a ticket here?: https://forge.fedoraproject.org/infra/tickets
@glb is correct - staging uses an entirely independent stack, so we can test changes to auth.
The redirect to prod is therefore a bug, and ticket would be appreciated if you have a moment to log it. Thanks!
Long shot, but there could be a relation to this: Making sure you're not a bot! (or a relation to the work that is done to fix it)
Given how the issue manifests (and depending on the configuration of course), I wouldn’t exclude the difference that occurred between Falkon and Firefox in my case (in one test: one working, falkon, and the other not, in parallel) can also occur between staging and non-staging
@ilikelinux, although I’d provided this a 50 % probability, versus a separate accounts stack, the actual answer appears to be that Staging utilises a separate accounts system. That is fundamentally incompatible with special group access, unless they implement another layer that binds accounts over there, via SSO, to production ones.
However, that would no longer resemble the production system, so it wouldn’t be useful.
We could do this… but staging is not a general place for anyone, it’s a place for infrastructure to test changes before rolling them into production. Anyone using staging should normally be someone in infrastructure or someone directed by infra to test something. When I point people to staging I try and note that it’s got a separate account system.
Where did you find the discussion.stg link? Possibly I mentioned it somewhere and didn’t note the diferent account system?
If so, sorry for any confusion there.
@kevin, I’ll keep discusstion at the Forgejo ticket hereafter, if feasible. Otherwise, we’ll duplicate our conversation in two places! 
well, sure, it’s not a secret or hidden or anything, but it’s definitely
not advertised for general use.
We do have staging banners in some cases, in some software it’s harder
than others to add such a thing. In this cause the identiy provider
there is a thing called ‘ipsilon’, but it’s old and not very actively
maintained and we plan to move away from it as soon as we can, so we
don’t want to spend a lot of time tweaking it.