views:

84

answers:

3

fHi,

I need to build an site with some portal like functionality where an param in the request will indentify the portal. like so http:/domain/controller/action/portal

Now my problem is if an portal doesn't exists there must be an redirect to an other site/page and an user can login in to one portal but if the user comes to an other portal the user must be redirected back to the login page for that portal.

I have something working now, but i feel like there must be an central place in the pipeline to handle this. My current solution uses an custom action filter which checks the portal param and sees if the portal exists and checks if the user logged on in that portal (the portal the user logged on for is in the authentication cookie). I make my own IIndentiy and IPrincipal in the application_postauthentication event.

I have 2 problems with my current approach:

1: It's not really enforced, i have to add the attributes to all controllers and/or actions.

2: The isauthenticated on an user isn't really working, i would like that to work. But for that i need to have access to the params of the route when i create my IPrincipal/IIndenty and i can't seem to find an correct place to do that.

Hope someone can give me some pointers, Richard.

A: 

You can enforce user authorization through an attribute in the controller. You would apply this to each action (both get and post). I think it's reasonable to add some sort of validation to each action within the controller to write secure code, please correct me if I'm wrong here.

vikp
Its an option, and thats what i'm doing now. But i think its not the right approach since its actually an application wide thing and not on an controller level. In other words i think the application must enforce the rules and if the portal doesn't exists redirect and not even bother trying to go to some controller. It's should be more like the route doesn't exists and there is no where to go but redirect. The same goes for the user identity it shouldn't be authorized for the hole application if hes going to an portal he isn't logged in for.
Richard
+1  A: 

There's a couple different ways you could do this (as always...). If you want to do it in the controller (or via an attribute) but you also want to do it globally, then you could always use a custom base controller class and apply the logic there. The actionfilterattribute is inherited and bob's your uncle.

ON the other hand, this really feels like a routing concern to me. So I'd probably consider creating a custom route to handle what you're doing. If you do that, then once you get it working you'll want to test it out under load to make sure that you have a good caching strategy in place (so that every request isn't a db lookup for the route + another one for whatever happens in the controller).

Paul
A: 

For the missing portal redirect, I would handle this in routing. If you have a relatively small number of portals, you can do this by creating a unique route for each of your controllers and then setting a default route for the redirect. Routes are evaluated in the order you create them, so just put the default route at the bottom. Your route registration would look something like this:

routes.MapRoute(
        "Portal1",
        "{controller}/{action}/FirstPortal",
        new {controller = "defaultController", action = "defaultAction", 
             portal = "FirstPortal"}
    );

routes.MapRoute(
        "Portal2",
        "{controller}/{action}/SecondPortal",
        new {controller = "defaultController", action = "defaultAction", 
             portal = "SecondPortal"}
    );

routes.MapRoute(
        "Default",
        "{controller}/{action}",
        new {controller = "defaultController", action = "defaultAction", 
             portal = "Default"}
    );

This way you can use the "portal" route value to select the portal, and any request that does not match will be routed to the controller/action specified in your Default route, which can take care of redirecting the user appropriately.

nslowes