WAS Liberty profile java.lang.IllegalArgumentException: Cookie name "Path" is a reserved token - websphere-liberty

I am getting following exception when trying to access the deployed war application.
Environment Details:
WAS Liberty Profile and
IBM JDK 6
<pre>
Exception = java.lang.IllegalArgumentException
Source = com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters
probeid = 1105
Stack Dump = java.lang.IllegalArgumentException: Cookie name "Path" is a reserved token
at javax.servlet.http.Cookie.<init>(Cookie.java:139)
at com.ibm.ws.webcontainer.osgi.request.IRequestImpl.getCookies(IRequestImpl.java:147)
at com.ibm.ws.webcontainer.srt.SRTServletRequest.getCookies(SRTServletRequest.java:1600)
at com.ibm.ws.webcontainer.security.internal.WebRequestImpl.determineIfRequestHasAuthenticationData(WebRequestImpl.java:155)
at com.ibm.ws.webcontainer.security.internal.WebRequestImpl.hasAuthenticationData(WebRequestImpl.java:176)
at com.ibm.ws.webcontainer.security.internal.WebAppSecurityCollaboratorImpl.optionallyAuthenticateUnprotectedResource(WebAppSecurityCollaboratorImpl.java:392)
at com.ibm.ws.webcontainer.security.internal.WebAppSecurityCollaboratorImpl.performSecurityChecks(WebAppSecurityCollaboratorImpl.java:343)
at com.ibm.ws.webcontainer.security.internal.WebAppSecurityCollaboratorImpl.preInvoke(WebAppSecurityCollaboratorImpl.java:327)
at com.ibm.wsspi.webcontainer.collaborator.CollaboratorHelper.preInvokeCollaborators(CollaboratorHelper.java:431)
at com.ibm.ws.webcontainer.osgi.collaborator.CollaboratorHelperImpl.preInvokeCollaborators(CollaboratorHelperImpl.java:267)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1033)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:81)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:930)
at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$1.run(DynamicVirtualHost.java:253)
at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink$TaskWrapper.run(HttpDispatcherLink.java:457)
at com.ibm.ws.threading.internal.Worker.executeWork(Worker.java:398)
at com.ibm.ws.threading.internal.Worker.run(Worker.java:380)
at java.lang.Thread.run(Thread.java:770)
</pre>
Can somebody help on this?

There are restrictions on cookie names, including a selection of reserved names/tokens[1]. (No need to worry about the specific environment in this case.) =) You may not use any of the following names (this list may not be exhaustive):
comment
discard
domain
expires
max-age
path
secure
version
Also, since cookies are case-insensitive[2], "Path" will spark the same java.lang.IllegalArgumentException as "path" will.
As for the restrictions, cookie names:
must not be null or empty[3]
must not contain any whitespace[3]
must not start with $[2]
must not include commas , or semicolons ;[3]
=)
References
"Cookie Reserved Names- Who's to blame?" article
RFC 2109 specification (see sections 4.1 and 4.2.2 respectively)
Java EE 6 Cookie constructor documentation

From the stacktrace, it looks like that the cookie from the client side (maybe the browser ?) has an invalid name. Per the Cookie java doc, some reserved words are not allowed for cookie name.
java.lang.IllegalArgumentException - if the cookie name is null or
empty or contains any illegal characters (for example, a comma, space,
or semicolon) or matches a token reserved for use by the cookie
protocol

Related

Spring Boot doesn't recognize multipart form-data element when filename is missing

I have this code:
#PostMapping("foobar")
public ResponseEntity<SaveLogsResult> foobar(#RequestPart("file") MultipartFile log, #RequestPart("env") MultipartFile json){
return ResponseEntity.ok(fooService.saveFooBar(log, json, UUID.randomUUID().toString()));
}
Two applications send formally correct data to this endpoint, one fails miserably and receives an http status 400.
I set logging.level.org.springframework.web=DEBUG and can see (among other lines) this:
Required request part 'env' is not present
Resolved [org.springframework.web.multipart.support.MissingServletRequestPartException: Required request part 'env' is not present]
Completed 400 BAD_REQUEST
To further diagnose this I compared a working (left) and a non-working (right) request. The only different is the mising filename:
As far as I understand the RFC for Content-Disposition leaving out the filename is perfectly valid:
Is followed by a string containing the original name of the file
transmitted. The filename is always optional and must not be used
blindly by the application: path information should be stripped, and
conversion to the server file system rules should be done. This
parameter provides mostly indicative information. When used in
combination with Content-Disposition: attachment, it is used as the
default filename for an eventual "Save As" dialog presented to the
user.
Is this an error inside Spring ? I use Spring Boot 2.6.2
Unfortunately I can't change the non-working component for a quick test because it is a bought component that doesn't receive bugfixes very often.
I think that my problem is different from that described here because the failure only happens in a specific scenario.
It looks like you have to provide the filename. see this issue
This [The situation in which filename is not present] can lead to inconsistencies, e.g. you would get it with
MultipartFile but not with collection or array of MultipartFile, and
one can make the opposite argument that it should be rejected.
Why does it matter to have it injected as MultipartFile if it doesn't
even have a filename? You could also inject it as InputStream or any
other type supported by a registered HttpMessageConverter.

Can Jmeter LDAP Request or LDAP Extended Request populate a multi-valued attribute?

I am working on a Jmeter LDAP test plan and the test plan has to populate an attribute on the LDAP that is multi-valued.
When I do an LDAP search sampler, I noted that the value I get back is a string, with the values separated by ", ".
But, if I take the same comma-separated string and try to do an LDAP modify or add, using either an LDAP Request or LDAP Extended Request, I get an error.
So I am wondering if there is a way that the Jmeter LDAP Request or LDAP Extended Request can do that?
Thanks,
Jim
EDIT: When I try to use an Extended LDAP Request modification test/add with the attribute of "", I get this error in the Jmeter GUI response:
When attempting to modify entry cn=xxx... to replace the set of values for attribute lastlogindate, value "20181023085627-04, 20181024063205-04" was found to be invalid according to the associated syntax: The provided value "20181023085627-04, 20181024063205-04" is not a valid generalized time value because it contains an invalid character '-' at position 14
The strange part is that even though I have Jmeter to log at debug level, I don't see any detail on the error in the Jmeter.log, but/so I am guessing that that error message is coming from the Jmeter client itself. I noticed that the message says:
to replace the set of values
so it seems like it recognizes that I am trying to modify/replace a multi-value, but it doesn't seem to like the syntax of the replacement values string(s).
Does anyone know what the correct format SHOULD be?
I found the answer to my own question, or at least "A" answer: It appears that I can use an Extended LDAP request, and add the same attribute in that request, multiple times. So for example, if I am populating an attribute named "foo" the Extended LDAP request would have the following:
attribute value opcode
foo 12345 add
foo 12346 add
etc.
I think I also need to do a replace with no value, to empty the attribute, before all the adds.

JMeter intermittently failing to parse URL variables while load testing

While load testing with JMeter I am attempting to send 1000 requests in one second. The issue is that I need to send the access token aquired from each previous login. While doing so I am getting the following error:
java.net.URISyntaxException: Illegal character in path at index 67: https://greenback-api.com/api/subscribers/getSavings/${USER_ID}?access_token=${AUTH_TOKEN}
Typical under a low load JMETER has no problem transforming the variables into a valid url likeso:
api.com/api/subscribers/getSavings/4?access_token=443hrr4938rh9ghreughughtrugtrgt4
Is there a way to force JMETER to render the url variables before issuing a get request even under a high load?
It looks like sometimes ${USER_ID} and ${AUTH_TOKEN} are not returned by login (or whatever sets them). As a result JMeter will use the expression ${...} as is. And the characters {} are indeed invalid for URI (they have to be encoded).
Another option is that ${USER_ID} or ${AUTH_TOKEN} really contain some characters invalid for URI and that need to be encoded.
So you may need to
URL Encode your ${AUTH_TOKEN} (and possibly ${USER_ID})
Make stricter checking upon login completion (and any other operations that fill ${USER_ID} or ${AUTH_TOKEN}) to make sure they don't proceed to the following operations if the value was not returned.

How to set Content-Type header for JMS message

We have a Java application that sends JMS message via IBM WebSphere MQ. The consumer application requires the message content type to be set to "application/json". How can I go about doing it?
I've checked through a few references and it seems I can set extra header via method "setStringProperty(headerKey, headerName)", E.g.
Message jmsMsg = session.createTextMessage(msgStr);
jmsMsg.setStringProperty("Content-Type", "application/json");
The problem then is "Content-Type" is not a valid property key since it contains the "-" character.
Is this something that can be done in code? Or is it actually configured in the queue settings?
The property name "Content-Type" has a '-' character. According to JMS specifications a property name can contain any character for which the Java Character.isJavaIdentifierPart method returns a true. For '-' character isJavaIdentifierPart method returns false. Hence the setStringProperty("Content-Type", "application/json") method call fails with the following exception.
com.ibm.msg.client.jms.DetailedMessageFormatException: JMSCC0049: The property name 'Content-Type' is not a valid Java(tm) identifier.
The supplied property name does not conform to the allowed format described in the JMS specification.
Check the characters used in the property name and modify as necessary.
If it's possible to change the receiving application, you could opt for "Content_Type" (Use an underscore) as property name instead of "Content-Type".
As an example for SOAP format, w3c requires using JMS property named "SOAPJMS_contentType" (http://www.w3.org/TR/soapjms/). It looks that there is nothing about JSON format in the standards, but you can use name like that. Such name will be processed correctly by IBM JMS libraries.

How do you check for a valid session in Struts 2 jsp?

I have an include jsp on all my pages which includes js files, css files, etc. This include jsp also refers to the session with "".
On the last page of my application, the action does a session.invalidate on the HttpSession object.
So when the last the last page of my application appears and runs the "", I get the following error since the session is invalidated
2011-10-19 10:30:59,134 WARN com.opensymphony.xwork2.ognl.OgnlValueStack - Caught an exception while evaluating expression '#session.user.isWhatever()' against value stack
java.lang.IllegalStateException: getAttribute: Session already invalidated
at org.apache.catalina.session.StandardSession.getAttribute(StandardSession.java:1062)
at org.apache.catalina.session.StandardSessionFacade.getAttribute(StandardSessionFacade.java:110)
at org.apache.struts2.dispatcher.SessionMap.get(SessionMap.java:165)
at ognl.MapPropertyAccessor.getProperty(MapPropertyAccessor.java:76)
I have tried "#session neq null" to stop the error from appearing but that doesn't work.
Is there anyway/condition to use to stop this error? How does one check if the session is valid in the jsp in Struts 2?
Check for the presence of a known session value--in your case, #session.user. You shouldn't have to do an explicit null check, IIRC (could be wrong). Depending on how things are actually working in your app, you can also check for isNew, although that seems like it shouldn't be necessary.
The session will "never" be null--unless explicitly directed otherwise, just hitting a JSP page will create one.

Resources