search

changcheng / wro4j

Automatically exported from code.google.com/p/wro4j
0 stars 0 forks source link

css image request causes http 403 #530

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

Consider following situation:

1.
The browser renders a page with a css style sheet that was served by the wro 
filter. The browser caches the css content.

2.
The server is restarted.

3.
The browser renders a second page which references the same css style sheet as 
in step 1. Because of the browser cache there is no server hit to the wro 
filter.

4.
The second page references a css image (e.g. a background image referenced in 
the css style sheet). The css image causes a wro request to "wroResources" with 
a certain "id".

This is the first request to the wro filter at all! The corresponding css style 
sheet is not yet parsed.

5.
The css image is processed by class ResourceProxyRequestHandler.
The class verifies the access for the css image with the help of a
ResourceAuthorizationManager.

Unfortunately, this manager is not fully initialized.
This causes a http 403 respond (see method 
ResourceProxyRequestHandler.verifyAccess()).

The access order of the css style sheet and the css image is crucial. This is a 
serious bug.

There is no problem if the css image is requested *after* the corresponding css 
style sheet is requested (by any client).
But the bug occurs if the css image is requested and no client has requested 
the css style sheet.

The ResourceAuthorizationManager has only been initialized if the css style 
sheet is accessed and parsed.

What version of the product are you using? On what operating system?
WRO 1.4.8.1

Original issue reported on code.google.com by g...@inasys.de on 27 Aug 2012 at 8:12

GoogleCodeExporter commented 9 years ago 
Indeed, this is a problem. What do you suggest as a solution for this issue? 
Bypassing proxy resource requests and not using ResourceAuthorizationManager is 
not an option, since it may cause a serious security hole. The 
ResourceAuthorizationManager is stateful. It is sensitive to a server restart.

Original comment by alex.obj...@gmail.com on 27 Aug 2012 at 9:40

GoogleCodeExporter commented 9 years ago 
Yes, bypassing the ResourceAuthorizationManager would be a serious security 
hole.

A possible solution:
Parse all registered css style sheets when WroFilter.doFilter() is called for 
the first time. 

        if (isFirstRequest()) {
          parseBundlesSuchThatRequestHandlerStateIsInitialized(); // TODO!
        }
        if (!handledWithRequestHandler(request, response)) {
          processRequest(request, response);
          onRequestProcessed();
        }
        onProcessComplete();

Original comment by g...@inasys.de on 27 Aug 2012 at 10:08

GoogleCodeExporter commented 9 years ago 
Don't you think that issue will get fixed automatically by fixing issue529 ?
By setting image headers correctly, there will be no requests for images as 
long as css referring those images is not requested. 
Thoughts?

Original comment by alex.obj...@gmail.com on 27 Aug 2012 at 2:32

GoogleCodeExporter commented 9 years ago 
Look at the scenario described above. You have two different pages using the 
same css style sheet. The first page does not use any css image. Consequently, 
the browser has no reason to load the image (in step 1). Only the second page 
(in step 3) references the css image. If there is a server restart between 
these steps the problem can occur. 

The same problem arises for a server cluster (without any server restart). The 
request to the css style sheet is directed to server 1. But the css image 
request is directed to server 2.

Original comment by g...@inasys.de on 27 Aug 2012 at 2:59

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 7 Sep 2012 at 8:08

GoogleCodeExporter commented 9 years ago 
Solution approach:

- Allow configure the resources to allow to be served through 
ResourceProxyRequestHandler. This will ensure that resources are served 
properly also when application is deployed on multiple nodes.

Original comment by alex.obj...@gmail.com on 12 Sep 2012 at 1:13

GoogleCodeExporter commented 9 years ago 
Fixed in branch 1.4.x. 

Not it is possible to configure the ResourceAuthorizationManager (which is an 
interface) implementation. A convenient implementation is available in 
extensions module which is called 
ConfigurableAntPathPatternsResourceAuthorizationManager and which allows 
configure a list of patterns which will be allowed. This interface doesn't 
accept add or remove of authorized uri's by default.

Original comment by alex.obj...@gmail.com on 22 Sep 2012 at 2:28

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 27 Sep 2012 at 12:24