proxyauthtype should only be considered during proxy auth (so, only after we've checked that proxy auth is allowed). This patch seems to unconditionally apply the parameter.

The lack of an else: case in the WebAuthType if block in login() bothers me somewhat. I don't think we're going to see an error from it, but WebAuthType can technically still be None here.

With the current code, the None case will error in the next block because we can only get the None when both WebCert and WebPrincipal are unset. Still, it feels a little fragile to me, since it relies on an inference about load_config's behavior.

In #2550, I was concerned about the case where web auth is based on a user cookie. However, I don't believe this will cause any issues because if we have a cookie then the user must already exist (in fact, _getServer will error if it does not before we even get to _assertLogin).

So, even though in the cookie case we're going to pass the plain username (no domain) with proxyauthtype=koji.AUTHTYPE_GSSAPI, it's all going to work out.

Added option to hub.conf + exception in else branch.

The proxyauthtype parameter is passed to ClientSession methods gssapi_login and ssl_login, but neither of these accept it. They should pass it though as they do proxyuser.

Adding the ProxyAuthType boolean config is reasonable, but it doesn't address the issue that the code is still accepting and honoring proxyauthtype even when proxyuser is not set (and therefore its associated access checks are not performed. I think that the if proxyauthtype block should be nested under the if proxyuser block.

Also, might be better to name the option AllowProxyAuthType for clarity.

:thumbsup:

Because there is a bug when: CLI current, older hub with sslLogin (https://pagure.io/koji/pull-request/3008#_3__36), I untag testing-ready until fix.

I guess, it should be self._callMethod instead of self.callMethod. Without '_' isn't working for QE.

updated

Tested:
WebUI login via certificate
HUB login via certificate (current and 1.26 client)
HUB login via user and password (current and 1.26 client)

Commit f5ba2a5c fixes this pull-request