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
BedrockMission!

Learn More

View all

Sign in to view all badges

AEM 6.2 Author Dispatcher

Avatar

Avatar
Validate 1
Level 2
bmccurdy1
Level 2

Likes

8 likes

Total Posts

13 posts

Correct Reply

3 solutions
Top badges earned
Validate 1
Give Back 3
Give Back
Boost 5
Boost 3
View profile

Avatar
Validate 1
Level 2
bmccurdy1
Level 2

Likes

8 likes

Total Posts

13 posts

Correct Reply

3 solutions
Top badges earned
Validate 1
Give Back 3
Give Back
Boost 5
Boost 3
View profile
bmccurdy1
Level 2

21-03-2017

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

View Entire Topic

Avatar

Avatar
Validate 1
Level 2
bmccurdy1
Level 2

Likes

8 likes

Total Posts

13 posts

Correct Reply

3 solutions
Top badges earned
Validate 1
Give Back 3
Give Back
Boost 5
Boost 3
View profile

Avatar
Validate 1
Level 2
bmccurdy1
Level 2

Likes

8 likes

Total Posts

13 posts

Correct Reply

3 solutions
Top badges earned
Validate 1
Give Back 3
Give Back
Boost 5
Boost 3
View profile
bmccurdy1
Level 2

22-03-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.