How do I make sure that chromedriver + chrome instances that it fires up have the Kerberos environment variables?

[nicholas...@lucidworks.com]

I am doing tests with Chrome + ChromeDriver + Selenium (all latest editions as of 2/1/2020).

My site that I am testing with has only Basic and Kerberos auth.

So I need to use Kerberos, because basic is not supported with Chrome + Chrome Driver + Selenium at this time (as far as i know!).

I need ChromeDriver to create instances of chrome that have my valid kerberos ticket session so that it automatically logs me into the site i'm testing.

So I have done a quick test where I do this:

KEYTAB_FILE_PATH="/home/me/my.keytab"
KERBEROS_PRINCIPAL_NAME="HTTP/myu...@MY.DOMAIN.COM"
kinit -kt "${KEYTAB_FILE_PATH}" "${KERBEROS_PRINCIPAL_NAME}"

.\chrome-linux --disable-background-networking --disable-bundled-ppapi-flash --disable-client-side-phishing-detection --disable-default-apps --disable-gpu --disable-hang-monitor --disable-popup-blocking --disable-prompt-on-repost --disable-sync --disable-web-resources --enable-automation --enable-logging --force-fieldtrials=SiteIsolationExtensions/Control --headless --hide-scrollbars --ignore-certificate-errors --log-level=0 --metrics-recording-only --auth-server-whitelist=*.mydomain.com --auth-negotiate-delegate-whitelist=*.mydomain.com --mute-audio --no-first-run --no-sandbox --password-store=basic --remote-debugging-port=12776 --test-type=webdriver --use-mock-keychain --enable-logging=stderr --v=1 "data:,"

When I use Chrome Remote Interface and I can verify that yes, I am able to authenticate to this website with no issues in this case.

But...

When I try to use selenium to do this same thing:

KEYTAB_FILE_PATH="/home/me/my.keytab"
KERBEROS_PRINCIPAL_NAME="HTTP/myu...@MY.DOMAIN.COM"
kinit -kt "${KEYTAB_FILE_PATH}" "${KERBEROS_PRINCIPAL_NAME}"
java -jar my-selenium-chromedriver-program.jar

The kerberos doesn't work for some reason. As if I never properly ran the kinit.

Which begs the question, did the environment variables from my current user pass on to the environment variables of the spawned processes from Selenium + ChromeDriver?

Am I missing anything here?

[T Crichton]

From the format of your variable references, it looks like you are using linux or mac. I checked the ChromeDriver code, and we do pass the current environment to Chrome. I'm not certain what selenium does, but the standard mechanism in Java also passes the current environment when starting a subprocess.

First, I would confirm that the java application sees the correct variables by calling System.getenv(). If they are present, there is a mechanism in Selenium to explicitly set environment variables. This requires creating a custom ServiceBuilder, and using the Service to launch ChromeDriver.

CustomBuilder builder = new CustomBuilder();

      builder = (CustomBuilder) builder.usingPort(22171); //must match below

      ChromeDriverService service = builder.createDriverService(

            new File(System.getProperty("webdriver.chrome.driver")), 22171,

            ImmutableList.of(), //ChromeDriver arguments

            ImmutableMap.<String,String>of("key", "value")); //environment

      service.start();

      

      driver = new ChromeDriver(service, options);

The CustomBuilder class:

  static class CustomBuilder extends ChromeDriverService.Builder{

  public ChromeDriverService createDriverService(File exe, int port, 

    ImmutableList<String> args, ImmutableMap<String, String> environment){

    ImmutableList<String> superargs = super.createArgs();

    ImmutableList<String> merged = new ImmutableList.Builder<String>()

      .addAll(args).addAll(superargs).build();

    System.out.println("exe: " + exe.toString());

    System.out.println("port: " + port);

    System.out.println("args: " + args.toString());

    System.out.println("merged: " + merged.toString());

    

    return super.createDriverService(exe, port, merged, environment); 

  }

}

Once you have the CustomBuilder, you can also call withEnvironment, but that's not necessary if you pass the variables you need to the constructor.

[Nicholas DiPiazza]

Hi thanks for the reply.

So what I noticed is that the latest ChromeDriver + Selenium + Headless mode seems to have regression.

The negotiate auth scheme will not work if you use ChromeDriver + Selenium + Headless mode enabled.

It will work if you:

a) Run ChromeDriver + Selenium + Headless mode disabled.

or

b) Run a headless chrome remote debugging port connected with Chrome Remote Interface or Puppeteer.

--
You received this message because you are subscribed to a topic in the Google Groups "ChromeDriver Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/chromedriver-users/ZwNxtXIiDlU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromedriver-us...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chromedriver-users/6a00bd83-a406-48a6-bac5-b142ea4c1e0d%40googlegroups.com.

[T Crichton]

The only difference in ChromeDriver between headless and headed mode is the switch passed to Chrome. Once Chrome has launched (or connected) ChromeDriver itself operates exactly the same in headless or headed mode. So all differences in behavior are in Chrome where the code paths for headless and headed can be very different. If you can provide a clear repro, filing a bug against chromium might help.

It's interesting that it works with Chrome Remote Interface (which I don't know at all) or Puppeteer (of which I know little), but that doesn't point to anything ChromeDriver could do to change the behavior. 

When did the authentication last work for you in headless mode using ChromeDriver?

[T Crichton]

Please try to respond to the list instead of directly to email.

The best way to get the Chrome command line is through the verbose log; the process list will always show several Chrome processes, but only one is directly controllable by ChromeDriver.

Comparing the command line from Selenium (and ChromeDriver):

/home/ndipiazza/testdir/var/connectors/connectors-classic/chrome-linux/chrome --disable-background-networking --disable-bundled-ppapi-flash --disable-client-side-phishing-detection --disable-default-apps --disable-gpu --disable-hang-monitor --disable-popup-blocking --disable-prompt-on-repost --disable-sync --enable-automation --enable-blink-features=ShadowDOMV0 --enable-logging --force-fieldtrials --headless --hide-scrollbars --ignore-certificate-errors --load-extension=/home/ndipiazza/testdir/var/connectors/connectors-classic/work/.org.chromium.Chromium.NGorEo/internal --log-level=0 --mute-audio --no-first-run --password-store=basic --remote-debugging-port=0 --test-logging-path="dsID_70d5af_lucidworks_b27e401a" --test-type=webdriver --use-mock-keychain --user-data-dir=/home/ndipiazza/testdir/var/connectors/connectors-classic/work/.org.chromium.Chromium.M6iOec --v=1 data:,

to command line run directly:

/home/ndipiazza/testdir/var/connectors/connectors-classic/chrome-linux/chrome --disable-background-networking --disable-bundled-ppapi-flash --disable-client-side-phishing-detection --disable-default-apps --disable-hang-monitor --disable-popup-blocking --disable-prompt-on-repost --disable-sync --enable-automation --enable-blink-features=ShadowDOMV0 --enable-logging --force-fieldtrials --hide-scrollbars --ignore-certificate-errors --load-extension=/tmp/.org.chromium.Chromium.PxObay/internal --log-level=0 --mute-audio --no-first-run --password-store=basic --profiling-file=dsID_test235235_chrID_452a77db --remote-debugging-port=44444 --test-type=webdriver --use-mock-keychain --user-data-dir=/tmp/.org.chromium.Chromium.44444 --v=1 --auth-server-whitelist=XXX --auth-negotiate-delegate-whitelist=xxx --auth-schemes=basic,digest,ntlm,negotiate --headless adless

There are a few differences:

the ChromeDriver version includes:

disable-gpu - a user selectable option

test-logging-path - also user selectable

the ChromeDriver version is missing:

auth-server-whitelist - which is still referenced in the Chrome code. I don't know exactly what it does, but it seems it could be relevant to this issue

auth-negotiate-delegate-whitelist - no longer referenced in the Chrome code

auth-schemes - no longer referenced in the Chrome code

You can try adding auth-server-whitelist. 

[nicholas...@lucidworks.com]

Hi sorry I meant to tell you I tried with and without auth whitelist. Doesn't seem to cause any change.

[1580939856.813][INFO]: Launching chrome: /home/nick/test/var/connectors/connectors-classic/chrome-linux/chrome --auth-negotiate-delegate-whitelist=n4vm204 --auth-schemes=basic,digest,ntlm,negotiate --auth-server-whitelist=n4vm204 --disable-background-networking --disable-bundled-ppapi-flash --disable-client-side-phishing-detection --disable-default-apps --disable-gpu --disable-hang-monitor --disable-popup-blocking --disable-prompt-on-repost --disable-sync --enable-automation --enable-blink-features=ShadowDOMV0 --enable-logging --force-fieldtrials --headless --hide-scrollbars --ignore-certificate-errors --load-extension=/home/nick/test/var/connectors/connectors-classic/work/.org.chromium.Chromium.p7bQSa/internal --log-level=0 --mute-audio --no-first-run --password-store=basic --remote-debugging-port=0 --test-logging-path="dsID_7beb05_lucidworks_1e227aef" --test-type=webdriver --use-mock-keychain --user-data-dir=/home/nick/test/var/connectors/connectors-classic/work/.org.chromium.Chromium.yYkXZ1 --v=1 data:,

I tried taking this exact command line and running it directly from command line, then running my test and it works fine. It only doesn't work when chromedriver created the process for some weird reason.

[Panos Christeas]

What port is your Kerberized web server listening at?

I have experienced that issue when a chromedriver-spawn browser would try to negotiate against a non-standard port. As if that flag is enforced by chromedriver somehow:

https://dev.chromium.org/administrators/policy-list-3#EnableAuthNegotiatePort
https://www.chromium.org/developers/design-documents/http-authentication

[Nicholas DiPiazza]

I am using 44444 and chromedriver uses 0 and picks a random available one. 

--
You received this message because you are subscribed to a topic in the Google Groups "ChromeDriver Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/chromedriver-users/ZwNxtXIiDlU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromedriver-us...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/chromedriver-users/bbae626c-a8be-471a-8d8f-a3c57475081b%40googlegroups.com.

[nicholas...@lucidworks.com]

and as for the Auth server port, I'm using 80 and/or 443. the standard ports. nothing unusual there.

On Wednesday, February 5, 2020 at 5:28:03 PM UTC-6, Nicholas DiPiazza wrote:

I am using 44444 and chromedriver uses 0 and picks a random available one. 

On Wed, Feb 5, 2020, 4:57 PM Panos Christeas <xrg...@gmail.com> wrote:

What port is your Kerberized web server listening at?

I have experienced that issue when a chromedriver-spawn browser would try to negotiate against a non-standard port. As if that flag is enforced by chromedriver somehow:

https://dev.chromium.org/administrators/policy-list-3#EnableAuthNegotiatePort
https://www.chromium.org/developers/design-documents/http-authentication

--
You received this message because you are subscribed to a topic in the Google Groups "ChromeDriver Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/chromedriver-users/ZwNxtXIiDlU/unsubscribe.

To unsubscribe from this group and all its topics, send an email to chromedriver-users+unsub...@googlegroups.com.

[T Crichton]

The only recommendation I have at this point is to file an issue with Chromium at https://crbug.com. 

[nicholas...@lucidworks.com]

I filed an issue, finally.

Thanks for your time.

https://bugs.chromium.org/p/chromium/issues/detail?id=1058499