Results 1 to 7 of 7

Thread: How to secure <mvc:resources>?

  1. #1
    Join Date
    Oct 2008
    Location
    On your screen
    Posts
    50

    Default How to secure <mvc:resources>?

    Hello everyone,

    I'm having a little trouble with my webapp. Recently I had to configure it to serve some static content, so to that purpose I used the following in my applicationContext.xml:

    Code:
    <mvc:resources mapping="/data/**" location="/path/to/my/files" />
    That works just fine on its own and the static content can be displayed. However it can be displayed without athentication, so I added to my security configuration:

    Code:
    <intercept-url pattern="/app/data/*" access="fullyAuthenticated" />
    But it doesn't work. I can still access the static content without athentication. Is there something I'm missing?

    Thanks in advance!

  2. #2
    Join Date
    Jan 2008
    Posts
    1,826

    Default

    What is the URL of the resource rendered in the html that is not being secured? Did you try using ** instead of *? You may need to remove /app if it is the context root or is not part of the URL to your resource (i.e. you are using UrlRewriteFilter). In addition to securing the URL you may also want to wrap the resource tag with the authorized tag so it is not even requested. This will help with performance.
    Rob Winch - @rob_winch
    Spring Security Lead
    Pivotal

  3. #3
    Join Date
    Oct 2008
    Location
    On your screen
    Posts
    50

    Default

    Thanks for the reply rwinch.

    Actually, the static resources are mostly pictures, I don't know if that has anything to do with, and the URL of the resources is in the form of: http://hostname:8080/app/data/resource.jpg, so if I remove the /app I get a 404 error.

    I already tried using ** instead of * but the result is the same.

    I will try to render the resources from a .html file and see what happens.

  4. #4
    Join Date
    Jan 2008
    Posts
    1,826

    Default

    I was referring to removing /app from the intercept-url. When specifying pattern for intercept-url you should not not include the context root in it (Spring Security calculates the context root portion dynamically). Give the following a try:

    Code:
    <intercept-url pattern="/data/**" access="fullyAuthenticated" />
    Also note that enabling debug logging can help a lot in situations like this (in case you have an issue like this again).
    Rob Winch - @rob_winch
    Spring Security Lead
    Pivotal

  5. #5
    Join Date
    Oct 2008
    Location
    On your screen
    Posts
    50

    Default

    I tried your suggestion and it didn't work... Thanks a lot rwinch, I guess I'll try the logging thing to find out what's going on...

  6. #6
    Join Date
    Jan 2008
    Posts
    1,826

    Default

    A few other things:

    1) The order of intercept-url matters, so the first pattern that matches the URL is used. You might need to move the intercept-url I mentioned up higher. You might provide your entire http configuration block.
    2) Is the Spring Security filter-mapping the first entry in your web.xml? Also is it mapped to /*?
    3) Is the browser caching the image? If so, then Spring Sescurity will not be consulted. You will want to ensure that you disable caching of the protected resources by setting the cache headers.

    If none of those work try enabling debug logging and post the logs for a request to the image.
    Rob Winch - @rob_winch
    Spring Security Lead
    Pivotal

  7. #7
    Join Date
    Oct 2008
    Location
    On your screen
    Posts
    50

    Default

    It wooooooooorked!

    Thank you so much rwinch! First I bumped up the intercept url, that alone did not work, however I think it was a good recommendation. Then I checked my Spring Security filter-mapping and it was configured with servlet-name element instead of url-pattern. I corrected it and my resources are now safe and secure!

    Regarding your third point, it was also true... If I login and access my resources and then logout, the browser caches the images, so I will get working on those cache headers...

    Once again, thank you very much rwinch, your help has been invaluable!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •