Skip to content
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

Basic auth is not sent to registry with different domain #284

Closed
MrNocTV opened this issue Jan 16, 2023 · 8 comments
Closed

Basic auth is not sent to registry with different domain #284

MrNocTV opened this issue Jan 16, 2023 · 8 comments

Comments

@MrNocTV
Copy link

MrNocTV commented Jan 16, 2023

Hi, I use this docker registry UI and I have an issue...

Bug description

I use registry.com domain for the backend registry:2 and registry-ui.com for the docker-registry-ui.
After login on browser (browser shows a simple username/password form, it is closed after I successfully login with the registry:2.
But after that, requests to registry-ui.com get 401, I check the request headers, there is no fields regarding authorization or authentication.

Expected behavior

I think even though the domain is different, it should work because I have specified the registry url in the config file.

@kubal5003
Copy link

I also experienced this behaviour today and hence decided to deploy this on the same domain, but this has its own issues unfortunately.

@Joxit
Copy link
Owner

Joxit commented Mar 10, 2023

Hi, thank you for using my project and submitting issues 😄

Is your issue linked to this question from the FAQ ?

  • Why OPTIONS (aka preflight requests) and DELETE fails with 401 status code (using Basic Auth) ?
    • This is caused by a bug in docker registry, it returns 401 status requests on preflight requests, this breaks W3C preflight-request specification. I suggest to have your UI on the same domain than your registry e.g. registry.example.com/ui/ or use NGINX_PROXY_PASS_URL or configure a nginx/apache/haproxy in front of your registry that returns 200 on each OPTIONS requests. (see #104, #204, #207, #214, #266).

If this is the case, and as I said in almost all linked issues, this is a docker registry issue and it's not a part of my project. You may override the OPTION response from your registry (via your reverse proxy) and return a status code 200 instead of 401.
The UI itself cannot solve this issue...

@alexanderwolz
Copy link
Contributor

Hi @MrNocTV

I also experience kind of the same behavior. I solved this by setting up my proxy to serve all registry requests on the same domain. For example:

  • registry.com/ui -> joxit/docker-registry-ui:2.4.1 (with NGINX_PROXY_PASS_URL)
  • registry.com/v2 -> registry:2.8.2
  • registry.com/auth -> keycloak/keycloak:21.1.1 (redirect with CORS to authserver.com/*/protocol/docker-v2/auth)

So finally Safari and Firefox are working nicely now, but I have issues with Chrome and need to re-authenticate on every click. Maybe the description in #303 would help you?

How is your authentication setup in registry? via token or htpasswd?

@MrNocTV
Copy link
Author

MrNocTV commented Jun 1, 2023

@alexanderwolz
I couldn't find a solution so I have changed to use this repo instead
https://github.com/klausmeyer/docker-registry-browser

@alexanderwolz
Copy link
Contributor

Hi @MrNocTV
That project looks nice, too.

I have also started a side project for one of my customers using Angular and Bootstrap. It reduces HTTP traffic by caching tokens and tags. I recently published it as open source at https://github.com/alexanderwolz/registry-angular-ui (see also the images at Docker Hub)

You are welcome to check it out.

@Joxit
Copy link
Owner

Joxit commented Jun 1, 2023

Hi @MrNocTV and @alexanderwolz , I'm sad to see you go to different projects.

@alexanderwolz I've checked your project, it's a nice one and thank you for the credit 😄 Are you not afraid of the security breaches that storing passwords in local storage can cause? I had also thought about it but I found that the risk was too great. 🤔

@alexanderwolz
Copy link
Contributor

Hi @Joxit

It was a requirement to have a login screen and I also thought about it for a long time. I ended up saving the credentials base64 encoded with a valid period of 2h in a Token object that is encrypted with CryptoJS AES encryption and put in the local storage.

At least this approach works fine on all browsers whereas the Basic Auth approach does not work on Chrome (see #303 ) for my client's configuration. Basic auth struggles with 301 redirects on certain browsers.

@Joxit
Copy link
Owner

Joxit commented Jun 7, 2023

Okay I see, you are encoding the basic auth in your fronted with a secret. Good choice ^^

Yeah I did respond to your #303 issue, since I didn't succeed to reproduce your bug I wanted you to host an example but I didn't get a response and well... You preferred to create your own project instead.

Since the original issue here didn't get a response too and choose another project, I will close it.

@Joxit Joxit closed this as completed Jun 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants