Smarty Forum Index Smarty
WARNING: All discussion is moving to https://reddit.com/r/smarty, please go there! This forum will be closing soon.

Advanced Authentication->Permissions, Templates and Smart

 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Smarty Forum Index -> Tips and Tricks
View previous topic :: View next topic  
Author Message
fabhren
Smarty Rookie


Joined: 29 Jun 2003
Posts: 9

PostPosted: Mon Jul 28, 2003 2:23 pm    Post subject: Advanced Authentication->Permissions, Templates and Smart Reply with quote

Hyia all,

Lemme first express my genuine gratitude to AZTEK fabulous multilanguage solution in the first thread of this forum.

After this (it was really necessary!), I wonder and challenge if it has been already done Wink :

Has anybody thought of an advance permission system within smarty, kinda like a plugin that is header all templates and requests a certain level of permission or authentication. My idea is to have groups of users/roles of users which set certain levels to certain areas in each template, determining what you can/cant activate/deactivate/read/write/change/eliminate or general access ?

Has anyone thought of this yet ?

Greetz all and happy smartying,
Fabhren
-------------------------------------
'Simple people make simple mistakes. Important people make colossal mistakes'
Back to top
View user's profile Send private message
CirTap
Smarty Pro


Joined: 04 Jun 2003
Posts: 106

PostPosted: Mon Aug 04, 2003 7:08 am    Post subject: Reply with quote

hi fabhren,
I'm working on two larger projects that requires all of this: l10n/i18n, a14n/a11n (authentification/authorization Wink ), using roles/postions and -- if I can make it reasonably fast enough --, implement an ACL system (access control lists) based on what I learned as a Lotus Domino administrator.
I'd love to share any ideas, and if your're interested, we can stick our heads together and make it happen Smile
So far the following is "designed", but much of the PHP code is still in early alpha stage:

  • simple strings and descriptive text is maintained in the database, using a similar design as the "List of Values" in Siebel CRM. This allows -- what I call it --, automagic fallback translation when used with two or more languages.
    If the user's locale is french (fr) and for some "values" only the english translation is available, the english text will be taken instead. No big deal sof ar, but you can actually have use as many languages as you want to do this, e.g. with all the entries from the browser's accept-language, with respect to their priority. This may certainly result in some sort of "esperanto" if some bits are missing, but the default language of the site should always be "complete".
  • object authentfication uses a hierarchical system with people, (nested) groups, and (nested) lists. Individuals can have "aliases", eg. a person may write/publish an article as "Author X", but is logged into a forum posting as "User Y". Using any alias of a person can be used to identify (and authorize) the person behind.
  • "objects" (as one can say so) may be a single "item" (edit/save/delete-button, link, URL), to page-fragments (forms, menus), to pages and "views" and have a default ACL which is bound to the underlying class.
  • the concept of the ACL requires each "object" to have an Owner, this owner may grant others to be this object's Editor, Author or Reader. In addition each object has a default ACL, which may be inherited from its parent (if you can't see a form, you can't edit the value of a textbox in it). Of course it's not possible for the Owner to apply Author access it's "article-object" to some User/Group/List that's are unable to even see the link leading to it's page - he can do so, but it won't work.


My LOV.class is pretty generic and running, so it can be hooked in basically any "translation system". You can write your own output handler to have the results as the original assoc array, in XML, flat-file, whatever.
I'm more or less evaluation different tools to do the local selection, but my favorite so far is part of PHP-FLP's i18n, as it provides all the functionality I need to hop between locales and it handles other tricks like dates, currencies, and numbers.
However, I'd like to reduce any locale- and LOV-retrieval orgie to a minimum and my favorite solution is to finally have/produce simple "/locale/lang_xxxx.php" files as they are used by this board.
I experienced that it's possible to determine the "needs" of a page or pagegroup and predefine them as a named set (can be the page group or section), which is a compilation of the various LOV entries.
Again, this can and should be hierarchical: in the database you'd define a set of strings to translate all the labels, captions and help texts for a form, basen on existing entries if the LOV table, then for every page that requires this form, it'll will "load" its very own string-set. In practice this would mean that a set is "bound" to any instance of this form.

Now for the Smarty's ACL Wink ...
As mentioned before, a page/view is built from individual "items", which it's supposed to know before its rendered. Each item can have actions (those you listed) and/or a status (enabled). Because each item has its own ACL, it will propage the ACL to its parent upon request. At the top you have the godlike Auth object which knows everything about the current user: names, memberships in groups, lists, it's roles etc. Witht his information, the topmost object starts too collect it's children, and each children does the same: page -> menubar -> submenu -> menuitem -> link. If submenu decides that the user as insufficent grants to see it, the process stops, on the other hand, if grants are given, the "link" object may have a status "disabled" and only renders the text, but not the <a>anchor</a>. This may be due to maintenance of the "URL-object" which is the child of this link...
Because each URL finally represents a page/view, any currently disabled URLs will cause a "unavalable" message from the system.
In case a user does not have access to the editing form, the system will give tell Smarty to use "read-only" view-template for the data or nothing. This requires a (conditional) template to be available for every item that has multiple status.

That's it Smile Want to participate? Cool

Have fun,
CirTap
Back to top
View user's profile Send private message
irbrian
Smarty Rookie


Joined: 08 Oct 2003
Posts: 32
Location: USA

PostPosted: Wed Jun 23, 2004 8:30 pm    Post subject: Reply with quote

Just curious, did this ever get anywhere?
_________________
I Create. Therefore I Am.
Back to top
View user's profile Send private message Visit poster's website
CirTap
Smarty Pro


Joined: 04 Jun 2003
Posts: 106

PostPosted: Thu Jul 08, 2004 2:25 pm    Post subject: Reply with quote

hi,
thanx for asking. I totally forgot about this posting Smile
To be honest: development on this has been very slow as I only touched the code when a (new) project really required any of this, and I only implemented what was needed.
The LOV stuff is done but a bit "rough" to use. There is no real integration into Smarty yet, such as a "translate" function or modifier to use in the templates. It all still happens on the PHP side using assign('foobar', 'translated phrase')
I have finished the retrieval part as described in my post and added caching of the LOVs for language sets.
As there is no "LOV Editor Application" available yet, populating the database with new lists of values is mainly happening either in phpMyAdmin or by writing individual import scripts in PHP.

The ACL is currently very complicated to maintain if you don't have an editor either Smile Especially editing the nested lists (groups) and various types like Person, Alias, List, Server is a pain in the neck.
So we currently use (and test) this with simple authentification only on some very recent projects.
The integration with Smarty templates is on the top of the list and planned in the near future (see below), but as long as the ACL isn't really finished, we still use "normal" handmade scripts to determine authorization, like user access to an "item" on a page.

We didn't made it yet to write any interface or application to edit and maintain the LOV, ACL, or resource authorization, so if things had to be done quick (a usual), we often dropped the idea of using them ourself, because there was either no time to add all the data or a lack of "inspiration" on how to add a new requirement to the data or class models.

I must confess, that the majority of websites we create, either don't need i18n (because the client doesn't want it or is unable to provide the content necessary -- no money, no time, noone to do it), or we end up with simple array based translations ($lang['keyword'] = "phrase") which are proven to work, and are easy to maintain in order to have maybe an German and English version of the site.
Most of our client's sites also don't need any auth, or there's only a handful of people editing some records via a web-interface. So why bother with fancy auth systems, rules and nested groups?

However, the project is definately not dead at all as we really need this stuff ourself: not only are we sick to constantly rewrite or modify the same scripts over and over again for every new site that needs a "little different kind of" authorization, but for a long-termed client project which requires the website to be available in literally any language spoken on this planet: an international website for linguists Smile
So thanks to this website, the projects are likely move on a little faster in the next few months Very Happy

CirTap
Back to top
View user's profile Send private message
irbrian
Smarty Rookie


Joined: 08 Oct 2003
Posts: 32
Location: USA

PostPosted: Mon Jul 19, 2004 6:03 pm    Post subject: Reply with quote

What I'm really interested in is the ACL/authorization stuff. I think it would be fantastic if there were a way to protect templates and build in some kind of access-permission system, but I'm not sure how it could even be done. I'd be interested in hearing more about your plans in that area.
_________________
I Create. Therefore I Am.
Back to top
View user's profile Send private message Visit poster's website
CirTap
Smarty Pro


Joined: 04 Jun 2003
Posts: 106

PostPosted: Mon Jul 19, 2004 8:38 pm    Post subject: Reply with quote

irbrian wrote:
What I'm really interested in is the ACL/authorization stuff. I think it would be fantastic if there were a way to protect templates and build in some kind of access-permission system, but I'm not sure how it could even be done. I'd be interested in hearing more about your plans in that area.

You probably suffer from the same "point of view" as we did in the beginning: you have records and tables in your database you want to give or deny access to.
Wrong.
You *do* have webpages that render a specific collection of fields from your database to build "documents" containing a specific set of data, and you have templates and forms that display this data for reading or editing.
Your application needs to have a set of "data views" and a set of "display templates", each of them have a specific "data source", which is usually built from a specific "SELECT something FROM somewhere".
What we do, more or less, is to name each of these queries and assign this name to the "page template" in question, i.e. the "UserProfile".

Then we define an ACL for the "UserProfile" template which looks somehow like this (simplified)
- (Default) -- No Access
- "Guests" -- Reader
- "Members" -- Author
If a visitor is not logged in, he's assign "(Default)" access and sees nothing*), if she's in the "Members" group, she can read a "UserProfile", if she's a "Member" she can also edit *her* "Document" using the UserProfile Form.
*) in fact she woudn't even see the link to the User Profile.

The records that result from this query are our "Documents", and a user is the owner of the finally composed document made from several records, not of "her" user record, "her" address record(s) or "her" fone-number record(s).
As a result we don't have a single "owner" field in any of such tables like §users", "addresse", "contacts", but a "documents" table which has information of the individual (physical) records involved -- and each with an ACL Smile

So we have:
A "named query" (dataview) which returns a well-known list of fields; this combination can have an ACL to define who may "use" this query (and at least see/read all the fields it returns).
A View assigned to the dataview having another ACL to downgrade the list of users who successfully passed the dataview's ACL to a lower level, and to possibly reduce the list of fields, to finally fetch the ...
Documents that share the same fields as the origin dataview, and displays them, whilst each Document may further match the current user against it's own ACL ("is this my owner?") to allow the View to display an "edit" link .. or any other type of command.

Whenever some piece of data is shown, the Template (object) *knows* what may possibly happen next in chain with the Documents it contains. If it knows, "they might be edited, it queries each document's ACL in order to show the "edit button/link" or not.
This happens for basically any "resource" that's behind a specific page or URL. The navigation (object) may also have an ACL for its parent to find out if the user's allowed to use it (bunch of links to admin pages).
As a navigation object itself refers to a "named query" with an ACL, we can group some URLs which require access control.
The data source for a named-query is not necessary the database.

Because of the seven access levels and five usertypes available, the ACL object is built from bit-masks which allow very quick compares and db-searches, rather than having 12 or 20 fields for each level or usertype -- with most of them being empty: how many "is_admin" records do you find in an application database -- and: who's an admin, and where, and for what resource?

This frees us from having dedicated "users", "persons", or "groups" tables. They're all in one "names" tables and a type field with the bitmask.

Besides having ACLs, all user and resources have "hierarchical" names (at least internal), which allows us to avoid creating a zillion groups and bother the database to search and join hundreds or thousands of records.
It's similar to using namespaces. If a resource like an Issue Tracker application belongs to a different namespace, any user which is not in the same namespace is automatically rejected. She does not even know it exists.
If I want a user to access the issue tracker, I add her to a group of that namespace. When she logs in, the session stores the names of all groups (or namespaces) she's a member of. Then the names are matched agains those in the ACLs.
Done. Smile

That's a very rough sketch of how it's implemented. The current documentation spreads ~ 10 pages or so Smile and includes the finegrain control using Roles and such down to the field level, and is based on this document The ABC's of using the ACL.

I hope to have and implement as much of the flexibility Lotus Domino allows Smile

CirTap
Back to top
View user's profile Send private message
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Smarty Forum Index -> Tips and Tricks All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP