Secure functional areas

ajj3085 posted on Tuesday, October 24, 2006

Hi,

My application has a look and feel similar to outlook 2003.  Based on the users role, I want to disable entire fucntional areas.  For example, I have a Products group of items in the Explorer bar (the bar you see which displays Inbox, Calendar, Tasks, etc.).  I need to remove access to the entire group if the user has no business doing anything with Product administration at all.

What's the standard practice here?  Just create a class in the business layer that allows the UI to figure out if an entire area is off limits?

Thanks
Andy

Bayu replied on Wednesday, October 25, 2006

Hey,

I assume your BOs already respect the ristrictions of different user roles, i.e. you are not trying to program security restrictions in your UI.

Then it is indeed just about how you inform your UI of irrelevant use cases for the current user role. There are several options:
- you make your Explorer bar items data-driven, based on business objects like ExplorerBarAction (which would inherit ReadOnlyBase). Then security restrictions can be made a dynamic concept in the context of your relational model.
- you can use a technique similar to what is included in CAB (Composite UI Application Block)
    - you don't place explorer-bar items directly into the explorerbar
    - all 'requests' for explorer bar item go through an ActionServiceController class (or whatever the name is)
    - this ActionServiceController checks security restrictions before actually adding the explorer bar item
    - these security restrictions could reside anywhere, in the code of the controller, app.config (yeah, user can edit these, but hey your BOs restrict security after all anyway), database, registry, webservice, ...

In CAB this works pretty nice, since every module that gets loaded requests it's own set of actions to be added to the explorerbar (through the ActionServiceController). But despite the fragmentedness of the modules, security rules can be maintained in one (holistic) place.

Bayu

SonOfPirate replied on Wednesday, October 25, 2006

May I suggest a version of the Model-Controller-View pattern where your UI element is simply a presentation tool.  You would need a controller class that sits between the UI element and your business object(s) whose role is to interprete the BO data and security and use it to drive the UI.  So, your controller class would include or exclude items from your UI based on the security access the current user has.

I like this pattern because I can use the same controller to drive multiple UI's for the same app (e.g. Win Forms, ASP.NET, Mobile, etc.) or I can have multiple controllers to handle my business objects differently based on need (such as two apps with different purposes making use of the same data & BO library).  This puts another layer of abstraction and decouples the UI and BO's even further.

Hope that helps.

 

ajj3085 replied on Wednesday, October 25, 2006

Hmm,

Interesting, I just finished the MVC chapter in my patterns book.

It doesn't seem like the view would even be listening to the model though, as there's no other state it cars about.  Is this how you implemented this?

Bayu replied on Wednesday, October 25, 2006

Hello,

It's an old discussion of MVP vs MVC, i.e. Presenters vs Controllers. The discussion is not what I bring to be bear, merely the key insights:

- the less the view knows about business logic the better reusable it will be

- what a view must know is how to display a certain types of business objects
    - you could even make use of reflection, so that the 'certain types of' can be removed from the previous phrase
    - naturally your view might contain some logic, but this should all be UI-related logic (e.g. layouting)

- all the business logic (e.g. validation, security, save/insert/remove) then resides in the controller (or presenter, what's in a name...?)
    - preferably it is fully ignorant of the particulars of the view it is currently controlling (presenting)
    - to enable this, you will have to design an interface for communication from the view to the controller that is independent of UI-specifics, so don't pass specific UI event args around or anything that is tied to your specific view, all these details should be taken care of within the view, and the communication of certain UI interactions to the controller should reduce to UI-independent function calls


Ultimately, you should be able to reap the following benefits:
- you can attach the same view to different controllers, so if you change business-logic or have different variations of business logic depening on some context, your view does not need to know: it should only be concerned with rendering the object to the UI, so swapping controllers should be free
- you can attach the same controller to different views (independently or even simultaneously), since the controller is unaware of any rendering logic swapping views is free (or attaching multiple views to one controller simultaneously)

- you can push view-reuse further when using reflection, then the same view can be used to display any object, different object types will simply result in a different controller being attached
- the same applies for controllers: you could program your controller against BusinessBase(Of T), so anything that derives from BusinessBase can be managed by the same controller, different object types would then result in different views being attached
- if you do the two together: you can manage an arbitrary object with the same base views and controllers (I have just 4 views and 4 controllers, which manage all my 50+ business objects)

- only in some cases I have special requirements for a particular view, in which case I make a specialized subclass of my base-views, the same applies for special behavioral requirements which involve a specialized controller, note: views and controllers can be specialized (and subsequently reused) independently


In summary, MVP or MVC are often stated as a goal, but they are not. Reuse is the goal, and MVP and MVC are key paradigms towards achieving this.

For more details I could elaborate on my implementations. Let me know.

Regards,
Bayu

burmajam replied on Tuesday, July 03, 2007

Hi Bayu,

More than half a year has passed since you wrote about usage of MVP/C pattern with CSLA. I'd like to hear if you are still satisfied with it and if your offer for elaboration of implementation is still active, I'd like to here whatever you could tell us on that topic.

Regards,