You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tell us about your request
Currently if DD gets multiple options for proxy auth it will just elect Basic per the docs. We have multiple w Basic as a fallback and they are ordered by pref, but that is more a convention than an enforced standard.
Be nice for the new support to mirror how Chromium approaches this problem with a weighting so it tries the most secure first and then works it's way back to Basic.
Which service(s) is this request for?
Docker Desktop
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Multiple authenticate headers are often used on big central proxies and per the docs (and from what i see in deployment feedback) it just means that unless we force using kerb/ntlm folks are just stuck on basic.
Are you currently working around the issue?
We just cover the proxy auth prompt in user docs, but because we have multiple headers it means we really can't take advantage of SSO w/o forcing on install which we only loosely control. As long as they auth to the Proxy correctly the cred will be cached and they will be good till they change the password so the impact is pretty minimal.
The text was updated successfully, but these errors were encountered:
Tell us about your request
Currently if DD gets multiple options for proxy auth it will just elect Basic per the docs. We have multiple w Basic as a fallback and they are ordered by pref, but that is more a convention than an enforced standard.
Be nice for the new support to mirror how Chromium approaches this problem with a weighting so it tries the most secure first and then works it's way back to Basic.
Which service(s) is this request for?
Docker Desktop
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Multiple authenticate headers are often used on big central proxies and per the docs (and from what i see in deployment feedback) it just means that unless we force using kerb/ntlm folks are just stuck on basic.
Are you currently working around the issue?
We just cover the proxy auth prompt in user docs, but because we have multiple headers it means we really can't take advantage of SSO w/o forcing on install which we only loosely control. As long as they auth to the Proxy correctly the cred will be cached and they will be good till they change the password so the impact is pretty minimal.
The text was updated successfully, but these errors were encountered: