Spring security + i18n = how to make it work together?

10,970
  1. After sending request xxxxx?locale=en it creates Locale without "country" attribute (only language is set).

It is the expected behaviour. In java there is some kind of hierarchy. The language is more general then the country.

The idea behind is that you can have for example the text in the more common languge but some units (like currency) in the country specific files.

@see: http://java.sun.com/developer/technicalArticles/Intl/IntlIntro/


  1. The more serious problem is that it doesn't work...

It should work without any hand made implementation!

You need to register the Local Change Interceptor, and need to set permitAll for the login page.

<mvc:interceptors>         
     <bean class="org.springframework.web.servlet.i18n.LocaleChangeInterceptor" p:paramName="lang"/>
</mvc:interceptors>

<http auto-config="true" use-expressions="true">
    <form-login login-processing-url="/resources/j_spring_security_check" login-page="/login" authentication-failure-url="/login?login_error=t"/>
    <logout logout-url="/resources/j_spring_security_logout"/>

    <!-- Configure these elements to secure URIs in your application -->
    <intercept-url pattern="/login" access="permitAll" />
    <intercept-url pattern="/resources/**" access="permitAll" />
    <intercept-url pattern="/**" access="isAuthenticated()" />
</http>

To see this example running, create a roo project with that roo script:

// Spring Roo 1.1.5.RELEASE [rev d3a68c3] log opened at 2011-12-13 09:32:23
project --topLevelPackage de.humanfork.test --projectName localtest --java 6
persistence setup --database H2_IN_MEMORY --provider HIBERNATE 
ent --class ~.domain.Stuff
field string --fieldName title
controller all --package ~.web
security setup
web mvc language --code de
web mvc language --code es

Then you must only change the security filters intersept-url patterns like I have shown above (applicationContext-security.xml)!

Now you have a application where the user can change its local via the local change interceptor in the application (when the user is logged in) as well as when he is not logged in (in the login page)

Share:
10,970
Nirwan
Author by

Nirwan

Updated on June 04, 2022

Comments

  • Nirwan
    Nirwan about 2 years

    My first question here and i'll try to be specific. I am quite new to Spring and i'm trying to create quite simple reservation system (but this actually doesn't matter). What matters is that I am creating some basic template which i will then fill in by real webpages. Application works on hibernate,mysql, I also setup i18n and spring security. The poblem is that I cannot change my locale. The only thing which works is changing the default one. First I browed Web A LOT and I found out that usage a i18n together with spring security is more complicated that usually. What i found out is that i need to have additional filter:

    <filter>
        <filter-name>localizationFilter</filter-name>
        <filter-class>org.springframework.web.filter.RequestContextFilter</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>localizationFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
    

    What I found out is that this filter is indeed processed before the security one however it does not parse the request in a form: http://someserver.com/bla/home?locale=en. I debugged it and it seems that it's not created for such purpose (and that's what I need). This is taken from spring sample "contacts" however in this example I couldn't find any code that was actually targeting in changing the language. The effect is that it simply doesn't work. It always tries to change locale to my default one. The good news is that if in debug mode I manualy changed the locale-to-set to some other one it worked fine so i felt hope in my heart... ;-)

    Then i've found some other way - by creating our own filter. What i did is to merge found example (don't remeber author) together with the way how RequestContextFilter is created. After all the RequestContextFilter works fine - just donest parse my requests. That's code of the new filter:

    public class InternationalizationFilter extends OncePerRequestFilter {
    
    @Override
    public void destroy() {
        // TODO Auto-generated method stub
    
    }
    
    
    @Override
    protected void doFilterInternal(final HttpServletRequest request,
            final HttpServletResponse response, final FilterChain filterChain)
            throws ServletException, IOException {
        final String newLocale = request.getParameter("locale");
        if (newLocale != null) {
            final Locale locale = StringUtils.parseLocaleString(newLocale
                    .toLowerCase());
            LocaleContextHolder.setLocale(locale);
        }
        try {
            filterChain.doFilter(request, response);
        } finally {
    
            LocaleContextHolder.resetLocaleContext();
        }
    }
    
    }
    

    As you can see the request paramter locale is parsed and the locale is set. There are 2 problems: 1. After sending request xxxxx?locale=en it creates Locale without "country" attribute (only language is set). To be honest I don't know if it's any problem - maybe not. 2. The more serious problem is that it doesn't work... i mean it's in the right place in the filter chain (before the security one), it produces right locale and sets it in exackly the same way like RequestContextFilter... but it simply doesnt work.

    I would be very happy if someone could let me know how to make i18n work with spring-security basing on my example given or any other...

    Thanks!

    ADDITIONAL INFO: I made some experiments and it seems that the Locale instance from request is somehow specific.

    Look at this code (modified the RequestContextFilter class):

        @Override
    protected void doFilterInternal(final HttpServletRequest request,
            final HttpServletResponse response, final FilterChain filterChain)
            throws ServletException, IOException {
    
        final ServletRequestAttributes attributes = new ServletRequestAttributes(
                request);
        final Locale l = Locale.GERMAN;
        final Locale l2 = request.getLocale();
        LocaleContextHolder.setLocale(l,
                this.threadContextInheritable);
        RequestContextHolder.setRequestAttributes(attributes,
                this.threadContextInheritable);
        if (logger.isDebugEnabled()) {
            logger.debug("Bound request context to thread: " + request);
        }
    (...)
    

    if to this method: LocaleContextHolder.setLocale(l, this.threadContextInheritable); I pass locale 'l' it doesn't work at all. I mean the locale doesn't change even thou it's explicitly changed. On the other hand if I pass there Locale 'l2' which is modified to german (in debug mode) it works fine!

    This means that for some reason the Locale instance from request.getLocale() is somehow favored, maybe something is going on later on in the code which I don't know/understant...

    Please let me know how should I use this i18n together with security cause I got to the point where I must admit that I have no idea what's going on...

    -====-======-======--=======-====

    FINAL SOLUTION/ANSWER (but still with little question) Thanks to Ralph I managed to fix my issue. Previously I was going the wrong direction but the roo generated project pushed me forward. It seems that I kept adding the interceptor in a wrong/not accurate way (previous code):

    <bean id="localeChangeInterceptor"
    class="org.springframework.web.servlet.i18n.LocaleChangeInterceptor">
    </bean>
    <bean id="localeResolver"
        class="org.springframework.web.servlet.i18n.CookieLocaleResolver">
        <property name="defaultLocale" value="pl"/>
    </bean>
    <bean id="handlerMapping"
        class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping">
        <property name="interceptors">
            <ref bean="localeChangeInterceptor" />
        </property>
    </bean>
    

    This way the interceptor was never invoked for some reason.

    After changing interceptor def to:

    <mvc:interceptors>
    <bean id="localeChangeInterceptor"
    class="org.springframework.web.servlet.i18n.LocaleChangeInterceptor">
    </bean>
    </mvc:interceptors>
    
    <bean id="localeResolver"
        class="org.springframework.web.servlet.i18n.CookieLocaleResolver">
        <property name="defaultLocale" value="pl"/>
    </bean>
    
    <bean id="handlerMapping"
        class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping">
    </bean>
    

    ... it started to work fine without any other changes to security/web.xml.

    Now the problem is gone however I am not sure what happened. From what i understand in the second example (the one that works) I made the interceptor "global". But why the interceptor definded in the first example didn't work? Any hint?

    Thanks again for help! N.

  • Nirwan
    Nirwan over 12 years
    Ok thanks for quick answer - that's what I expected. Maybe you could put me on the right path also in case of the main issue (locale change). Thanks again!
  • Ralph
    Ralph over 12 years
    @Nirwan: see my extended answer - It does not really explain why it does not work for you, but it guides you to an example where the local change interceptor works well.
  • Nirwan
    Nirwan over 12 years
    thanks Ralph. With the roo example I managed to get it running finally. Like you've said there was no need for manual implementation... Please look at my Question for details what was wrong - maybe you will be able to tell me what I actually did cause I am not sure ;) Anyway thanks again!!!
  • denis
    denis about 12 years
    The problem with this implementation is that it is simply Spring MVC specific. When you need to obtain the Locale inside a custome Spring Security authentication handler you won't have the correct one set. The localeChangeInterceptor is Spring MVC specific. :(
  • JBCP
    JBCP about 10 years
    @and-dev - I have the same issue, its a few years later, but how did you solve this?