Can't link a Bugzilla account with BBA

kparal commented

2022-02-07 14:26:20 +00:00

Owner

When I try to link my bugzilla account to BBA, I get the following error:

Login failed: Application failed during request deserialization: 32000: You have attempted to access the API either using an unsupported method or using one or more unsupported parameters. You must use the 'Authorization' header to authenticate to the API and you must remove all unsupported parameters from the query. The unsupported parameters are: Bugzilla_login, Bugzilla_password, Bugzilla_token, Bugzilla_api_key. See https://bugzilla.stage.redhat.com/docs/en/html/api/core/v1/general.html#authentication for details on using the 'Authorization' header. at /usr/share/perl5/vendor_perl/SOAP/Lite.pm line 2855.

This might be caused by bugzilla auth changes:
https://listman.redhat.com/archives/bugzilla-announce-list/2022-February/msg00000.html

This might also be further complicated by the fact, that redhatters can no longer login using username+password only. When I try to do that in bugzilla, I get an error:

To access Red Hat Bugzilla Stage you are required to login using 2 Factor Authentication. To do so you can enter PIN and Token in the password field or you can use the Red Hat Associate SSO.
This is because you have an account with elevated permissions.

When I log in using username+pin+token directly in bugzilla, it works fine. But it doesn't work in BBA, same error.

So, we need to fix account linking, and in case of redhatters, we possibly need to tell them to use pin+token instead of a password (needs verification).

When I try to link my bugzilla account to BBA, I get the following error: > Login failed: Application failed during request deserialization: 32000: You have attempted to access the API either using an unsupported method or using one or more unsupported parameters. You must use the 'Authorization' header to authenticate to the API and you must remove all unsupported parameters from the query. The unsupported parameters are: Bugzilla_login, Bugzilla_password, Bugzilla_token, Bugzilla_api_key. See https://bugzilla.stage.redhat.com/docs/en/html/api/core/v1/general.html#authentication for details on using the 'Authorization' header. at /usr/share/perl5/vendor_perl/SOAP/Lite.pm line 2855. This might be caused by bugzilla auth changes: https://listman.redhat.com/archives/bugzilla-announce-list/2022-February/msg00000.html This might also be further complicated by the fact, that redhatters can no longer login using username+password only. When I try to do that in bugzilla, I get an error: > To access Red Hat Bugzilla Stage you are required to login using 2 Factor Authentication. To do so you can enter PIN and Token in the password field or you can use the Red Hat Associate SSO. This is because you have an account with elevated permissions. When I log in using username+pin+token directly in bugzilla, it works fine. But it doesn't work in BBA, same error. So, we need to fix account linking, and in case of redhatters, we possibly need to tell them to use pin+token instead of a password (needs verification).

kparal commented

2022-02-07 14:26:45 +00:00

Author

Owner

[![link-error.png](/fedora-qa/blockerbugs/issue/raw/files/d9340982b571678d2999cae1c1c38b7ef1d00df9b1f5c3f4a656d846755038e9-link-error.png)](/fedora-qa/blockerbugs/issue/raw/files/d9340982b571678d2999cae1c1c38b7ef1d00df9b1f5c3f4a656d846755038e9-link-error.png)

kparal commented

2022-02-07 14:27:08 +00:00

Author

Owner

Issue tagged with: next

kparal commented

2022-02-07 14:27:19 +00:00

Author

Owner

Metadata Update from @kparal:

Issue assigned to kparal

**Metadata Update from @kparal**: - Issue assigned to kparal

kparal commented

2022-02-07 14:53:52 +00:00

Author

Owner

This might also be further complicated by the fact, that redhatters can no longer login using username+password only.

After debugging, this is not for all redhatters, just those with certain (not sure which) permissions. I have those, Frantisek doesn't (and he can log in just using username+password).

> This might also be further complicated by the fact, that redhatters can no longer login using username+password only. After debugging, this is not for all redhatters, just those with certain (not sure which) permissions. I have those, Frantisek doesn't (and he can log in just using username+password).

kparal commented

2022-02-07 14:53:54 +00:00

Author

Owner

Metadata Update from @kparal:

Issue untagged with: next

**Metadata Update from @kparal**: - Issue **un**tagged with: next

kparal commented

2022-02-07 14:54:28 +00:00

Author

Owner

Issue tagged with: next

kparal commented

2022-02-11 12:04:39 +00:00

Author

Owner

So, the current approach of verifying the user bz account with login and password is doomed, because bugzilla will no longer support this kind of authentication. Using bz api keys is also a non-starter, because it's several extra steps for the user, and I haven't found a way to actually figure out the user login (email) when using the api key. And we need the login to add the user to CC. So, bummer.

Please note that the whole point of verifying a user's login/email seems to be to then add him/her to CC. We already have the user logged in through FAS, so that serves as a spam protection. If we don't know users' bz login, we can't add them to CC, but that's the only loss, it seems.

Solution 1: Don't verify bz login, make the user CC manually
The simplest. Just thank the user after the proposal and ask her to CC manually.

Solution 2: Use fasjson service to get rhbz_email from FAS
Users can set "RHBZ email" value in FAS. It doesn't verify it against BZ, but it does verify that you own that email, so that seems good enough. If the user doesn't have it set, we can ask him to set it and then refresh our proposal page.

However, we don't get the rhbz_email value through flask_fas_openid module that we use in BBA. After talking to Fedora AAA folks, there is https://github.com/fedora-infra/fasjson project for querying FAS, which seems to be a bit early in development, but I tested it and it works (interactive api docs). However, rhbz_email value is not exposed currently, but should be once this PR is merged and deployed:
https://github.com/fedora-infra/fasjson/pull/298
The downside is that the service requires a Fedora Kerberos ticket, so we'd need to configure it on our server and also in the devel environment. Also, it's a one more service to depend on (and we'd need to handle the case when it's down).

Solution 3: Ask python-fedora to expose rhbz_email in flask_fas_openid
This would be ideal for us, we'd get that value when the user gets logged in. I'm not sure they'll want to forward it, though. I filed a ticket here:
https://github.com/fedora-infra/python-fedora/issues/230

I think I'll start with Solution 1, because the deadline is approaching (Feb 28th). And we'll then determine if we want to improve it and how.

So, the current approach of verifying the user bz account with login and password is doomed, because bugzilla will no longer support this kind of authentication. Using bz api keys is also a non-starter, because it's several extra steps for the user, and I haven't found a way to actually figure out the user login (email) when using the api key. And we need the login to add the user to CC. So, bummer. Please note that the whole point of verifying a user's login/email seems to be to then add him/her to CC. We already have the user logged in through FAS, so that serves as a spam protection. If we don't know users' bz login, we can't add them to CC, but that's the only loss, it seems. **Solution 1: Don't verify bz login, make the user CC manually** The simplest. Just thank the user after the proposal and ask her to CC manually. **Solution 2: Use fasjson service to get rhbz_email from FAS** Users can set "RHBZ email" value in FAS. It doesn't verify it against BZ, but it does verify that you own that email, so that seems good enough. If the user doesn't have it set, we can ask him to set it and then refresh our proposal page. However, we don't get the `rhbz_email` value through `flask_fas_openid` module that we use in BBA. After talking to Fedora AAA folks, there is https://github.com/fedora-infra/fasjson project for querying FAS, which seems to be a bit early in development, but I tested it and it works ([interactive api docs](https://fasjson.fedoraproject.org/docs/v1/)). However, `rhbz_email` value is not exposed currently, but should be once this PR is merged and deployed: https://github.com/fedora-infra/fasjson/pull/298 The downside is that the service requires a Fedora Kerberos ticket, so we'd need to configure it on our server and also in the devel environment. Also, it's a one more service to depend on (and we'd need to handle the case when it's down). **Solution 3: Ask python-fedora to expose rhbz_email in flask_fas_openid** This would be ideal for us, we'd get that value when the user gets logged in. I'm not sure they'll want to forward it, though. I filed a ticket here: https://github.com/fedora-infra/python-fedora/issues/230 ---- I think I'll start with Solution 1, because the deadline is approaching (Feb 28th). And we'll then determine if we want to improve it and how.

kparal commented

2022-02-17 13:40:31 +00:00

Author

Owner

PR for Solution 1 is in #234.

kparal commented

2022-02-21 09:03:31 +00:00

Author

Owner

Commit 665875e7 relates to this ticket

Commit [665875e7](https://pagure.io/fedora-qa/blockerbugs/c/665875e7) relates to this ticket

kparal commented

2022-02-21 12:39:07 +00:00

Author

Owner

Solution 1 is now deployed to production. The other approaches are not even possible yet (the tickets are still open), so I'll put this ticket on ice and re-evaluate it after a while. It would be nice to CC the user automatically, but it's not highly important, rather a nice-to-have feature.

kparal commented

2022-02-21 12:39:07 +00:00

Author

Owner

Metadata Update from @kparal:

Assignee reset
Issue untagged with: bug
Issue priority set to: Low (was: High)
Issue tagged with: enhancement

**Metadata Update from @kparal**: - Assignee reset - Issue **un**tagged with: bug - Issue priority set to: Low (was: High) - Issue tagged with: enhancement

kparal commented

2022-07-15 07:41:54 +00:00

Author

Owner

A note for future self: If we move to OIDC, which is planned in #230, that might also change this problem (perhaps rhbz_email will be accessible that way).

A note for future self: If we move to OIDC, which is planned in #230, that might also change this problem (perhaps `rhbz_email` will be accessible that way).

kparal commented

2025-09-03 12:30:50 +00:00

Author

Owner

Metadata Update from @kparal: