Smarty

[irbrian]

This question isn't so much technical as a request for advice. I've got several templates that have options in them that are different for, or only available to, administrator users. Currently I'm just doing something like:

{if $access.permission == "admin"}
<!-- admin html links and stuff -->
{/if}

but this is obviously not very safe, since the template designer could easily make the admin stuff available to everyone. Now, the only things that ever get put inside that kind of condition are links and buttons, and occasional input fields; the actual actions they link to check for access permission internally (within the PHP code and database), so nothing is ever going to be ruined as a result of someone monkeying with the templates. But I'd like to come up with a more secure way of showing the admin options within the template, without keeping the html in the PHP code, which would defeat the purpose of the template system.

Any thoughts?
_________________
I Create. Therefore I Am.

[Duncan]

If your designer has access to the template files, then addressing the admin functions via the templates surely won't be any good, so that one solution would be to hard-code it into the code.

However, I would never do it like this, since anything layout related belongs into the templates.
So, the easiest way in such a case: don't allow the designer direct access to the template files

[irbrian]

Heh, yeah, I'd certainly considered that option as well unfortunately, I don't have that level of control. I'm developing the application for a client that will most likely run the application from some unknown host and handle administration themselves. They are just as likely to ask someone else to revise the templates, if necessary, as to ask us to do it.

I'm worried that this will end up being one of those problems with a significant number of so-so or downright crappy solutions and no really great (discovered) solution... but it seems like this would be a problem someone would have come across before, so I've still got a bit of hope left. Any input would be appreciated.
_________________
I Create. Therefore I Am.

[boots]

In principle, you can have another set of templates (perhaps even in a different template directory)that conatined all of the admin related snippets to which your end-users would not be able to touch. You can then include them using a custom resource which would first verify the user condition and hence allow you to determine if you should return the template or not.

[mohrt]

i think you've got it right. There is no stopping a template designer from creating links to administration pages. As long as you check for access in the PHP code when the page is requested then you are fine. I have stuff in the templates like this all the time:

[irbrian]

I completely agree that in-template authorization is a formality. There is no way, in my application, that even a template designer could gain the abilities of an administrator, since every action performed requires proof of proper authorization before the action is carried out.

But I'm still hoping to achieve a scenario wherein display authorization logic is handled within PHP, so that it's more difficult, and less tempting, for template authors to gain visual administrative privileges (buttons and links).

Based on inspiration from Boots, here's what I'm considering right now, though I'm not sure yet whether it will be as useful as it is complicated:

Once the user has been authorized as an admin, I'll instantiate a new Smarty object. I'll use a different directory, called for instance protected_tpl, to store mini-templates with administrative controls. A trusted template designer would have access to this directory to modify these templates. In PHP, I'll use output buffering to capture the output of any admin templates that are required for the current page, and store them in variables, which will then be used in the general templates, i.e:

[mohrt]

So what is stopping a template designer from re-assigning $GRANT? This looks more like "security by obscurity" to me. I guess it depends on what is more important to you: obscuring admin buttons, or clean understandable templates.

[irbrian]

If the template designer re-assigns $GRANT, they are breaking the admin's ability to view administrative options... that is clearly not a good thing, but they'd have that ability anyway (by simply deleting the source that displays the admin controls); and at least this way they don't have the immediate ability to add admin controls into the page.

Furthermore, I don't feel that having a bunch of {if admin}display this{/if} conditions is any cleaner than just inserting an appropriate variable containing previously-rendered output. Consider:

[irbrian]

...but you know, on the other hand its probably not even worth the time. I think I'm just going to keep using the {if $permission='admin'} method for now. It doesn't seem very secure, in terms of displaying admin controls, but there don't seem to be any options that are secure.
_________________
I Create. Therefore I Am.

[mohrt]

[boots]

[irbrian]

I'm not too familiar yet with Smarty resources... perhaps I'll research it and consider this idea for a future version of the product. Thanks for the suggestion.
_________________
I Create. Therefore I Am.