Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

403 on images below jcr:content on dispatcher only

Avatar

Level 5

We are having problems with our dispatcher config setup, Images are being forbidden if they sit below jcr:content. So the following url fails with 403:

http://localhost/content/foo/en/apage/jcr:content/par_top/acomponent/image.img.jpg/1302613914118.jpg The page itself loads and is just missing the images

but an image from the DAM comes back fine. If you go direct to the publisher then its fine. I'm guessing the problem is with the dispatcher config? But I can't see where, I've even tried changing the deny all to allow all! 

Any advice much appreciated. 

1 Accepted Solution

Avatar

Correct answer by
Level 8

Normally when you see this kind of disconnect between author and publish two things are happening - either the web server is has been configured to deny access to the URL (often for security reasons) or a rewrite rule is changing the URL. To diagnose the problem I'd recommend the following steps:

  1. Determine if the 403 is coming from the web server or the Publish server
    1. Depending on configuration the page may display the source
    2. Response headers may tell you
    3. Worst case you should be able to tell by looking at access.log file on the publish server - if the request hits the web server, but never shows up in access.log then you know the web server is generating the error. 
  2. If the request is being generated by the web server look at the following:
    1. Turn up logging on the dispatcher.log to see what dispatcher thinks is happening. The problem may be with the /filter section of dispatcher.any and it may be blocking the request. The dispatcher log will tell you that it is getting the request and denying it. 
    2. Another possibility is that you have rewrite rules at the web server level may be changing the request path. The dispatcher log in debug mode will help you see this because it will log the path and you can see if the path dispatcher is getting is different than path of the request. 
    3. Another possibility is that for some reason the request is not getting sent to dispatcher because of a mis-configuration in httpd.conf. Again looking at dispatcher.log will help identify it. 
  3. If the request is being generated by the publish server the most likely reason is that the URL has been modified by a rewrite rule either at the dispatcher level or in /etc/map or the JcrResourceResolver. The easiest way to debug this is to look at the access.log or request.log and verify that the path that hits the publish server is the same as the request path. If the paths are correct then you best bet is to look at the Recent Request page in the Felix console - the debug information available here may clue you into the problem as well. http://localhost:4502/system/console/requests

View solution in original post

2 Replies

Avatar

Level 10

In webserver cache are you see directory with name 1302613914118.jpg  instead of image?

Avatar

Correct answer by
Level 8

Normally when you see this kind of disconnect between author and publish two things are happening - either the web server is has been configured to deny access to the URL (often for security reasons) or a rewrite rule is changing the URL. To diagnose the problem I'd recommend the following steps:

  1. Determine if the 403 is coming from the web server or the Publish server
    1. Depending on configuration the page may display the source
    2. Response headers may tell you
    3. Worst case you should be able to tell by looking at access.log file on the publish server - if the request hits the web server, but never shows up in access.log then you know the web server is generating the error. 
  2. If the request is being generated by the web server look at the following:
    1. Turn up logging on the dispatcher.log to see what dispatcher thinks is happening. The problem may be with the /filter section of dispatcher.any and it may be blocking the request. The dispatcher log will tell you that it is getting the request and denying it. 
    2. Another possibility is that you have rewrite rules at the web server level may be changing the request path. The dispatcher log in debug mode will help you see this because it will log the path and you can see if the path dispatcher is getting is different than path of the request. 
    3. Another possibility is that for some reason the request is not getting sent to dispatcher because of a mis-configuration in httpd.conf. Again looking at dispatcher.log will help identify it. 
  3. If the request is being generated by the publish server the most likely reason is that the URL has been modified by a rewrite rule either at the dispatcher level or in /etc/map or the JcrResourceResolver. The easiest way to debug this is to look at the access.log or request.log and verify that the path that hits the publish server is the same as the request path. If the paths are correct then you best bet is to look at the Recent Request page in the Felix console - the debug information available here may clue you into the problem as well. http://localhost:4502/system/console/requests