Spring security and special characters

Question

I need to log in with j_spring_security_check using special characters in the username and/or in the password via url

http://localhost:8080/appname/j_spring_security_check?j_username=username&j_password=üüü

isn't working and

http://localhost:8080/appname/j_spring_security_check?j_username=username&j_password=%c3%bc%c3%bc%c3%bc

(with "üüü" urlencoded) isn't working either

Any suggestion? Let me know if you need to see any other configuration.

Thanks

Answer 1

Maybe an encodingFilter in the web.xml file could be helpful:

<filter>
<filter-name>encodingFilter</filter-name>
    <filter-class>
        org.springframework.web.filter.CharacterEncodingFilter
    </filter-class>
    <init-param>
        <param-name>encoding</param-name>
        <param-value>UTF-8</param-value>
    </init-param>
    <init-param>
        <param-name>forceEncoding</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>
<filter-mapping>
    <filter-name>encodingFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

source: Spring security: Form login special characters

Answer 2

The issue was actually solved for me by moving the CharacterEncodingFilter ABOVE the SpringSecurityFilterChain in web.xml.

Answer 3

The Java Servlet standard is lamentably poor at supporting Unicode. The default of ISO-8859-1 is useless and there is still no cross-container-compatible means of configuring it to something else.

The filter method in matteosilv's answer works for request bodies. For parameters in the URL, you have to use container-specific options. For example in Tomcat, set URIEncoding on the <Connector> in server.xml; in Glassfish it's <parameter-encoding> in glassfish-web.xml.

(If you have to work in a fully cross-container-compatible manner you end up having to write your own implementation of getParameter(), which is sad indeed. Bad Servlet.)

However in any case it is a bad idea to pass login form fields in GET URL parameters.

This is firstly because a login causes a state-change to occur, so it is not "idempotent". This makes GET an unsuitable method and causes a load of practical problems like potentially logging you in when you navigate a page, or failing to log you in due to caching, and so on.

Secondly there are a range of ways URLs can 'leak', including referrer tracking, logging, proxies and browser history retention. Consequently you should never put any sensitive data such as a password in a URL, including in GET form submissions.

I'd suggest using a POST form submission instead, together with the CharacterEncodingFilter.