Question

I’m trying to implement a small ASP.NET MVC site which interacts with another site. In short, sessions are managed between the main site and satellite sites through tokens in the URL. I can specify the url format but I can’t remove the requirement that a session token is submitted as part of the URL.

I’m trying to work out how to set up the routing and am in a few minds here. I can’t decide which would be best, or if there is perhaps a better way to do it. The main ways I’m thinking:

routes.MapRoute("Main", "{controller}/{action}/{id}/{token}");

Gives URLs like http://mysite.com/Products/Detail/5/5f1c8bbf-d4f3-41f5-ac5f-48f5644a6d0f
Pro: mostly keeps with existing MVC convention for site nagivation
Con: Adds complication to routing when supporting defaults for ID and Action.

routes.MapRoute("Main", "{token}/{controller}/{action}/{id}/");

Gives URLs like http://mysite.com/5f1c8bbf-d4f3-41f5-ac5f-48f5644a6d0f/Products/Detail/5
Pro: simplifies routing – can still apply action/id defaults as per standard MVC convention
Con: very “un-web-like” URLs. Requires regex to validate that the first variable is a valid GUID / token before moving on to next route in the table.

The other possibility coming to mind, passing sessions like:

http://mysite.com/Home/Index?session=5f1c8bbf-d4f3-41f5-ac5f-48f5644a6d0f

The related problem with that is I have a base class derived from Controller which all other secure pages are going through. The SecureController class overrides Execute() and checks for the validity of the token taken from the URL. Both approaches (GET and routing) seem like it would be easy enough to get the token within the controller Execute() function, but the GET approach feels kind of tacky whereas the routing approach feels like it’s, for lack of better explanation, breaking the elegance of the MVC routing design.

Has anyone else out there taken on a similar problem and had any particular successes or difficulties to share?

Answer 1

It seems no matter you do, your URLs will be pretty messy with that token.

I have had to handle this kind of single sign-on functionality in an ASP.NET MVC app as well, but I went for a slightly different and much simpler approach: I created a GatewayController with a SignOn action that took a session token and a URL as parameters.

Then this SignOn action would just check the validity of the session token and then sign the user on to my site, redirecting to the supplied URL. From then on, the session token is not needed anymore, as authentication from then on would be cookie-based.

It might not be entirely applicable in your case, depending on your requirements. If you are required to continuously check the validity of the session token somewhere, you could however just do the same thing as I did and then store the session token in the user’s session data, allowing you to check the token in each request.