AOP and Security for UI Elements

I am working on an application in which we are doing our best to separate the separation of problems. We find that end-to-end safety concerns create a number of complications.

However, it seems that they can be mitigated using attributes and aspect-oriented programming.

I understand this in relation to aspects of the domain code, but what if you want to apply it to user interface elements? For example, what should I do if I do not want to display a button when the user does not have permission to execute this function?

In our MVC application, at this point we will have to write (pseudocode follows):

<% if (user.CanSeeSomeData) { <%=Html.TextBox("MyTextBox") } %> 

But we would like to manage the display with attributes a la AOP, if possible.

Any ideas?

Also, if there are third-party open source tools that would be helpful, these suggestions are welcome.

+6
aop asp.net-mvc domain-driven-design
source share
1 answer

I would say that a view should not contain much programming (or nothing at all). The idea of ​​using AOP (or aa AOP) in a place where P is forbidden does not look very good.

Let the design be different. Typically, submissions have keywords for managing basic materials: conditions and cycles. More intelligence, and I would say that you mix the role of the controller there.

So, if (user.CanSeeSomeData) you put there if it is actually a simple flag. This is how views should look.

When you build the modelview object (the container in which you put the information for the view). You could use AOP to initialize / set this information with a good attribute in this property, for example.

You can request attributes instead of "ifs"

 [UserCanSeeData] <%=Html.TextBox("MyTextBox") %> 

It looks like syntactic sugar, not real AOP. Any attempt to say that UserCanSeeData should have more than if (for example, access to the database to check user privileges) is an attempt to move the controller code into the view.

+1
source share

All Articles