[feature] Better diagnostics for unauthorized remote access.

[forry]

What is your suggestion?

Hi, from time to time when AF tokens expire to our private conan remote, the developers write to me about some package not being found on any remote. It would be very nice and helpful if e.g. the conan install could somehow tell the user that when it is checking a remote for some package the user is not logged in.

I don't know if there is an easy way for conan to know so I add some suggestions. Conan could see if the username is set to anything other than Anonymous. Conan could remember that the login command has been successfully run in the past for that remote. Or suggest it always for remotes that are not conan centre.

Have you read the CONTRIBUTING guide?

• [ ] I've read the CONTRIBUTING guide

[memsharded]

Hi @forry

Thanks for your suggestion.

from time to time when AF tokens expire to our private conan remote, the developers write to me about some package not being found on any remote. It would be very nice and helpful if e.g. the conan install could somehow tell the user that when it is checking a remote for some package the user is not logged in.

If this is happening the best approach is configuring the server so it raises auth errors. In that way if the token expires, the devs will not get a "not found", but get a new auth challenge and will be asked to re-enter credentials.

Conan could remember that the login command has been successfully run in the past for that remote. Or suggest it always for remotes that are not conan centre.

Conan actually remembers this, because it contains in its DB the previous user & token that were successfully used in the past. The problem is if they are provided to the server and the server decides to return a 404 instead, due to its security configuration, then the client takes it as "ok, it doesn't exist". The only possibility would be to force a hard auth challenge every time, but that would make the Rest API slower, so not worth it.

I'd then suggest the above, trying to change the server configuration so it actually requires auth instead of returning 404 when packages are requested.

[forry]

Thanks for your answer. I need some clarification. Does the "new auth challenge" mean the conan command will stop and await user input? This is not what I want.

Conan actually remembers this, because it contains in its DB the previous user & token that were successfully used in the past. The problem is if they are provided to the server and the server decides to return a 404 instead...

Does that mean that if the conan server (Artifactory) respond with e.g. 401 or 403 the conan output will be different (and also not stop to wait for user input)?

[memsharded]

Does that mean that if the conan server (Artifactory) respond with e.g. 401 or 403 the conan output will be different (and also not stop to wait for user input)?

If a 401 is returned, Conan will ask for credentials (from credentials.json, env-vars or if not, interactively).

403 will immediately return as Forbidden

Isn't this the behavior that you want?

[forry]

That's good enough if our admin wants to "unhide" the existence of the unauthorized resources for Artifactory, then the 403 would be perfect for users to see why the package was not found even when they are sure it is there, thus hinting them their access expired. If not it would be great if conan could check for this possibility even if the server returns the 404, but I guess it would need to run something like conan remote auth in the background (at least one time per install). I don't know if that is not much of a hassle, but it would be nice imho.

[forry]

Ok, so we've managed to set up AF to return 401. According to my admin, the 401 is more precise. The hide unauthorized resources option was already false, and it doesn't seem to work. The shame is that now the conan freezes on wanting the user input, which makes it impossible to fulfil when called from the cmake-conan script. So now I have to modify all the conan_provider.cmake scripts at all of our repos to give there -cc core:non_interactive=True, because if I would put it globally in the config that is downloaded by the conan config install no one would be able to log in without putting its pass as the arguments. This really sucks. Am I missing something or is this how it's going to be?

(edit) It seems that it doesn't freeze the cmake-gui as the early versions of conan1 did. So it might be fine after all. Now I wonder how that interaction works. Does the conan somehow know it is running under a process where it can't get the user input or is it cmake?

[memsharded]

But there is something in the flow that I don't understand.

If the developer is unauthorized, and you want them to be authorized, then credentials are necessary, why wouldn't you want them to enter the credentials and fail instead? why would you want to add core:non_interactive=True?

So if the developer is unauthorized, there are 2 possibilities:

• The server returns 404 to hide resources (typical security practice). But you say you don't want this behavior, because developers complain to you.
• The server returns 401, then the user needs to authenticate against the server, and enter the credentials, but not fail (I assume that you want the developers to have access to those resources). Why wouldn't you let developers to authenticate?

So I might be missing something here, could you please clarify?

[forry]

If the developer is unauthorized, and you want them to be authorized, then credentials are necessary, why wouldn't you want them to enter the credentials and fail instead? why would you want to add core:non_interactive=True?

When you run conan install from a cmake dependency provider from a cmake-gui - the most used case in our company. You can't give the credentials and you want it to fail in a way that hints the developer that the package was not found not because it is not there but because he is not authenticated (his token expired). So then the dev will open shell, log in to conan server, hop back in the cmake-gui, and run the configure again.

As I've said in the edit before, my big concern was that cmake would freeze like it did some years ago when we first used this approach, but it seems that it works fine now. I don't know how but if I don't need to add core:non_interactive=True to every customized conan-cmake deps provider I'm quite happy.

But I'd like to know why it doesn't freeze the cmake-gui without the core:non_interactive=True, when conan install would be hanging on the "enter password:", and if it is something that we can rely on in the future.

[memsharded]

Thanks very much for the feedback.

It is indeed a bit surprising that in GUI mode won't freeze in the same way as the terminal, there is nothing different in Conan there, I think it should behave the same, so not very clear why it won't freeze (I know it is not that easy to verify, as it is not that tokens expire continuously).

In any case, I am having a further look, reviewing the whole authentication process, and will reconsider if there are ways this could be improved for a better UX. Cannot guarantee, this might be challenging to change as it could break existing users, but lets have a look.

[forry]

Many thanks!