I agree, this workflow should be much different. Do you think the access denied page is even needed? Why not just redirect to the login page with a message stating that access to the requested content is restricted? That would cut down on clicks and most people understand that they need to login to see content if a login page is presented.

Hi Crispin,

I'm looking through the code and currently you're going to get mixed results depending on what you are not allowed to see. For instance, regular CMS pages check if you can view a page, if not it checks if you are logged in, if not you get login page. If you are logged in and you can't see the page, you're redirected to the AccessDenied page.  The blog posts are the same way.  But, PageSettings.aspx checks to see if you are in a role which allows you to see the page settings page and always redirects to the AccessDenied.aspx if not; it doesn't check to see if the user is authenticated first but the methods it uses to check for role membership does but those don't redirect anything, they just provide true|false.

So, we need to go through and standardize everything. Any page like PageSettings.aspx needs to require you to be logged in before you can see them so they should check if you're authenticated before checking roles. Anything that requires login  and the user isn't logged in should redirect to the login page. 

To be clear, there isn't a security problem here. The workflow is just a mess because there is no standardization. 

I'm going to add code to the login page to check the return url and not use it if it is AccessDenied.aspx. I'm also removing the need for the EditAccessDenied.aspx page because having two is not necessary. 

You can change the content of the AccessDenied.aspx page by modifying the /Data/MessageTemplates/AccessDeniedMessage.config

Thanks,
Joe