WPTDriver NTLM authentication

Support
1

Hi,

I just migrated one of my agents from URLBlast do WPTDriver.

Unfortunately some of the tests started to fail. This applies only to tested sites that require NTLM authentication. The problem is that in waterfall I now can see all the responses of the server to the browser that require to provide credentials:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM

HTTP/1.1 401 Unauthorized
WWW-Authenticate: NTLM TlRMTVNTUAACAAAADAAMADgAAAAFgomiFHd18hyttBgAAAAAAAA[…]

After that browser sends some hashes to the server and page loads as expected. All subsequent connections to the server are authenticated.

This is great because UrlBlaster does not separate this behavior from reported http requests. And it is impossible to see how fast it is done and TTFB is reported incorrectly.

The only problem is that after that (in my opinion normal behavior of the server and browser) the test has error status 401.

Is this big deal to correct this? My automated tools that use WPT Server have problem with reporting statuses of tests. They are not able to distinguish described case from real problem with authentication.

Regards,

2

I investigated this issue deeper and noticed that for described case when result for run is other than “0” average is not calculated. Only median. Tools that rely on average of runs have problem in case of “401” responses from the server.

I have following in xml result:

<response><statusCode>200</statusCode><statusText>Ok</statusText>
...
<average><firstView></firstView></average>
...
<median><firstView><run>1</run><URL>https://my.url.com/</URL><loadTime>3460</loadTime><TTFB>1202</TTFB><bytesOut>89710</bytesOut><bytesOutDoc>74140</bytesOutDoc><bytesIn>2460365</bytesIn><bytesInDoc>2077324</bytesInDoc><connections>6</connections><requests>62</requests><requestsDoc>55</requestsDoc><responses_200>58</responses_200><responses_404>0</responses_404><responses_other>4</responses_other><result>401</result><render>2483</render><fullyLoaded>4373</fullyLoaded>
...
<run><id>1</id><firstView><results><URL>https://my.url.com/</URL><loadTime>3460</loadTime><TTFB>1202</TTFB><bytesOut>89710</bytesOut><bytesOutDoc>74140</bytesOutDoc><bytesIn>2460365</bytesIn><bytesInDoc>2077324</bytesInDoc><connections>6</connections><requests>62</requests><requestsDoc>55</requestsDoc><responses_200>58</responses_200><responses_404>0</responses_404><responses_other>4</responses_other><result>401</result><render>2483</render><fullyLoaded>4373</fullyLoaded><cached>0</cached><docTime>3460</docTime><domTime>0</domTime>
3

There is another problem with tests of pages that require authentication by sending 401 responses. Repeat view test is not performed:

2014/04/18 11:54:02 - Test Created
2014/04/18 11:54:06 - Starting test (initiated by tester PLKRK-L-R9A1FAP-10.3.52.208)
2014/04/18 11:54:37 - Test Run Complete. Run: 1, Cached: 0, Done: , Tester: xxx-10.3.52.208
2014/04/18 11:54:37 - Test Run Complete. Run: 1, Cached: 1, Done: , Tester: xxx-10.3.52.208, Test Run Error: "Skipped repeat view, first view failed: Test run failed with result code 401"
2014/04/18 11:54:37 - Test Run Complete. Run: 1, Cached: 1, Done: 1, Tester: xxx-10.3.52.208, Test Run Error: "Skipped repeat view, first view failed: Test run failed with result code 401"
2014/04/18 11:54:37 - Test Complete
2014/04/18 11:54:38 - Test post-processing complete
4

Any updates on this bug? We’re looking at implementing a private instance to test our internal web sites, most of which use NTLM auth. We noticed the same problems.

It’s valuable for us to capture the 401s but as mentioned before we don’t want the test to report as an failure.

Thanks.

5

Is it just the 401’s or is there also a functional problem getting to the page? It should be easy enough for me to treat 401’s more like redirects which will make them non-errors and report a correct TTFB.

6

In my case it’s just the 401s, the first test completes as you would expect (captures the entire waterfall) just reports as an error and skips the repeat test (plus the other issues noted by OP). Treating them more like redirects sounds like an appropriate solution.

Thanks!

7

Treating them like redirects would be perfect IMO.

Thanks!

8

Patrick, is it possible to predict when this change can be implemented in WPTDriver?

9

I just pushed 177 which has an attempt at a fix (I don’t have a test rig with NTLM auth so I can’t verify it is working). I think I got all of the places in the code where it looks for a > 400 response code and have it treating 401’s as 301 and 302’s: https://github.com/WPO-Foundation/webpagetest/commit/f1d1dc4718f3fd447b49dc9d512f8c4d9f4b81f7

Here’s how to grab the latest binary: https://sites.google.com/a/webpagetest.org/docs/private-instances#TOC-Updating-Test-Agents

Let me know if it still doesn’t work.

10

Works perfectly now.

Thanks a lot for your work, Patrick.

11

Patrick,

Now I have the same issue with “407” proxy authentication requests:

When getting “HTTP/1.1 407 Proxy Authentication Required ( Forefront TMG requires authorization to fulfill the request. Access to the Web Proxy filter is denied. )” response agent reports “First View (Error: 407)”

12

Any chance you can email me a screen shot? It sounds like a different failure where the auth actually failed rather than the auth succeeding but being reported as a test error.

13

Here is the example:

14

Any chance you can email me the result folder for that test as a zip file? If I can reproduce it I might be able to get a fix in the 2.15 release that I’m preparing right now.

15

Sorry, just realized the original fix was for 401’s and now you are seeing it for 407’s. Do you ming opening a github issue so I don’t forget? I’ll try and get it fixed tomorrow (though I just cut 2.15 so it won’t get into an official release for a while).

16

I always use trunk HEAD, so not including it in the release is not a problem for me.

Do you mean that you open github issue?

17

Patrick,

I am not sure if the fix is included in current version.

I updated WPT Server to Head and wptdriver to version 183 and I am still getting “Error: 407” when going through the proxy with NTLM authentication.

18

Hi Patrick,

Is there any chance that this issue will be fixed? I use the latest (HEAD) version of WPT Server and wptdriver but it is still a problem for me.

Best regards,