Missing support for HTTP authentication prompts about webdriver HOT 34 OPEN

@andreastt Any chance we can prioritise this please?

from webdriver.

While I applaud the effort to support all of that, I would be very much more happy to get support for http basic authentication first and those settings later, when the dust has settled for how to authenticate those and make API for them.

from webdriver.

Since Chrome does not support in-URL auth (https://medium.com/@lmakarov/say-goodbye-to-urls-with-embedded-credentials-b051f6c7b6a3) since v59, are there plans of increasing the priority of this?

from webdriver.

@AutomatedTester who basically could take this up nowadays?

from webdriver.

Well, let me tell you, the vendor that first gets any form of basic http authentication is going to see a massive spike in usage, as this is pretty much the most annoying missing feature of any implementation. And all of them require different, hard to implement and not generic workarounds. :-(

from webdriver.

This is a discussion on how to handle HTTP basic access authentication in WebDriver, and not about how to circumvent or work around the current API’s shortcomings.

I alluded in an earlier comment that basic auth might be handled by a new permissions API in general, but this API wound up being tied closely to the Permissions API standard. They are now extending WebDriver which makes it possible to control permissions for a range of web APIs, but since basic auth isn’t part of this standard we still need to find a solution for how to handle this in WebDriver.

from webdriver.

Authentication isn't always via a username and password. Other valid forms include OTPs, and security tokens. Any API for authentication added to webdriver should support those other mechanisms too.

from webdriver.

This appear to be a pangalactic gap in WebDriver. Every architect should now that:

1. Basic authentication is NOT supported in URL in most modern browsers.
2. WebDriver has absolutely no support for basic authentication.

As a consequence, automation of any BAISC AUTH involving scenario is NOT SUPPORTED IN WEBDRIVER at all.

Possible workarounds include:

1. Enabling of basic auth via URL did not work for me in any target browser of mine. Supposedly --disable-blink-features=BlockCredentialedSubresources was working for Chrome some time ago...
2. In Chrome you can add a plugin that does the authentication for you instead: https://stackoverflow.com/a/35293026/232542
3. Create an unprotected login page, that makes a basic authentication request including username and password to establish session for all upcoming requests. E.g. https://stackoverflow.com/questions/5507234/use-basic-authentication-with-jquery-and-ajax or https://github.com/jshttp/basic-auth

This is still utterly lame. This problem persists for two+ years. Basic auth should be basic!

from webdriver.

It's been a while since TPAC and I wonder if we can make a bit of progress on this issue given that it blocks a couple of people correctly implementing their tests.

Sadly the minutes don't mention someone who should take action on it, but in the final lines Simon asked Brian, if that is a sensible approach and he agreed. So @burg I would like to kindly ask if you would have the time to write down the spec changes?

from webdriver.

As of now this can be solved by WinAppDriver
microsoft/WinAppDriver#212

from webdriver.

I would say OTP is out of the scope of this ticket. This is usually implemented by a 3rd party service which redirects you to a webpage. In turn a webpage can be handled by selenium.
Security token can not be used securely in a cloud environment like sauce, so that is kind is out of the scope as well.

from webdriver.

from webdriver.

@haroon-sheikh It is scheduled for level 2 of the specification, so we will likely discuss this at the next F2F in November. However, implementors are currently focussing on level 1 conformance.

from webdriver.

Guyz,
I would like to understand the reason for thumbs down?

from webdriver.

Wokhay! That sounds justifiable.

from webdriver.

Guys, this is a 2 years old topic.
To be honest I don't really get why is it so complicated by given the facts:

1. You can send strings to the popup.
2. You can click both 2 buttons.

What is missing:
The ability to fill or switch over to the password field.

Ok, I'm not included in any browser development project that's true, but given the above facts and that Selenium is able to handle all the other type of popups, it doesn't seems to be a big deal to get this fixed.

And I also feel a bit overcomplicated that we need to hack through proxys in order to get this properly workaround for the moment.

from webdriver.

NTLM and FaceID are both authentication mechanisms baked into browsers that we need to support. The idea isn't specifically about OTP, it's about the fact that browser-based authentication via modal dialogs owned by the browser aren't always just username and password. My apologies for not making that clearer.

from webdriver.

@andreastt Do you know where does the priority sit now? When are we planning to make a start on Level 2 conformance?

from webdriver.

I believe most vendors are hesitant to start new feature work before they are in complete conformance with the existing specification.

from webdriver.

Can we have any permanent solution for this? No reliable and good workaround solution as well. authenticateUsing feature should be available in latest release.

from webdriver.

Resolution from TPAC (minutes):

Add new capability for default authentication credentials. Add handling of authentication dialogues wherever it is that we have unhandled prompt prose. Add endpoint to allow deliberate authentication, and this is probably going to be in section 18.

from webdriver.

from webdriver.

I'm also running into this issue trying to implement some enterprise level tests that run in Jenkins. I had to switch from geckodriver to chromedriver and now authentication is not working. The pre-authentication workaround is also not working for me. Any chance of progress on this issue? I'm at a standstill.

from webdriver.

I am having the same problem. I am able to do the URL approach to bypass basic auth on chrome but when it comes to Safari OS X I haven't been able to find any solution yet.

from webdriver.

Is there a workaround for this on Chrome?

from webdriver.

any change in this matter?

from webdriver.

What is the priority for this?

from webdriver.

At the moment this is not a priority for me. If someone wants to write the prose I will gladly edit it and get it merged.

from webdriver.

from webdriver.

@AutomatedTester would something like what selenium-wire incorporated to handle requests and use proxies that require basic authentication be what could inspire the handling of basic authentication here?

from webdriver.

from webdriver.

Any priority for this?

from webdriver.

It seems that the current workaround is to use use selenium support for the BIDI API to solve this problem. AFAIK it currently only works with Chrome/Chromium.

I don't see any movement happening on this until we from the community create pull requests for the relevant specification in the webdriver spec, as the current maintainers seem to have moved on?

from webdriver.

Any workarounds in headless Python Chrome Selenium without spinning up XVFB display for extension cycling (unreliable on Lambda) and without using SeleniumWire (blocked due to TLS fingerprint)?

from webdriver.