[
https://issues.jboss.org/browse/SEAMSECURITY-68?page=com.atlassian.jira.p...
]
Stefano Travelli updated SEAMSECURITY-68:
-----------------------------------------
Git Pull Request:
https://github.com/seam/security/pull/14
I filed a pull request with a fix for the problem. In this fix I assumed that
'dialogueId' parameter is in the query string.
On #seam-dev I was suggested to check how weld retrive the conversationId ('cid')
and I found that it is retrieved in the WeldPhaseListener, so inside FacesServlet, that is
when encoding is already set.
I wonder if this filter shouldn't be reworked as an Interceptor and get the dialogueId
through @RequestParam from seam-servlet.
DialogueFilter breaks character encoding
----------------------------------------
Key: SEAMSECURITY-68
URL:
https://issues.jboss.org/browse/SEAMSECURITY-68
Project: Seam Security
Issue Type: Bug
Affects Versions: 3.0.0.Final
Environment: JBoss 6 Final, JSF 2
Reporter: Stefano Travelli
Including seam-security-external among the dependencies causes the application to use the
default iso-8851-1 character encoding for parsing form parameters.
After digging into the code I found that character encoding would be set to the correct
value by the FacesServlet that calls request.setCharacterEncoding(). This method must be
called before any attempts to get a parameter from the request, since at the very first
getParameter() the request parses all parameters with the specified encoding.
However seam-security-external introduces a DialogueFilter that look for a dialogId
parameter too early (see:
https://github.com/seam/security/blob/master/external/src/main/java/org/j...)
causing all the parameters to be parsed as iso-8859-1 and the subsequent encoding set by
the FacesServlet to be ignored.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira