Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

Extended Social Component - On Dispatcher/VIP

Avatar

Community Advisor

Hello All,

We have extended OOTB comment component. The comments work fine on publish environments. But while on Dispatcher I see a 404 error on browser console when it tries to load the componet it see at "/services/social/getLoggedInUser.html?moderatorCheck=/content/eNet/en/path" .

We have the following  

# Allow SCF User model to check moderator rules
/6005 { /type "allow" /glob "GET /services/social/getLoggedInUser?moderatorCheck=*" }
in dispatcher ".any" file, as mentioned in  https://docs.adobe.com/docs/en/dispatcher/disp-config.html

Is there anything else that should be considered here?

1 Accepted Solution

Avatar

Correct answer by
Level 9

From the troubleshooting section :

        A major source of problems is inserting filter rules without paying attention to the affect on earlier rules,         especially when adding a rule to deny access.

        The very first filter pattern is often used to deny everything so that following filters restore access in a         controlled manner.  When multiple filters apply to a request, the last filter that applies is the one in         effect.

And this note :

        Property Name Examples
        All property names shown, such as /0050 and /0170, should be adjusted to fit within an existing         dispatcher.any configuration file.

If you only copied one rule from the sample filters, then you need to ensure it is properly integrated into your dispatcher.any.

Any sample dispatcher configuration is only for illustrative purposes.  Dispatchers must be tuned for each deployment.  If you need more help than you're willing to show in an open forum, you could open a request for support.

- JK

View solution in original post

2 Replies

Avatar

Correct answer by
Level 9

From the troubleshooting section :

        A major source of problems is inserting filter rules without paying attention to the affect on earlier rules,         especially when adding a rule to deny access.

        The very first filter pattern is often used to deny everything so that following filters restore access in a         controlled manner.  When multiple filters apply to a request, the last filter that applies is the one in         effect.

And this note :

        Property Name Examples
        All property names shown, such as /0050 and /0170, should be adjusted to fit within an existing         dispatcher.any configuration file.

If you only copied one rule from the sample filters, then you need to ensure it is properly integrated into your dispatcher.any.

Any sample dispatcher configuration is only for illustrative purposes.  Dispatchers must be tuned for each deployment.  If you need more help than you're willing to show in an open forum, you could open a request for support.

- JK