0

I have recently inherited a large .NET project, which needs role implementation to be patched in it. Different roles have different access to the site, and some elements need to be hidden accordingly in relation to the role of the current user.

Given the somewhat flexible and modular architecture, this was easy enough to implement when users try to access portions of the site they do not have access to. However, I ran into problems when authenticating the visibility of controls.

Many of the controls have been implemented through their own project-specific controls, however links are mostly implemented through HtmlAnchors, and some others fields that fall into the restricted category are also generic html elements.

Is there a way I can patch this with a generic adapter, or do I have to rummage through the vast array of controls and elements present in the project and make them inherit a common base where this can be implemented singularily? Manual labor in this case would mean a lot of work, and I am not exactly sure if it is even the right approach in the end.

Basically, is there a way to make all controls and elements of the page run a check whether or not they should be rendered visible, or not in an .NET 4.0 Web Project? And can I somehow manage to patch it so that all elements have the capacity to accept and process a new attribute which describes their 'restriction level'?

Nalaka526
  • 11,278
  • 21
  • 82
  • 116
Jonathan Maxwell
  • 3
  • 2

1 Answers1

0

Yes, you can do that sort of thing. Two ASP.NET features come to mind that might help you out here:

  1. ASP.NET Tag Mapping. This feature lets you change the type of the object that is instantiated when the parser finds a particular ASP.NET tag (so you can, for instance, replace all HtmlAnchors with SpecialHtmlAnchors that inherit from some base class of your choice). You just need to add a tagMapping section underneath /system.web/pages/ in your web.config. (I have not tested this sample, but it should be close to correct. It's a starting point, anyway.)

    <system.web>
  <pages>
    <tagMapping>
      <add tagType="System.Web.UI.HtmlControls.HtmlAnchor, System.Web"
         mappedTagType="My.Special.HtmlAnchor, MyAssembly"/>
    </tagMapping>
  </pages>
</system.web>

  2. ASP.NET Control Adapters. You can tell ASP.NET to attach an output adapter to each instantiated control of a particular type. The feature was originally intended to facilitate output adaptation for particular browsers or browser types (e.g. desktop vs. mobile), but you can do pretty much whatever you want with them. To use them, you create a .browsers file in your App_Browsers folder (if it does not exist, right-click on your web project in VS, mouse over "Add ASP.NET Folder" and select and select "App_Browsers." Then, add your .browsers file to this folder via the "Add New Item..." dialog. Register your custom control adapter by modifying your .browsers file to look something like this:

    <browsers>
    <browser refID="Default"> <!-- all browsers -->
        <controlAdapters>
            <adapter controlType="System.Web.UI.HtmlControls.HtmlAnchor"
                adapterType="My.Custom.RolesAwareControlAdapter, MyAssembly" />
        </controlAdapters>
    </browser>
</browsers>

    Control adapters inherit from System.Web.UI.Adapters.ControlAdapter, which has almost all of the same rendering methods that an ordinary control has. The ControlAdapter takes complete control of the rendering for the control, but can delegate rendering back to the Target control if it wishes.

Regarding adding new attributes to your controls: if you're already going to go through the existing code and add attributes, why not just change the tag type to refer to a custom control while you're at it? Public properties of custom controls get automatically promoted to markup attributes so that you can specify their values at design time.

Another good WebForms approach--although it won't fix the tedium of editing hundreds of pages and user controls--is to use a LoginView, since it's designed to solve problems like yours.

Let me know if you've got any questions; I'll be glad to clarify.

Matthew Schaad
  • 643
  • 5
  • 6
  • Thank you, it got me thinking. I'll go through the software and see what needs to be done -- it might be so that I will actually have to go thorugh much of what has already been done and try to generalize the approach so that I can feed attributes to the controls. – Jonathan Maxwell Jul 10 '13 at 12:27
  • Alright, now the most sensible solution in my mind seems to be this: Go through the whole project, and customize all related controls in a way that they inherit a project-specific rendering-block which has a public property that defines its role-restriction (it is depicted by a small, varying string in the program). Then, as we render these blocks, we should be able to easily choose to hide them instead. This is arduous, but it should prove to be most easily maintainable and modular in the future. Any thoughts on this approach? – Jonathan Maxwell Jul 10 '13 at 16:25
  • I don't quite understand your proposed approach, and I definitely don't understand your problem domain, but it sounds like a LoginView really might be the most straightforward solution. Actually, are you dealing with custom controls or user controls? I think it makes a difference here. – Matthew Schaad Jul 16 '13 at 21:12