`pixi auth login` should fail if the credentials are wrong
Problem description
~ $ pixi auth login https://xyz.xyz --username user --password password
Authenticating with *.xyz.xyz
This currently works even though the credentials are incorrect.
Hmm, I think the biggest issue is that we don't have an endpoint to easily check, or do we?
trying to fetch the repodata could be an option?
Yeah although part of the problem is that we store auth per host and we don't know any channels that are available at that point. We could create a "check-auth" endpoint though, or a /me and try to standardize it
I have considered this feature for conda-auth:
- https://github.com/conda-incubator/conda-auth/issues/17
I don't believe there's a way to reliably implement this, but you could make it so that it gives a "best" guess 😄. Although it could be inconvenient, I think the best thing to do is just fail later and report an error message to the user saying they need to verify their credentials and login in again.
Or maybe just try out a couple of well-known endpoints for the most relevant hosters (prefix.dev, anaconda, artifactory, s3)?
For jfrog, I think the most reliable bet would be a HEAD to artifactory/api/repositories. For most other routes you need to either be an admin or have extra information up front, such as what repositories exist.
@wolfv would you be open to a PR for this? I have not worked on pixi/rattler before, but I think the change here would be a straightforward extension of the existing validation for prefix.dev?
Another option could be to add a --check-authenticated artifactory|prefix.dev|anaconda.org to explicitly force an authenticated check?
Maybe even a --check-channel https://my.server/api/my-channel that would just do a get/head on https://my.server/api/my-channel/noarch/repodata.json as this should always exist