Default behavior and the scenario
On asp.net in general, when an user tries to access a page that requires the user to login first, it is fairly common to use the built in support to return to that page after the user logins.
When an user tries to access the page and an authorization made by the code determines the user doesn’t have access, a 401 is returned by that code. When that happens the FormsAuthenticationModule intercepts it and instead redirects the user to the login page configured in the asp.net config.
When the redirect to the login page is sent, it includes a returnUrl query string parameter. On a successful the user is sent back to that url. If no return url is indicated, the user is sent to a default url after authentication.
The above works fine, if the scenario fits well with the site.
One consideration is with the use of register and forgot password options, in which case extra code needs to be put in place if you want the user to be redirected to the url visited when the process started. A similar case is if the user visits any other page linked there, like a faq or about page and then hitting the login option you almost certainly have in your master page/layout.
Another consideration comes with the user of ajax based login forms accessible anywhere on the site. Depending on the site, the user might be on a page where you don’t want it redirect to. You still might want it redirected to a page the user visited before doing some action, like in a client’s scenario, a specific deal page.
The cookie based approach
One way to handle the above scenario is by storing the returnUrl in a cookie. By doing so the user can visit other pages (like the register/forgot password options), and the redirect will go to the last relevant page. Additionally you can control which actions are considered relevant pages, in case the user uses the login option in your master page/layout in any random page they happen to be at.
To set the cookie in an unauthorized access scenario, one could use a module based approach just like the FormsAuthenticationModule. In our case, we instead introduced an AuthorizeWithReturnCookieAttribute, and replaced the use of [Authorize] with [AuthorizeWithReturnCookie].
To set the cookie when a relevant page was visisted, we introduced a separate attribute ReturnAfterAuthenticationAttribute. Unlike the authorize attribute, this one is used on public pages, we want the user redirected back to if the login option in the master page/layout is used.
There are a few more things going on in the above attribute.
- We can avoid it being set based on logic executed in the action method, by setting true on the corresponding value in ViewData. In retrospective ctx.Items is probably the right place for it.
- No point in setting the cookie if the user is already authenticated.
- Post requests are not tracked.
For a more complete sample, the modified logon and register methods of the asp.net mvc template below. It still supports the returnUrl and gives it precendence (not what we did in our case, as we only use the cookie one).
The NavigationCookies class just sets/gets the cookie:
I added a full sample that uses the asp.net mvc 3 template to the following github repository: https://github.com/eglasius/Cookie-Based-ReturnUrl-After-Authentication-Sample. You can download a zip file of it directly at: https://github.com/eglasius/Cookie-Based-ReturnUrl-After-Authentication-Sample/zipball/master.