HTTPSession.setCredentialsProvider(AuthScope.ANY, ) always fails on null argument exception

[JohnLCaron]

unit test is thredds.tds.TestRestrictDataset in it module

[JohnLCaron]

perhaps AuthScope.ANY should be prohibited in this context, so is correct behavior?

I have replaced AuthScope.ANY with actual endpoint in TestRestrictDataset unit test for now.

[JohnLCaron]

Now the "bad password tests" pass unit tests, but TestRestrictDataset.testSuccess() does not correctly pass the credentials, or perhaps doesnt respond to the security challenge (?)

No Principle is seen in the servlet code (see DatasetManager.resourceAuthorized() in latest 5.0 PR). This code works from a browser, so I suspect something wrong with HTTPSession. ??

[DennisHeimbigner]

If memory serves, this is a known problem (to me). I think the problem
was that the restricted dataset redirection for the thredds server was not
working and I was waiting on Jen to fix it. In any case, let me return to this
and see if I can figure out the current state.

[JohnLCaron]

This is tested on localhost, so no funny dependencies on our production server

[DennisHeimbigner]

My error, I see you are referring to TestRestrictDataset instead of TestAuth.

[JohnLCaron]

OK, things are more complicated that i realized.

1. it appears that the UsernamePasswordCredentials is getting used by HTTPSession on the client. Used when a security challenge (307/401) comes back.

1a) Credentials not being preemptively set, but if they were, could avoid 1 or 2 extra round-trips.

2. HTTPFactory.Get(endpoint) appears to be using cached Credentials. Not sure if thats in our code or in the httpclient library.

3. Creating a new HTTPSession appears to be using cached credentials. So that might point to caching in the httpclient library ?? I think this is wrong, we need to keep sessions seperate, otherwise two users would share credentials. or is there some assumption somewhere that theres only one user??

this looks like a showstopper for 5.0, so high priority. Im wondering if the same problem is happening in 4.6?

bottom line: credential caching needs clarification and probably fixing.

[JohnLCaron]

its possible/likely that i still dont understand exactly whats happening....