search

Waffle / waffle

Enable drop-in Windows Single Sign On for popular Java web servers.
https://waffle.github.io/waffle
MIT License
473 stars 186 forks source link

TestNegotiate depends on side-effect from another test #68

Open nzbart opened 11 years ago

nzbart commented 11 years ago

The WindowsAuthProviderImplUnitTests.TestNegotiate test does not complete successfully when run by itself.

It does pass if the following line of code is added to the top of the test:

Domain.GetComputerDomain();

Because this line of code is executed in previous tests in the same class, TestNegotiate appears to pass.

Note that my machine is connected to a domain. I am running the following version of Windows:

dblock commented 11 years ago

That's weird. Do you understand why this happens? Obviously that's a bug.

dblock commented 11 years ago

Btw, nice debugging. I've seen this before and it confused me, but never dug deep enough.

nzbart commented 11 years ago

I've had a further look, but still none the wiser what the framework code is doing that we aren't. For now (since I'm not using this code in production), I'm just going to put the Domain.GetComputerDomain() line in the appropriate place. The SSPI API documentation from Microsoft is dismal.

hazendaz commented 10 years ago

Where is this piece of code? Is this still a problem?

nzbart commented 10 years ago

Sorry, I can't remember the details. Feel free to close it - if it's still causing problems, someone will report it again.

dblock commented 10 years ago

This is https://github.com/dblock/waffle/blob/master/Source/WindowsAuthProviderUnitTests/WindowsAuthProviderUnitTests.cs#L169 and I think it's still a problem.

nzbart commented 10 years ago

I never managed to come up with a satisfactory answer. I found the Domain.GetComputerDomain() workaround by getting an understanding of which test needed to be run before WindowsAuthProviderImplUnitTests.TestNegotiate, and then reverse engineering the .NET BCL code called by that test and copying and pasting bits into the failing test until it started working. That line was the minimum viable change I managed to find. Unfortunately, there's still quite a bit going on inside GetComputerDomain, but the key to this mystery lies within there. Perhaps there is some API initialisation that needs to happen first? As I said, the SSPI API documentation is lacking.

Good luck!

hazendaz commented 10 years ago

This issue appears to be ever more present now. I was unable to build out 1.7 release as long as this test case was in place. I simply deleted it to get through the release. Tried on multiple machines all with same issue. I did not try the solution in this but wanted to point out it seems to be occurring more often now. Machines I tried on where both windows 8.1.