There is a ticket filed against fedora-infrastructure we think it might be ipsilon or bugzilla. Filing the ticket here to get more understanding of the issue.
From the ticket:
When trying to log in into bugzilla.redhat.com as a Fedora contributor I get a 500 Internal Server Error.
This happened to me around 12:38 UTC today.
Checking the logs server side, I've found this traceback:
[Mon Aug 31 12:38:48.295630 2020] [wsgi:error] [pid 25509:tid 140039037421312] [remote 10.129.2.1:35188] [31/Aug/2020:12:38:48] DEBUG(providers/saml2/auth.py:176 Redirect.saml2login()): saml2: 'NoneType' object has no attribute 'get_login_handler' [Mon Aug 31 12:38:48.298334 2020] [wsgi:error] [pid 25509:tid 140039037421312] [remote 10.129.2.1:35188] [31/Aug/2020:12:38:48] DEBUG(ipsilon/util/errors.py:16 Errors.handler()): ['500 Internal Server Error', 'The server encountered an unexpected condition which prevented it from fulfilling the request.', 'Traceback (most recent call last):\\n File "/usr/lib/python3.7/site-packages/ipsilon/providers/saml2/auth.py", line 168, in saml2login\\n login = self._parse_request(request)\\n File "/usr/lib/python3.7/site-packages/ipsilon/providers/saml2/auth.py", line 75, in _parse_request\\n login = self.cfg.idp.get_login_handler()\\nAttributeError: \\'NoneType\\' object has no attribute \\'get_login_handler\\'\\n\\nDuring handling of the above exception, another exception occurred:\\n\\nTraceback (most recent call last):\\n File "/usr/lib/python3.7/site-packages/cherrypy/_cprequest.py", line 628, in respond\\n self._do_respond(path_info)\\n File "/usr/lib/python3.7/site-packages/cherrypy/_cprequest.py", line 687, in _do_respond\\n response.body = self.handler()\\n File "/usr/lib/python3.7/site-packages/cherrypy/lib/encoding.py", line 219, in __call__\\n self.body = self.oldhandler(*args, **kwargs)\\n File "/usr/lib/python3.7/site-packages/cherrypy/_cpdispatch.py", line 54, in __call__\\n return self.callable(*self.args, **self.kwargs)\\n File "/usr/lib/python3.7/site-packages/ipsilon/util/page.py", line 85, in __call__\\n return op(*args, **kwargs).encode(\\'utf-8\\')\\n File "/usr/lib/python3.7/site-packages/ipsilon/providers/common.py", line 105, in root\\n return op(*args, **kwargs)\\n File "/usr/lib/python3.7/site-packages/ipsilon/providers/saml2idp.py", line 82, in GET\\n login = self.saml2login(query, spidentifier, relaystate)\\n File "/usr/lib/python3.7/site-packages/ipsilon/providers/saml2/auth.py", line 177, in saml2login\\n raise cherrypy.HTTPError(500)\\ncherrypy._cperror.HTTPError: (500, None)\\n', '18.1.2']
@simo What do you think here?
Metadata Update from @ngompa: - Custom field component adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None
on the surface it looks like a configuration error as self.cfg.idp is NoneType
I can reproduce it regularly, but not 100% of the time either.
Seeing @simo's comment, I wonder if a configuration file is not being properly mounted in openshift or something fun like this.
Would someone know w/here/what I should check in the configuration for saml?
Right now, it's 100% of the time. The 500 is raised at:
https://id.fedoraproject.org/saml2/SSO/Redirect?SAMLRequest=hVJfb9owEH%2Fvp7D8TmICA2oRKlo0FandKuj20Jfqah%2FgybFT%2B0LXffo5WVEnLer8eL7fv7ubX%2FysLDtiiMa7kg8zwVkkcBqsd1jyV4z8YnE2j1DZWi4bOrgNPjcYiSWgi7L7KHkTnPQQTZQOKoySlNwub29kkQlZB09eecvPWM97p%2FmYBWLEQMllP816VfJP491kOnoSQgk1nRYzPd4JmGhxjmKiC5j0I7%2BfwieV%2Fo7lSfrKu9hUGLYYjkbht81NyQ9EdZR5%2FtTsfxlrIQuoD0CZ8lXepioeQcVM7Q1n6xgbXLt2vpTkRCEGYjYYDe%2BH53I0lePZQ7%2F%2BKo3bOKDO5UnP6GyH2gdI4%2F2BijIf9n8E8%2B32a75BbUIq9zPeBX80GsOXNOaSp152DcQu3yLwRQJ1K5ed5bD4f8gKCTQQtEnn%2Bd%2FYE1ctW7X16s5bo17Z0lr%2FchUQKDkY9ttk7LMPFdDHl9FWjB7sulZZt%2BuMhI44y9Pl5v%2Be7uI3&RelayState=https%3A%2F%2Fbugzilla.redhat.com%2Findex.cgi&SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1&Signature=cw502mns0AqrP6hJSVnZv6snogxAG054qG597U%2Fg1FFNDxv0L2%2FGjhk9zvfR2kzHNVfIBD%2BKRLf6Szih8DjrSbAuqKOCeO7rprR85PsO0du9VMGU9ykZjf6XJ7N7pRdTAs3kdBDcofXO0KknNDB2f5yqJVWSlRao%2FRZqXJ6082t64ReeVTNgeVSrZPzKh9ygy0l3fMz1KiH1%2Bj0DcdWSzY7jRQQZ1%2FKOmWWjKwreNCbR9cLtlL24lZqA%2Bv1Mv2HBidmzb4RmQghWQRFHlNL1TTbIfJQYvsG46XEx9qkqx48iXbn4d8FYS0E%2Bml4s8Y7YahdkYnb2YoHY%2BnyNHxW4iD%2FD8jtr0YyAF7DECnrkSyeOJa2KtY7iJdjXZWZRPSeN5Hp%2FTuXOT%2BTj4LxhQIfimK9wn7vxsP3X7AK%2Fd%2FZ5QLRTsRYTULTCf3eCSikpcFuF65GZHsegTdd2RmNDk9kSPHlFYIavDCQ4DDqfa8qWJs8fS1tnK4GrXKVPVnDD5xITYaG8M02%2FkTD5hh1W0swl4M8XJoYB9WQRYLm%2BVSRJoyd12cz%2B3RbwIDB7TkmGb8F1bLdjubzQai0WJqUg3ogaTsjsL29Sn8bspMJZyWapgOb2krh7LjlwYsJDHv1EeHueV4o8fDDFnruAHibgUC9P%2Fu6cBiRbykwjhG1QlsPmDGA%3D
If that can help
worksforme, sorry
still not possible to login to bugzilla redhat. As I am a daily user i think this is a blocking error.
by the way: Your website is marked as dangerous. by my browser.
Perhaps related https://pagure.io/fedora-infrastructure/issue/9287
Right now, I could reproduce it using a regular Firefox session and having a kerberos ticket. I could not reproduce it in a private session which asked me for my username and password.
Ok, of the three pods we were running, I was seeing the traceback only in one (though the configuration.conf looks the same in all three pods).
configuration.conf
I have deleted that pod, and I was able to login into bugzilla fine in a regular firefox session.
Could you check on your side?
On firefox 80.0 on Fedora 32 login is OK.
Will test other machine now.
On 9/1/20 11:46 AM, Pierre-YvesChibon wrote:
pingou added a new comment to an issue you are following: Ok, of the three pods we were running, I was seeing the traceback only in= one (though theconfiguration.conf`` looks the same in all three pods). I have deleted that pod, and I was able to login into bugzilla fine in a = regular firefox session. Could you check on your side? `` To reply, visit the link below or just reply to this email https://pagure.io/ipsilon/issue/343
pingou added a new comment to an issue you are following: Ok, of the three pods we were running, I was seeing the traceback only in= one (though theconfiguration.conf`` looks the same in all three pods).
Ok, of the three pods we were running, I was seeing the traceback only in= one (though the
I have deleted that pod, and I was able to login into bugzilla fine in a = regular firefox session.
Could you check on your side? ``
To reply, visit the link below or just reply to this email https://pagure.io/ipsilon/issue/343
login On Firefox 80.0 on Fedora 32 OK And on Fedora 33 OK too. No problems here now thanks.
Works fine now, thanks.
So this seems to not be an Ipsilon thing, then..
Metadata Update from @ngompa: - Issue close_status updated to: Insufficient data - Issue status updated to: Closed (was: Open)