Allow URL of private channel to resolve token properly if in subdirectory.

[SSchott]

Checklist

• I added a descriptive title
• I searched open requests and couldn't find a duplicate

What is the idea?

I am trying to setup a private development channel with quetz under a https://<FQDN>/quetz. Everyhting seems to be running fine if the channels are public, but when using a private channel with a token, it looks into https://<FQDN>/t/<TOKEN>/quetz/get/<CHANNEL> rather than https://<FQDN>/quetz/t/<TOKEN>/get/<CHANNEL>, which results in a 404. Any chance to make this also work with subdirectories?

Why is this needed?

Would allow a more flexible deployment in subdirectories rather than subdomains.

What should happen?

No response

Additional Context

No response

[travishathaway]

Hi @SSchott,

I'm wondering where you found the documentation that suggested you do that? I couldn't find anything in the quetz documentation itself. Is this just your best guess as to how it should work?

If I'm correct, I do not believe that quetz supports the "token-in-URL" form of authentication present in other places (e.g. anaconda.org).

There's a chance that the conda-auth plugin might allow you to do this because it doesn't use the same token-in-URL method. I would install this and then follow the instructions for using it with token based authentication:

• https://conda-incubator.github.io/conda-auth/user/#token-authentication

Please let us know if that works for you.

[SSchott]

Hi @travishathaway ,

Thanks for your input. The documentation around this is subpar I'd say, but it is implemented as you can see in the code here: https://github.com/mamba-org/quetz/blob/ce3aeb73c6f740fe618f2e36cddf376dd89394a9/quetz/main.py#L135 . This works properly with what is currently implemented in conda/mamba, i.e., <FQDN>/t/<TOKEN>/XXX

I actually managed to make it work by changing the regex rule there from "^/t/([^/]+?)/" to "^/quetz/token/([^/]+?)/", and adding https://<FQDN>/quetz/token/<TOKEN>/get/<CHANNEL> as my channel. This avoids conda managing the token, and passing the proper URL at the end. I still think that it would be more general to identify where t/<TOKEN> is located, and assume that the URL before that is where the repo is located, rather than using the FQDN by default.

[travishathaway]

I've reached out to the team maintaining quetz directly. I want to wait for their feedback before coming up with any plans for what should be done.

[SSchott]

Ok, thanks. I know that this is not the standard setup, but there might be other people out there with a similar "issue" as us, where getting a dedicated subdomain to host the repo was not what we were looking for.