Closed bjowes closed 3 years ago
This has been resolved by improving the way the ntlm-proxy closes connections on reset.
Implemented in 3.0.0
Sorry for the delay in answering. I use indeed '*' in the cy.ntlm(...). I have tested the version 4.0.4 and it works. Thanks a lot! I was forced to have two features for some requirements, I will be able to merge them and have a clean one on relation in my traceability matrix.
For information only (this is not an issue for me): if I do not use the ntlmReset(), the test is stuck with the identity obtained with the first cy.ntlm(...). Here is a for a test execution without the reset. The 3 first scenarios have a step to set dummy0 as user, the last one has a step to use dummy1. As you can see this last scenario fails because the identity is still dummy0. With the reset, this test passes.
Glad it helped. Thanks for reporting this - I think it could also be related to the wildcard host. For a named host it should clear all connections on reconfiguration, likely there is an issue with matching with wildcard host.
I have made a test by without the wildcard. I have used cy.ntlm(['localhost:44365'], Cypress.env('dummy0Login'), Cypress.env('dummy0Password'), 'prod.fsma.be') and I got the same result than above.
The cy.ntlmReset terminates all sockets to ensure no pre-authenticated sessions still exist. Recent versions of cypress seems to get confused by this. I have managed to work around it by navigating to a blank page, forcing the browser to drop all connections.
To simplify this for the users, the cy.ntlmReset should go to a blank page before terminating sockets. The blank page could be returned by ntlm-proxy when a specific url (or header) is requested. embedded Possibly this should be optional, there might be cases where the user would not want to navigate away on ntlmReset.