-
Notifications
You must be signed in to change notification settings - Fork 225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Puppetdb Client *ALWAYS* uses token header even when cert/key is configured #3296
Comments
Previously token was always included in header. With this commit, try POST requests with token in header. If that returns 401 AND cert/key is configured, retry with auth header excluded.
I think what makes sense to me without introducing a new flag or something is:
|
I think what is a bit confounding is that if cert/key are invalid it will fail regardless of the token. If this were net-new I would just choose to prefer cert based auth when both are specified (IE only include token if cert/key are not specified). But in order to not break anybody relying on token being included in header even if certs are configured I wanted to not disturb that (specifically thinking of the case where you would prefer the identity piece of an rbac token if possible). I bring this up in response to |
I see, didn't realize there was a use case for both. In that case, I think at least just not including the token again if the token was invalid to avoid repeat failures seems reasonable. |
Previously token was always included in header. With this commit, try POST requests with token in header. If that returns 401 AND cert/key is configured, retry with auth header excluded. !feature * **Try cert based auth, failback to cert based auth for puppetdb** ([puppetlabs#3296](puppetlabs#3296)) When both a token and cert are specified, try using the token in the x-auth header for puppetdb POSTs. If that responds with a 401, try again with the token excluded.
I'm tempted to simplify this to follow the pattern in the puppetdb CLI. Specifically, if cert is configured, do not use token. I think that really simplifies things and is easier to understand. It also probably helps as a forcing function to ensure there is not ambiguous config files in practice. I can put up a separate PR with that approach and make sure to add a log message to warn that token wont be used when cert based auth is configured. |
Previously regardless of using certs any puppetdb token (either read from default location OR configured in settings) would be sent in x-authentication header for puppetdb requests. In the case a cert is configured, do not include this as the puppetdb endpoint will 401 in the case a valid cert but revoked token is presented.
Previously regardless of using certs any puppetdb token (either read from default location OR configured in settings) would be sent in x-authentication header for puppetdb requests. In the case a cert is configured, do not include this as the puppetdb endpoint will 401 in the case a valid cert but revoked token is presented. !bug * **Prefer cert based auth over token for puppetdb** ([puppetlabs#3296](puppetlabs#3296)) When both a token and cert are computed for puppetdb config, only use cert auth. This matches behavior of other puppetdb CLI tools.
(GH-3296) Prefer cert auth to token auth for puppetdb client
Describe the Bug
In the case a
token
AND cert based auth methods are configured for puppetdb, the client always includes the token in the header for puppetdb requests. This results in the case where puppetdb queries fail even when a valid cert/key pair is configured.Expected Behavior
Puppetdb client should be able to use either token or cert/key auth.
Options:
The text was updated successfully, but these errors were encountered: