1

I have a number of projects (some commercial, some not) in which both field- and resource-level access are needed. Naturally, it would be nice to use and contribute to an ORM project rather that re-inventing the wheel, but I've not been able to find a project with any kind of access control layer; it seems most of them leave that up to the domain objects, and those classes cannot inherit from a super class.

It may be possible to fork Doctrine--but again, I'd prefer not to dive in solo.

Bryan Agee
  • 4,924
  • 3
  • 26
  • 42

2 Answers2

1

My choice as ORM has always been Propel (v1.5), I find it lighter, faster and easier to understand. It also has custom behaviors, which could be the starting phase of your access control plugin, at least for resources.

You can see some docs on behaviors here, and this wiki explains pretty well how to build your own.

Hope I can help

David Conde
  • 4,631
  • 2
  • 35
  • 48
  • I also looked through propel (still reading through the source actually), but it doesn't address access control any more than Doctrine, and requires the Zend Framework--a heavy piece to add if you're already committed to some other framework on the domain side. – Bryan Agee Apr 06 '11 at 23:51
  • 1
    Where did you find that Propel requires Zend Framework ? AFAIK it's not the case. – Maxime Pacary Apr 07 '11 at 07:32
1

Creating a DB structure for user access control, and building the code that will make the defined rules effective, is not the ORM job (it will help you to do it, but it won't do it for you).

However this need of access control is frequent (named ACL or RBAC; it seems that you're looking for an ACL), and some projects have already emerged, which create all the DB structure for that, for example sfGuard (Symfony) or Zend_ACL (Zend Framework).

Check those SO threads too:

Community
  • 1
  • 1
Maxime Pacary
  • 22,336
  • 11
  • 85
  • 113
  • What we're looking to do is much finer-grained then RBAC, and the reason that I can't see how to separate it from ORM is that the field level access control needs to work whether a domain object is loaded into a working model, or some fields are loaded in a custom query/mapping. – Bryan Agee Apr 06 '11 at 23:31
  • Since we handle a fair amount of sensitive data, internal controls require that we not allow one person to access certain combinations, so the ORM is the only thing both low enough to enforce the Access Control at a field level, and yet high enough to understand the implications on actual resources (mostly one-to-one with domain objects). – Bryan Agee Apr 06 '11 at 23:34
  • Sorry, I've quite ignored the "field-" access control requirement in your question... After some Googling I didn't find anything interesting already existing for that. You should give a try to the "Propel behavior" idea of David Conde's answer (since you wouldn't have to "fork" Propel, you would still be able to upgrade it even after adding your code as a behavior). – Maxime Pacary Apr 07 '11 at 07:47