Hi
After installation of Adobe Service Pack 2 , there is an intermittent alert while accessing any page in CQ. The alert shows "Your request could not be completed because you have been signed out" and after the alert , it redirects it to "/system/sling/login.html" and shows 404 server error File Not Found.
I am not able to figure out why this is occurring. Any help would be highly appreciated.
Solved! Go to Solution.
Also, Can you try starting a fresh AEM with SP2 on it and see if you face the same problem. Just to make sure its not the effect of something custom you guys have developed !
Is this occurring on AEM 6.1?
Views
Replies
Total Likes
Its on AEM 5.6.0
Views
Replies
Total Likes
Whats your Log stating?
Views
Replies
Total Likes
Also, Can you try starting a fresh AEM with SP2 on it and see if you face the same problem. Just to make sure its not the effect of something custom you guys have developed !
Hey Deepikaa
You can raise a ticket with Adobe for the same. It will provide you a hotfix for the same. Also make sure that you are not caching your public pages in the dispatcher.
Thanks
Pankaj
Views
Replies
Total Likes
Running 6.1 SP2 CFP7 our authors also face this from time to time. They may or may not have logged out, and then return to a few days later. The system prompts to login thru our SSO after which they can browse but not edit. The alert opens when any edit is attempted regardless of UI, page customization, and OOTB pages (e.g. /siteadmin). It definitely has something to go with the CSRF token and happens especially after restarting the author instance.
I may have reproduced the problem recently. Since restarting on Friday and logging back on Monday, I found edits generated the popup stating "Your request could not be completed because you have signed out." Of course I am freshly signed in. Looking at the network tab I see CSRF token ( /libs/granite/csrf/token.json ) is loading from disk cache.
Opening the CSRF resource from Chrome's browser disk cache, I see that it is Adobe Manage Services' maintenance page, which is given when their health-check fails. After reloading this resource (not clearing any other cache), the problem was resolved. The CSRF token resource has cache-control set for 'no-cache' (not 'no-store'). The cache is refreshed when the ETag is updated, so that offers efficiency I wouldn't want to change. But the maintenance page has no cache-control whatsoever. In this case, I think we need to set cache-control no-store on the maintenance page. This way hopefully the browsers won't cache the error responses.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies