We Keep Coding

fix for spot bug - HRS_REQUEST_PARAMETER_TO_HTTP_HEADER

I am executing below code inside servlet and getting this spot bugs - HRS_REQUEST_PARAMETER_TO_HTTP_HEADER
Bug: HTTP parameter directly written to HTTP header output in SSOIdpLogoutRedirect.doPost(HttpServletRequest, HttpServletResponse)
String relayState = request.getParameter("RELAY_STATE");
if(relayState != null)
{
response.sendRedirect(relayState);
}
To fix this bugs i added below code.
relayState = URLEncoder.encode(relayState,StandardCharsets.UTF_8);
But URL does not redirect in correct way as i can see the relaystate url has been changed after encoding
original relaystate = https://sad.ezhdj.net/system/web/apps/dfgh/
and after encoded it is
relaystate =https%3A%2F%2Fsad.ezdev.net%2Fsystem%2Fweb%2Fapps%2Fdfgh%2F`

you should use HttpServletResponse.encodeRedirectURL() to encode redirect urls:
String encodeRedirectURL(String url)
Encodes the specified URL for use in the sendRedirect method or, if
encoding is not needed, returns the URL unchanged. The implementation
of this method includes the logic to determine whether the session ID
needs to be encoded in the URL.
...
All URLs sent to the HttpServletResponse.sendRedirect method should be
run through this method...
this should work:
response.sendRedirect(response.encodeRedirectURL(relayState));
since your url doesn't actually need encoding, output from encodeRedirectURL() will be:
https://sad.ezhdj.net/system/web/apps/dfgh/
and the redirect will work just fine.
edit:
apparently proposed solution still triggers HRS_REQUEST_PARAMETER_TO_HTTP_HEADER spotbug error.
after doing little more research I found out that the error is meant to prevent HTTP response splitting vulnerability (i.e. when unwanted \r\n are written in the header section of http response).
we should then better sanitize relayState against this type of vulnerability.
a simple relayState.replace("\r\n", "") is enough to make the error go away:
response.sendRedirect(response.encodeRedirectURL(relayState.replace("\r\n", "")));

NTLM authentication failing

I'm trying to get NTLM authentication working in some Java code, but getting 401'd.
This page makes me think the following code (source for NTLMEngineImpl is from Apache HTTPClient and modified slightly here):
System.out.println(new NTLMEngineImpl().generateType3Msg("Zaphod", "Beeblebrox", "Ursa-Minor", "LightCity", "TlRMTVNTUAACAAAAAAAAACgAAAABggAAU3J2Tm9uY2UAAAAAAAAAAA=="));
Should output:
TlRMTVNTUAADAAAAGAAYAHIAAAAYABgAigAAABQAFABAAAAADAAMAFQAAAASABIAYAAAAAAAAACiAAAAAYIAAFUAUgBTAEEALQBNAEkATgBPAFIAWgBhAHAAaABvAGQATABJAEcASABUAEMASQBUAFkArYfKbe/jRoW5xDxHeoxC1gBmfWiS5+iX4OAN4xBKG/IFPwfH3agtPEia6YnhsADT
Instead I get:
TlRMTVNTUAADAAAAGAAYAEgAAAAYABgAYAAAABQAFAB4AAAADAAMAIwAAAASABIAmAAAAAAAAACqAAAAAYIAAgUBKAoAAAAPrYfKbe/jRoW5xDxHeoxC1gBmfWiS5+iX4OAN4xBKG/IFPwfH3agtPEia6YnhsADTVQBSAFMAQQAtAE0ASQBOAE8AUgBaAGEAcABoAG8AZABMAGkAZwBoAHQAQwBpAHQAeQA=
Which looks close - I think the expected string is almost, but not quite, a substring of the actual string. So where does the extra data come from and how can I fix it?

How to get http response header in apache jena during calling Method FileManager.get().loadModel(url)

I am loading model in apache jena using function FileManager.get().loadModel(url).And I also know that there may be some URLs in HTTP Response Link Header .I want to load model also from the links(URLs) in link header.How to do that ? Is there any inbuilt fuctionality to get access to header and process link header in Response header?

FileManager.get().loadModel(url) packages up reading a URL and parsing the results into a model. It is packing up a common thing to do; it is not claiming to be comprehensive. It is quite an old interface.
If you wanted detailed control over the HTTP handling, see if HttpOp (a lower level) mechanism helps, otherwise do the handling in the application and hand the input stream for the response directly to the parser.
You may also find it useful to look at the code in RDFDataMgr.process for help with content negotiation.

I don't think that this is supported by Jena. I don't see any reason in doing so. The HTTP request is done to get the data and maybe also to get the response type. If you want to get the URLs in some header fields, why not simply use plain old Java:
URL url = new URL("http://your_ontology.owl");
URLConnection conn = url.openConnection();
Map<String, List<String>> map = conn.getHeaderFields();

Sending dynamic custom headers in swagger UI try outs

I am using swagger in java.
I am reading a header called callerId through requestAttributes in the code. I am not using the header through the annotation #HeaderParam.
because of this reason, the header section is not showing up in the swagger UI for try outs.
How can I make this header show up in the try out form.
Is there any way I can achieve this without hard coding the header value.
Thanks in advance.

You can add parameters to an operation using #ApiImplicitParams and #ApiImplicitParam.
The following wiki documentation should provide you with an explanation on how to use these annotations - https://github.com/swagger-api/swagger-core/wiki/Annotations#apiimplicitparam-apiimplicitparams
Keep in mind I assume here that this is not a security header but actually part of the API (at least based on the description you gave). If you're looking for a security header, there's an alternative method. Please leave a comment and I'll edit this response.

Content-Length-Header not set in Jersey Client request

I'm using Jersey Client to access a webservice, like this:
response =
r.accept(MediaType.TEXT_PLAIN_TYPE).header("content-length", 0).post(String.class);
where r is a WebResource
However, the Webservice returns 411 - Content-Length is missing.
using tcpdump, i found out that i am able to specify custom headers, i.e. .header("myheader", 0) works fine.
So it seems that jersey is deleting the content-length header for some reasons.
Anyone has any ideas?

I actually had a requirement to use an empty POST request for a Restful webservice.
If you specify an empty string as the second parameter of post method, Jersey will create the Content-Length header with the value of 0.
e.g.
response = r.accept(MediaType.TEXT_PLAIN_TYPE).post(String.class, "");

The content length of a call is computed by Jersey Client, it cannot be set.
Paul Sandoz — a well known commiter on the project — have answered a similar question:
Q: I think that "Content-Length"
header is not being set automatically.
A: The Jersey runtime [...]
determine the length of content.
If you need further informations, please explain what result did you expect from POSTing a String to a Resource with an empty size.