action #67381

Login on not possible (403 Forbidden)

Added by nicksinger over 1 year ago. Updated over 1 year ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Today, 2020-05-28 at 09:43 we got a report that our login is broken:

@here request for a helpful hint: works for me, logging in does not anymore (yesterday: good; this morning: fail): just replies with a `Forbidden` page. Even after starting a fresh browser and even after logging into bugzilla before. Any hints? Does this login work for you?

I could reproduce in my browser too. Haven't checked server logs yet. Maybe related to the IDP move?


#1 Updated by okurz over 1 year ago

  • Status changed from Workable to In Progress
  • Assignee set to okurz

Logged in sessions are still active so most of our users should not be affected unless they select to delete their session cookies or are inactive for long. I can also reproduce the issue in a private browser window reaching the "Forbidden" page. Login on o3 still works as well as on other instances so this is not a generic issue coming from the server but something about our instance. The "simple approach" of restarting just the webui daemon does not help.

#2 Updated by okurz over 1 year ago

  • Status changed from In Progress to Workable
  • Assignee deleted (okurz)

I could not find anything obvious in neither the openQA logs e.g. using journalctl -u openqa-webui nor grep '$my_ip.*\(May 28\|28/May\)' /var/log/apache2/{openqa.access,access,error}_log. other servers are fine, restarting webui and apache2 does not help. To me this looks like a problem with the external openID provider by MF-IT . But as it is Thursday and we have the SUSE-IT maintenance window I guess we just need to wait 2h anyway before we raise the alarm.

#3 Updated by nicksinger over 1 year ago

  • Status changed from Workable to Feedback
  • Assignee set to nicksinger

OSD had an entry in /etc/hosts pointing to With this I could finally reproduce the issue myself:

openssl s_client -showcerts -connect -servername < /dev/null

I now removed that line now and login works again.

#4 Updated by Xiaojing_liu over 1 year ago

This issue happens again in and o3.

#5 Updated by okurz over 1 year ago

  • Priority changed from Immediate to Normal

I doubt this is the same issue now as it concerns all openQA instances. Not sure why nicksinger set this ticket to "Feedback" but certainly the immediate issue was fixed last week with his mentioned changes. What seems to have happened now is that the upstream openID provider has been switched off completely. See #66703 for this

#6 Updated by okurz over 1 year ago

  • Status changed from Feedback to Resolved
  • Assignee changed from nicksinger to okurz

Let me update here. I doubt the very same issue reappeared but what was needed on top to fix the login for now is to allow OpenID login via POST as well. This has been deployed to o3 and osd in the meantime after initially done as hotpatch.

Also available in: Atom PDF