Expand my Community achievements bar.

SOLVED

custom 403 error page not loaded by sling in CQ 5.6.1, 404 page loaded instead

Avatar

Level 1

Hi, I am trying to trigger a custom 403 error page in CQ based on the respective error code. First of all, as mentioned in the adobe docs, I couldn't find the 403.jsp page in /libs/sling/servlet/errorhandler/ . It only had the 404.jsp. However I had overridden this page by creating a 404 and 403 jsp pages in  /apps/sling/servlet/errorhandler/ and created a default.jsp which handles all the error codes and forward the request to the respective error pages. But even after doing all this, somehow the error code of 403 is not even coming in the errorhandler when an actual 403 happens. I'm getting the 404 error code instead, so cq is loading the 404 error page even when a 403 happens. Can anyone please help me solve this? I want to solve this in the absence of a dispatcher.

1 Accepted Solution

Avatar

Correct answer by
Level 1

Hi guys,

               I managed to nail this one. It was a little bit of a hack but it did the trick. I found that in the instance that I am running aem 5.6, even if there is a 403 error on the page, the request is coming to the error handler as a 404, i.e to 404.jsp. So, I wrote some code to check if the logged in user has access to that particular resource he/she is trying to access. Then I login with as admin to the repo and try to access the same resource again. If the access is granted for admin and not for the user, then it's a 403. I then forward the request to display the 403 error page.

Apart from this, there was a little flaw in the dispatcher config to allow these pages. It was allowing only error pages with .html, while we don't have that in the vanity path.

 

Thanks,

Vivek

View solution in original post

8 Replies

Avatar

Level 10

Hi Vivek,

Even I dont see 404.jsp under libs. I would test this and let you know if it works for me or not.

meanwhile, I could think of couple of options.

1. Add a logic in your 404.jsp and check if it is 403.jsp and fwd it to the respective page

2. Check ACS Commons solution which is a good solution to handle all the error pages - http://adobe-consulting-services.github.io/acs-aem-commons/features/errorpagehandler.html

 

Regards,

Lokesh

Avatar

Level 1

Hi Loki,

            Sure, thanks a lot for the quick reply! 

The code for Option 1 is already in place, but it seems to not work because the status code received in this jsp itself is a 404 instead of an actual 403. Hence it is showing the 404 page. This code is in the apps folder.

Here's the piece of code that handles this currently:

 String message = (String) request.getAttribute("javax.servlet.error.message");
    Integer scObject = (Integer) request.getAttribute("javax.servlet.error.status_code");
    boolean isAuthorMode = WCMMode.fromRequest(request) != WCMMode.DISABLED && !sling.getService(SlingSettingsService.class).getRunModes().contains("publish");
    
    int statusCode = (scObject != null) ? scObject.intValue() : HttpServletResponse.SC_INTERNAL_SERVER_ERROR;

    if (message == null) {
        message = statusToString(statusCode);
    }
    
    response.setStatus(statusCode);
    response.setContentType("text/html"); 
    response.setCharacterEncoding("utf-8");
    
    final String Citrix404Page = "/404";
    final String Citrix403Page = "/403";
    
    String pageURL = Citrix404Page;
    
    if (statusCode == 403) {
        pageURL = Citrix403Page;
    }
    
    if (statusCode == 404 || statusCode == 403) {
        try {
            request.getRequestDispatcher(pageURL).forward(request, response);
        } catch(Exception e){
           //Ignore this error
        }
    } else { //If this is not 404 or 403 Then show relevent error code based on response

 

Meanwhile I will try out option 2 and see how that goes. 

 

Thanks & Regards,

Vivek

Avatar

Level 10

It should work. May be your testing is not accurate & missing something.  How are you testing?

Avatar

Level 1

Hi Sham,

                I am creating a page and then assigning it to a specific CUG in the author instance, then published this page and accessed with a user who is not part of this CUG, but is part of other groups. However while trying to access, it is showing 404 for the user who is not part of the CUG for this page, which should have been a 403 instead. This user is able to access other pages without issue(for which he has access to). Please let me know if I'm missing something.

 

Thanks,

Vivek

Avatar

Correct answer by
Level 1

Hi guys,

               I managed to nail this one. It was a little bit of a hack but it did the trick. I found that in the instance that I am running aem 5.6, even if there is a 403 error on the page, the request is coming to the error handler as a 404, i.e to 404.jsp. So, I wrote some code to check if the logged in user has access to that particular resource he/she is trying to access. Then I login with as admin to the repo and try to access the same resource again. If the access is granted for admin and not for the user, then it's a 403. I then forward the request to display the 403 error page.

Apart from this, there was a little flaw in the dispatcher config to allow these pages. It was allowing only error pages with .html, while we don't have that in the vanity path.

 

Thanks,

Vivek

Avatar

Level 3

Hi,

Have we got any other solution to this or we still have to write the code for identifying user's access information to every resource to catch 403 error?

Avatar

Level 1

Hello Vivek

I have the same scenario, where i have two CUG and each has a user. When one CUG user tries to access page under another CUG he gets 404 and if he tries to access pages under CUG to which he belongs he can access those. Instead of 404 , it should ideally be 403. Did you figured out any other approach apart from first checking resource access via user login followed by admin? If you can also share the implementation you did would help.

Avatar

Level 2

Hi Lokesh,

I was going through this thread as I am also implementing the same.

I am using the solution provided by ACS-Commons and it is the same for me.

403 is not handled, it might be the case that I might have missed something but I do not think so as 404 errors are handled and global fall back is also handled.

Have you tried this before or have any solution in mind?

Regards,

Prateek