I am trying to execute this simple request on geonetwork, which should give me catalog statistics details (about private datasets for the corresponding user).
http://localhost:8080/geonetwork/srv/eng/q?_content_type=json&summaryOnly=true
It works, when I add basic authentication credentials, but it does not, when I add a JSESSIONID cookie.
I create a new Geonetwork session, getting this cookie back:
Set-Cookie: JSESSIONID=3038E369A5A499AF410F94ABF8A0B12D; Path=/geonetwork/
When I send this cookie with the above request, tomcat receives this request (from the catalina log):
"GET /geonetwork/srv/eng/q?_content_type=json&summaryOnly=true HTTP/1.1" 200 343 "serverTime=1489326597903; sessionExpiry=1489326597903; JSESSIONID=3038E369A5A499AF410F94ABF8A0B12D"
For me, this looks good. But geonetwork does answer the request just with the dataset statistics, that are public. Private datasets will be excluded from the response.
I examined the requests made in the Geonetwork UI and they look exactly like what I am sending. Is there anything that I miss out at this point?
EDIT:
I am using version 3.0.3 of GeoNetwork.
The good point is: If I test from the Firefox RESTClient with a JSESSIONID created by logging in via the user interface, the session is actually recognized for private access.
So the problem seems to be in my code, where I create a new GeoNetwork session.
- If I call with wrong username/ password, GeoNetwork gives me a
200 OK
but no JSESSIONID. - If I call with correct username/ password, GeoNetwork will give me a
200 OK
and a JSESSIONID. But apparently, the JSESSIONID does not seem to be qualified to access private datasets.
What I am basically doing to get the session id, is
Map<String, String> headers = new HashMap<>();
headers.put("Content-Type", "application/x-www-form-urlencoded");
String url = "http://localhost:8080/geonetwork/j_spring_security_check";
String body = "username="+userLogin+"&password="+userPass;
URLResponse r = HttpURLClient.sendRequest(url, headers, body, HttpMethod.POST);
Is that call to j_spring_security_check
probably wrong?