Authorization in the view layer.

[ghurtado]

I am currently going through the revamping of our home-brew template system (basically native PHP templates, and little more, very lightweight), and have suddenly run into quite a dilemma regarding the proper place for certain authorization checks. Our home made framework is MVC based (or at least I would like to think that it is, since I developed it ), and the way things currently work, when a user is not logged in, he simply gets redirected to the login page. Simple enough, and it can all be handled in the controller page, so this doesn't really pose much of a problem. The issue is that certain templates that appear in almost every page (like the menu you see once you are logged in), have sections that are dependant on the authorization level of the user (more specifically, what 'privileges' they have within the system), and I am at a loss as to how to handle the situation. I suppose one could say there are two general approaches:

1. The MVC / OOP purist would likely propose to run the auth checks in the controller page, which would then be in charge for setting or unsetting certain portions of the template either through variables or other more complex mechanisms (XML transformations?...). The main problem that I have with this approach is that it feels backwards to the issue at hand (it is the template that needs to know what parts to show or not based on user authorization, and setting this outside the view seems counter-intuitive), and perhaps more importantly, that it would require a lot of repeated code at the top of every page just to set all of these variables in the template that indicate what menu items are visible.

// index.php (controller)

$tpl = new Template();
$oAuth = new UserAuth();

if($oAuth->checkPrivilege('view_users')){
    $tpl->setVar('can_view_users', true); // kinda silly, or ....
    $tpl->setVar('users_nav', '<td>Users</td>'); // much worse!
} 

2. The second approach, more straightforward, but probably breaking some of the nice layering of MVC, would be to pass the auth object along to the template and allow the template to query it for existing privileges whenever it is needed. For simplicity's sake, I feel like this is what I am more inclined to do.

// template.php

<?
$oAuth = $this->_data['oAuth'];
?>
<table width="100%" id="nav_auth">
<tr>
    <td>Store</td>
<? if($oAuth->checkPrivilege('view_users')){ ?>
    <td>Users</td>
<? }
if($oAuth->checkPrivilege('view_pricing')){ ?>
    <td>Pricing</td>
<? } ?>
    <td>Sales</td>
</tr>
</table>

I can't help but to see some potentially serious drawbacks with both approaches, and it almost suggests to me that there is some inherent coupling between fine-grained authorization systems and views, as everything that you see is potentially something that you are "allowed to see" - if that makes any sense.

So what I would like to know is, which one of the two approaches would you go with, and what problems do you foresee with each of them? For the grand prize: is there a third, more natural approach, suggesting some kind of auth merchanism built into the view, or some other way to represent this coupling more naturally / directly?

[lastcraft]

Hi...

I can't help but to see some potentially serious drawbacks with both approaches, and it almost suggests to me that there is some inherent coupling between fine-grained authorization systems and views, as everything that you see is potentially something that you are "allowed to see" - if that makes any sense.

I think you have hit the nail on the head here. You have a "cross cutting concern", that is one that touches a large part of the application pretty much at random. When you get one of these, the usual way to deal with it is to separate the concern off into it's own declarative language and then weave it back into the code in as abstract form as possible. An example of this is CSS, separating the HTML styles into their own language. They are weaved together again from the tag name and the "class" attribute.

Surprise, surprise this is exactly what you have done . Your checkPrivilege() method gets it's information from some kind of (possibly compiled) config file, yes? By always passing the authorisation object into the template you have in effect distributed that config file (permission declarations) throughout the whole system.

In short I prefer teh second approach, although I would question whether you need that much control.

A minor thing also...

What does "Auth" stand for? Authority, Authorisations? If it just a bunch of permissions then how about...

class Permissions {
    ...
    function isAllowed($action) { ... }
} 

To me "if is allowed" reads more clearly than "if check privilege".

yours, Marcus

[ghurtado]

Thanks a lot for your post, lastcraft, it really helps see things clearer and realize that my programming woes are shared by others too.

You have a "cross cutting concern", that is one that touches a large part of the application pretty much at random

Thats where a suitable PHP implementation of AOP would fit very nicely. Being as unlikely as that is, some kind of framework-provided services paradigm might also be a good way to centralize the authorization classes.

"Auth" in this case stands for both Authentication and Authorization and it represents the class that manages authentication and permissions for users of the system, just as you figured. I suppose the reason why I chose "checkPrivilege" as opposed to "isAllowed" is because, in the beginning, we weren't thinking of the entity itself so much as an "Action" as we considered it a "Privilege". At the end of the day, they are the same thing, so I would have to agree that it would probably be much more readable as "isAllowed".

[lastcraft]

Hi...

"Auth" in this case stands for both Authentication and Authorization and it represents the class that manages authentication and permissions for users of the system, just as you figured.

I was kind of wary as I think that authentication and authorisation are two different things. I see a lot of Auth classes and they often seem a bit muddled.

To me an authorisation is a static declaration assigning a permission to a user or a role. It is more a piece of configuration information. An authentication is a split second operation that assigns a group of permissions to a session. You could have an Authenticator class, but it makes less sense to have an Authentication class except for logging purposes. It doesn't seem to have a role to play. An authenticate method on some other class (say the Authenticator) makes more sense to me.

So I sidestepped it by calling it Permissions .

yours, Marcus

[ghurtado]

Agreed, for me too, Authentication is the part that makes sure you are who you say you are and Authorization is the part that decides what you can do, being who you are. Since most people usually think of both as one, I figured it would make more sense in our case to have it all in one class for the sake of simplicity. After all, the Authentication class would only really have 2 methods in our case, login() and logout(), and with such a thin layer and being closely related (conceptually at least) to the Authorization layer, we rolled them into one. In our case too, both the Authentication and the Authorization make use of the session (to store whether you are logged in on the one hand, and what permissions you do have on the other), so one single class simplifies this aspect as well.

I would like to hear from others too what their approach to the 2 Auths is. Anyone else care to share?

[been]

I've also implemented a "simple php-native template system" in the site I'm currently refactoring. But I "expanded" it with 2 other components: Tag and Printer:

The Tag is a simple class that can hold a basic html tag and it's attributes, and it can contain child tags. You could compare it with a DOM widget thingie, albeit a lot simpler
The Printer is basically an Eclipse LoopManipulator, used for displaying lists.
Then I've created 2 global functions: echoTag() and echoLoop(), together with the standard PHP echo, they form the 3 ways of displaying template variables. Although I'm the sole developer on this site, I imagined that this would provide a simple and easy to understand api, should a designer come in to play => explaining the concept of variables is quite easy (not even needed if they have any notion of scripting languages), so echo echoes a normal variable, echoTag echoes a Tag variable and echoLoop echoes a list via a certain printer (I'm thinking I should not start explaining iterators and manipulators, at least not in the very beginning ;-) )

When testing the Template engine, I needed simple Tags and Printers to perform the tests, what I did was create a file NullLayoutComponents, which contains a NullTag and a NullPrinter: These are dumb classes that only have the necessary method declarations, but with no code in them.

This allowed me to create a complete testing template, without the need to develop all the LayoutComponents in it, I just registered a NullTag or -Printer with the template for every component that wasn't developed yet.

And this, luckily, brings me on topic a bit

What you could do is seperate things that will or won't be displayed into such layout components, then, in the controller code you check your Permissions object and register the correct component with the template. Combine this with a small factory, and your controller code could look something like this:

$tpl =& new Template('content.html');
 $tagType = $permissions->isAllowed('view_users') ? 'user' : null;
 $userTag =& LayoutComponentFactory::create('tag', $tagType);
 $tpl->registerTag('User', $userTag);
 if ($tpl->parse()) {
     echo $tpl->render();
 } 

The factory would return a NullTag or a UserTag, depending on the value of $tagType, and the template would not have to worry about permissions, it just would have something like

<table id="nav_auth">
 <tr>
 	<td>Store</td>
 	<?php echoTag($User); ?>
 	<?php echoTag($Pricing); ?>
 </tr>

[ghurtado]

Thats a pretty interesting approach you have there, been, and also one which reminds me of ours in certain aspects. However, part of what I was trying to avoid is to have to repeat the "switching" code in every controller page that makes use of this template, since most pages will be using it (it is the main menu I am trying to set up based on the permissions). I think in the end I will probably give my templates access to the "auth" object to use in permission checks.

[been]

The code I've posted was part of some sort of controller, it could very well be placed into a menu controller, which you would pass the Auth or Permissions object...

It would have the permissions checks implemented into the menu controller, concentrated in one component.
The advantage being you could use any kind of template to display the menu, the menu controller (with the permissions check) would stay the same and the menu templates would remain quite simple.

If you'd pass the Auth object directly to the template, you would have to include these checks in other templates (for example, if you have a skinnable site, or different kind of menus: pure html and css, some sort of dhtml menu, etc...). Or you would extend a base template, but then you'd likely have something like a Basic Template, a TemplateWithPermissionChecks that extends the basic Template, and then maybe a few different MenuTemplateWithPermissionChecks, ...
Maybe it's just me, being not too keen about using inheritance a lot

Maybe some 'pseudo code' to illustrate this a bit further:

 // create the auth or permissions object...
 
 // instantiate the controller
 $menu =& new AuthMenu($auth);
 
 // render the menu with a chosen template
 echo $menu->render(new Template('DHTMLmenu.html')); 

or something like that. Mind you, I'm just thinking out loud here

[SamuliK]

I've been searching a nice way to do these kinds of things too, the clean, simple, efficient and elegant solutions always seem to lurk in the horizon and the horizon never get's closer as I approach it...

But currently I'm implementing the permissions check stuff as permission bits in an integer, one integer per each module in my CMS. The permission bits are stored in the user object instance, which is stored in the sessions for efficiency. For all modules most of the bits are 'standardized', i.e. 1 = read, 2 = edit, 3 = add/delete and so one. User levels can be easily implemented as sets of bits (preset integers).

The templating engine tries to be 'pull from modules' instead of 'push' where you have to know which titles/buttons/etc. you're expecting. The template kind of says' "hey, I'm drawing a menu here, any modules out there with something for me?". Also I'm waiting for the DOMXML to stabilize to enable the modules to "print" their output to the view in any order, regardless of the screen order.

This has lead to a solution where, for example, all the objects (forums posts, comments, pictures, pages, menu nodes and so on) have an unique id with a central database table to maintain the id<-->object type mappings. (A registry?) So what started out as very simple seems to add complexity to itself until it reaches a point of "let's try again from scratch, maybe we'll come up with something simplier this time".

Some sort of caching mechanism would be nice for the most used parts of the template views, and for the most accessed pages a full page file cache would be nice...

I have to take another look at the open source CMS designs and steal all the best ideas.

Just some rambling thoughts on this,
Samuli

[brainpipe]

I've also implemented a "simple php-native template system" in the site I'm currently refactoring. But I "expanded" it with 2 other components: Tag and Printer

I really like this idea, but wouldn't it create problems if you're working with a designer who doesn't know beans about scripting? At the moment, I'm the backend developer on a small web project, and I get the impression that the designer wouldn't know the difference between PHP and Pretty Hot Potatoes. Things like Smarty and your template approach would probably be impossible for her to maintain, and I also don't want to attempt a slice and dice of her HTML because (a) I'm not a designer and (b) I don't even want to think about the time I'd spend troubleshooting if it didn't go as expected. For those reasons, I'm planning to use FastTemplate and handle as much of the authentication -- or permissions -- as possible in the controller. I'm wondering, though, how I could translate your approach to work in my case.

[been]

wouldn't it create problems if you're working with a designer who doesn't know beans about scripting?

Designers that don't know beans about scripting, will always create problems, therefor we should shoot, euh, I mean educate them.

It's been more than a year since I took a look at FastTemplate, but at that time, it also had special tags for loops and conditions, but they seemed more cryptic to me (at least to my php-biased eye). No matter how you look at it, you're going to have to educate your designer in the syntax of your template language. Whether that is native php or an enginge specific language... I'm not touching that discussion with a 10 foot pole I've chosen php, because it was the obvious road to take in my case: I'm on a tight schedule, I needed something that was easy to use for me, but also easy enough for any person with some knowledge about scripting; I simply do not have time to spend on learning a third party template system; certainly not when it concerns quite complex engines like Smarty, and definitely not when I'm already quite proficient in an existing template language (php).

I'm wondering, though, how I could translate your approach to work in my case.

Maybe, you can go about it the same way as I explained in the previous post. In the end, it doesn't really matter what template engine you use, you just have a sort of controller for each "important" template in the view, that handles things like authentication, building lists for views, etc...

I'm not sure at all, but FastTemplate seems a bit of an outdated template engine, no? I could be wrong of course...
WACT's template system seems pretty good to me, although I haven't looked at it in detail yet. Also, it uses an x(ht)ml-compliant syntax, which maybe of great importance in regards to the software your designer uses.

Bottom line: educate the designer in the concept of templates, whether it are smarty tags, php tags, wact-component tags, fasttemplate tags, doesn't really matter, if you can get the concept of templating across, I think you'll be ok.

If you can't get it across, you'll have to whip up some in-between component that translates the designer's output into something that is usable to the backend system automatically.

[brainpipe]

I'm not sure at all, but FastTemplate seems a bit of an outdated template engine, no? I could be wrong of course...

You're right. I hadn't looked at it in years and it's apparently gone the way of the PHP3 dinosaur. Strike that from consideration.

WACT's template system seems pretty good to me, although I haven't looked at it in detail yet.

It does look pretty nice, but the focus is separation of view from model, not separation of programming code from markup code. The tags strike me as potentially more confusing to a designer than something like Smarty or straight PHP; at least with the latter two I can just say, "don't touch anything between the "<? ?>" or "{ }". I'm not even willing to rely on that though.

If you can't get it across, you'll have to whip up some in-between component that translates the designer's output into something that is usable to the backend system automatically.

Now that would be cool. Parse the HTML as a string and do a search and replace. Tough to make it work except on a custom basis though, and probably more work (in my case) than simply adjusting the templates if the designer needs to change the HTML.

I also think I've unintentionally hijacked this thread, although I think the heart of the matter is the same, and it's the question all these templating systems keep trying to answer: When do you compile the template, do you push or pull, and how much logic is allowed in the template? I'm leaning towards ghurtado's straight-PHP pull approach, particularly since the site in question is pretty small.

[sweatje]

Hi ghurtado,

I have serveral systems where I have authenticated users, and I classify them with an access level (as opposed to ACLs, which it appears some others have coded).

My MVC systems are architected using Phrame, and I have a default Action of ShowView that handles figuring out which view is appropriate, instanciating the view, and rendering it. It is in this ShowViewAction that I check for user permissions:

class ShowViewAction extends Action {
  function Perform(...) {
  $view_factory =& new ApplicationViewFactory;
  $view =& $view_factory->Build($_GET['view']);
  $user =& new User();

  if (in_array(get_class($view), $array_of_restricted)
    && !$user->IsAdmin()) {
    trigger_error('Access Denied');
    header(ERROR_REDIR);
    exit;
  }  

  $view->Render();
} 

HTH

[ghurtado]

Jason,

I wish our system was simple enough to be able to go the route of either showing the template or not. Unfortunately, due to the number of diferent employees that use the system, authorization pretty much has to live within the templates, since there is such a fine grained authorization model (probably a big mistake) that some of the templates can be rendered in a miriad different ways depending on the permissions of the user. In some instances it comes down to 9 or 10 spots within the template that need to be displayed according to user permissions. Perhaps a solution to this could be to break the templates up into further components.

[brainpipe]

Perhaps a solution to this could be to break the templates up into further components.

You can do that, but then you have other problems. You have to construct the pages in your program logic instead of in the templates, e.g.:

$tpl->addHeader();
if ($user->hasPrivilege($priv))
{
    $tpl->addAdminLinks();
} 

You also have to manage multiple template components instead of single template pages; this approach certainly has benefits, including dealing with restricted page components, but the obvious downside is dealing with (potentially) many different files that, if changed, could affect a large number of pages. And heaven forbid you should have components in nested tables. Not that this is any worse than the other options, of course.

[ghurtado]

Thats why I think that the most sensitive option for the time being is to assign an authorization object to the template, or at least until I can come up with something more elegant.

[Selkirk]

It does look pretty nice, but the focus is separation of view from model, not separation of programming code from markup code. The tags strike me as potentially more confusing to a designer than something like Smarty or straight PHP; at least with the latter two I can just say, "don't touch anything between the "<? ?>" or "{ }". I'm not even willing to rely on that though.

Well, the intent was to separate the programming code from the template. I'm not saying that we have achieved that. Assuming that you must have a fine grained approach, I suppose you have no choice but add some sort of markup in the template.

In WACT, that could be as minimal as simple as generically marking the section of the templates to use:

<core:block id="securesection">...</core:block>

You could then place all of the checks in the template helper code:

$securesection =& $Page->getChild('securesection');
if (hasPermission("administrator", ...)) {
    $securesection->show(); 
} else {
    $securesection->hide();
} 

Alternatively, you could create a specific tag:

<restricted role="administrator"> ... </restricted>

Now there is no need for new code in each template helper. The code is centralized in the tag. I would have thought that a specialized tag such as this would be easier for a template designer to understand than something like:

{if role="administrator"} ... {/if}

especially when the logic progresses beyond a simple if statement. The drawback to putting anything in the template at all is that you are then relying on your template designer to be careful about security. depending on your situation, this might not be a good thing.

[ghurtado]

Selkirk,

The way you propose to handle the auth is probably the most desirable option of all that I have considered so far. I would probably be more inclined towards the first option, as it carries less semantic meaning associated with the authorization that a template designer might have to deal with. This approach, in my view accomplishes all desired results:

1/ Centralizes authorization code common to all templates

2/ Puts template specific authorization code *within* the template that uses it. Call it auth parameters, rather than auth code, since in this case its being achieved via markup, which is a very elegant approach.

3/ It can be handled by a programmer or a designer with minimal training on the templating system.

I am not sure that any of the other approaches strike those points quite as effectively. In our case, we are a small team, and it's not very likely that anyone other than me will be touching the templates (At least in the near future), so that makes me weigh in more favorably this option as well.

Even if these templates were to be handled by our designer, we should really back away from this primal fear of having a designer "destroy" our applications with their carelesness. It seems to me as though one of the main signatures of success for a templating system is to be "designer-proof", and sometimes its almost as though we are pretending that there is some place where a designer can work on his templates without having ever met or spoken to any of the programmers he is working with. So while it is a good goal to try and separate presentation from logic, lets not get carried away thinking that such a world where design lives separate from logic exists. It doesn't. And in most normal situations you will have designers handling low level, simpleton kind of logic, while your programmers tinker with the color of the browser scrollbars. For as long as there is this overlap, we dont have a "perfect jail" to keep designers in, and communication must still be our safety net to prevent errors. I am saying this because as of late I feel a lot more inclined towards the "smarttags" approach to templating, ala WACT, and I only think that it fits the programming domain a lot better in certain situations (as is this one of authentication).

Fear not, designers are not here to steal our babies!

[Resolution]

In WACT, that could be as minimal as simple as generically marking the section of the templates to use:

<core:block id="securesection">...</core:block>

You could then place all of the checks in the template helper code:

$securesection =& $Page->getChild('securesection');
if (hasPermission("administrator", ...)) {
$securesection->show(); 
} else {
$securesection->hide();
} 

This makes sense and it doesn't even need salt or pepper. Except mabey, lazy loading the template init behind the permission check. Then again that's just plain picky. lol

I disagree on giving the developer access to WHO may view certain views/elements within views for 1or 2 reasons really.

How does the designer know what roles have been set in the permissions? Some developers use a flat table permissions where there are 3 (or whatever number) of groups that are non changable, whichs makes the design easier to implement. But imagine if the roles are dynamiclly created, ordered and authorized - which is what I did for my own permissions.

How would the developer know I changed "Admin" to "HeadHoncho"? if the designer didn't know this crutial info then all the templates with "Admin" permissions tags would be void and break the site function. On the other hand if this style is what is CHOSEN by the development group it is fine and I see no problem with it's use.

It seems to me to simply be a matter of defining business rules for your developer/s. Ease of use vs. long term flexability.


To the lead post:
It really depends on the scope of what you are attempting to do. If it's a not a small project consider seperation of php and HTML first. Second, trying to build a robust permissions will take you (likely) a number of months - it took me about a year. Then again I built for flexability which was difficult at best - for me at least.

I suggest you keep the same implementation but reconsider the design - because after a few templates, editing thouse permissions in the templates might get tedious.

later,
Res

[Mike Borozdin]

// index.php (controller)
 
$tpl = new Template();
$oAuth = new UserAuth();
 
if($oAuth->checkPrivilege('view_users')){
    $tpl->setVar('can_view_users', true); // kinda silly, or ....
    $tpl->setVar('users_nav', '<td>Users</td>'); // much worse!
} 

[/code]

Probably, I still don't understand MVC, but it seems to me that you mixed up controller and view layer there, because there are some template methods in the controller layer. But I think somebody else should answer to this question.

[code]

// template.php
 
<?
$oAuth = $this->_data['oAuth'];
?>
<table width="100%" id="nav_auth">
<tr>
    <td>Store</td>
<? if($oAuth->checkPrivilege('view_users')){ ?>
    <td>Users</td>
<? }
if($oAuth->checkPrivilege('view_pricing')){ ?>
    <td>Pricing</td>
<? } ?>
    <td>Sales</td>
</tr>
</table>

These if statements seem to be a part of presentation logic, so I think it fits MVC standarts, on other hand it's no god to mix HTML code with PHP.

[ghurtado]

Second, trying to build a robust permissions will take you (likely) a number of months - it took me about a year. Then again I built for flexability which was difficult at best - for me at least.

Just to add some clarification about our system, the permissions/authentication/authorization system is all already built, it was the first thing I had to create for the application framework. I would like to think we came up with a very flexible scheme while at the same time keeping it simple enough to understand. The basics of it are permissions, that can either be assigned to users or to groups, and consecuently groups that can contain users, very typical stuff I think. Surprisingly, along with the interface to manage users/groups and permissions, the entire user management system indeed, only took me about 2.5 months to finish. Then again, I was almost exclusively dedicated to that project.