AEM 6.2 Author Dispatcher | Community
Skip to main content
bmccurdy1
bmccurdy1
Level 2
March 21, 2017
Solved

AEM 6.2 Author Dispatcher

  • March 21, 2017
  • 5 replies
  • 2759 views

We are seeing login issues with our author dispatcher when logging in with anyone other than admin. When the admin account logs in everything looks and works as expected. If one of the other users, that was migrated over from AEM 6.0, logs in they appear to login but instead of seeing the projects page they get the following error:

"Resource at '/' not found

Cannot serve request to / in /apps//sling/servlet/errorhandler/404.jsp"

The dispatcher for author does have 1 rewrite rule that simple enforces https, I have switched rewrites off but no change. I have also turned off all cacheing on the dispatcher just to ensure the cache wasn't getting in the way. If users log directly in to the author instance via ip:port there is no issue.

I've not really ever seen this type of behavior before but would appreciate any ideas on the topic.

 

Thanks,

Brien

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by joerghoh

Hi,

I don't think, that this has anything to do with the dispatcher, it's clearly a permission problem. Looks like the users, which are not able to login, cannot read the / node. Login with the admin account and check on the /useradmin console the permissions of some users.

The release notes for AEM 6.1 [1] mention a change in the permissions.

Cheers,
Jörg

[1] https://docs.adobe.com/docs/en/aem/6-1/release-notes/deprecated-removed-features.html

5 replies

MC_Stuff
MC_Stuff
Level 10
March 21, 2017

Hi Brien,

Though description sounds issue at dispatcher since login directly works but from error description getting message from author that means external configuration issue.   Following are possible suspects 

1)     Some rewrite rule & when request reach aem that is additional path & hence not resolving properly.

2)      Browser cache issue Or csrf token was requested when server was restaring.  Please use browser private window and also delete from dispatcher cache the file  /libs/granite/csrf/token.json

Still issue persist please attach the dispatcher and aem logs. 

 

Thanks,

sandeepm744005
sandeepm744005
Level 5
March 22, 2017

You probably need to allow permissions for /apps and /etc under /filter section. Can you please check if these filters are set properly ?

bmccurdy1
bmccurdy1Author
Level 2
March 22, 2017

Thanks for the replies.

To test where the problem is I've turned off all Apache RewriteRules, disabled cacheing, in filters commented out all rules except '/0001 {/type "allow" /glob "*" }' to allow everything ,and cleared the dispatcher cache. Restarted dispatcher, and retested..issue still persisted.

Then created a new user in AEM, tested with the new user in author dispatcher and had no problems. Then went back and reenabled cache, filters, rewrites, etc and retested with the new user, again had no issues with the new user.

All the users that are experiencing issues were migrated from AEM 6.0 to 6.2 using the ACS Commons Tools to migrate ACLs and users.

I've attached the dispatcher configs for the author instance.

joerghoh
Adobe Employee
joerghohAdobe EmployeeAccepted solution
Adobe Employee
March 22, 2017

Hi,

I don't think, that this has anything to do with the dispatcher, it's clearly a permission problem. Looks like the users, which are not able to login, cannot read the / node. Login with the admin account and check on the /useradmin console the permissions of some users.

The release notes for AEM 6.1 [1] mention a change in the permissions.

Cheers,
Jörg

[1] https://docs.adobe.com/docs/en/aem/6-1/release-notes/deprecated-removed-features.html

bmccurdy1
bmccurdy1Author
Level 2
March 22, 2017

Hi Jörg,

   Thanks for the response. So full disclosure, apparently the person that reported the issue didn't mention that it is also resolved when we reassociated his account with the proper groups. So in the end yes, you were right it was permissions, much to my confusion was that it was still *falsely* reported as an issue when it had been corrected.

Terms & ConditionsAccessibility statement

Loading footer...