Hrm, I'd support that, but it's up to ttx. In this specific example, you could make the same call without a tenant to verify that authentication is succeeding, but then the only possibility for raising a 401 is that you're not authorized on the specified tenant... so I don't see any unnecessary exposure. However, I'd +1 for correcting it as part of this patch (I'd rather be on the safe side); it's not an issue worth distinctly tracking, IMO. Here's the line referenced above:
Hrm, I'd support that, but it's up to ttx. In this specific example, you could make the same call without a tenant to verify that authentication is succeeding, but then the only possibility for raising a 401 is that you're not authorized on the specified tenant... so I don't see any unnecessary exposure. However, I'd +1 for correcting it as part of this patch (I'd rather be on the safe side); it's not an issue worth distinctly tracking, IMO. Here's the line referenced above:
https:/ /github. com/openstack/ keystone/ blob/stable/ essex/keystone/ contrib/ ec2/core. py#L173
Looking through the same code, there's two other 401's that should really be 400's. There's also this:
https:/ /github. com/openstack/ keystone/ blob/stable/ essex/keystone/ contrib/ ec2/core. py#L115
... which I'm not sure represents an exposure or not. I'm guessing not, because either the auth will succeed or fail there without any granularity.