[TYPO3-mvc] access control & localization: are they killing the idea of extbase by now?

[Andreas Rieser]

Hi Sebastian and Masi!

Am 06.01.2010 um 15:49 schrieb Sebastian Kurfürst:
>> Well, implementing Access Control via AOP is beautiful - but no  
>> AOP no
>> Access Control doesn't convince me ;-) Sadly you are right, there  
>> is not
>> to much access control stuff in pibase - atm I can only think of the
>> typical cObj->enableFields() for generating additional stuff for your
>> where-clauses. But I think it might be a good idea to put  
>> something like
>> this and perhaps a bit more in Extbase.
> I'll be happy to discuss any API somebody comes up with :-)

The first question should be, what makes sense here. We already  
mentioned three totally different things:

- cObj->enableFields()
from the end of http://typo3.org/documentation/document-library/ 
tutorials/doc_tut_frontend/0.0.1/view/3/2/

$this->cObj->enableFields("pages").    // Include conditions for  
enableFields
In the case above, the call to enableFields returns this SQL condition:

AND NOT pages.deleted
AND NOT pages.hidden
AND (pages.starttime<=1011726642)
AND (pages.endtime=0 OR pages.endtime>1011726642)
AND pages.fe_group IN (0,-1)

Im pretty sure that extbase already takes care of some of these  
features, e.g. deleted...
I have no idea how far this has been implemented yet. Maybe Jochen,  
can help us out here?

- FE User  / FE Group
That's something I throwed on the list. For me this means a really  
basic access control mechanism. It's a bit like the last part of the  
where-clause above where the group field is checked. But it also  
should allow to check for a list of users. This has to be attached to  
each object like the typical ACL. If the logged in fe user belongs to  
a listed group or is in the list of users, the object should be  
accessable to him. But you can not define which actions are allowed  
to the fe user. In most of my development cases this was totally  
sufficient. My users were in several groups that enabled  
functionality for them (= access to controllers & actions). With the  
basic access control above you could decide which objects are  
available to them. Of course they could use all controllers & actions  
that are available to them, on all the objects that are available to  
them.

- ACL
At least Sebastian is pretty experienced with acl's because of his  
be_acl extension. ACL covers the part that is missing in my  
simplified access control mechanism.
So here you can define which users and groups are able to work with  
which controllers & actions for every single object in the system.


So far so good - but let's have a look at FLOW3 features:

Security Framework
   Clear separation of security concerns trough Aspect-Oriented  
Programming
   Default security by convention (eg. naming of methods)
   User, group and role support
   Extensive monitoring support
   Of course configurable

What's new on the list is role support. For a short introduction have  
a look at http://csrc.nist.gov/groups/SNS/rbac/documents/ 
design_implementation/Intro_role_based_access.htm
Correct me if I got it wrong, but I think role support is something  
that brings back the fun to your life if you are working with ACL's  
on a daily basis  ;-)

If anything is missing in this list, please bring it in.


My answer to this first question is, that acl & role support are a  
nice to have but not really needed as we didn't have anything like  
out-of-the-box access control before.
For me working with users & groups is ok. When we get this up and  
running we could have a look at FLOW3 again and decide if anything  
more makes sense.

What would be needed is a central configuration posibility to allow/ 
disallow access to controllers&actions for users and groups. A really  
nice thing would be a small configuration manager as backend module,  
where you can assign users & groups to the available  
controllers&actions. The resulting configuration files could (?) be  
compatible to FLOW3 or at least the same module could export a FLOW3  
format as well. I'm pretty sure that the part for putting a check  
somewhere in the dispatcher of extbase is not that hard.

So, what do you think of postponing ACL & Roles by now?
After we found a consensus we can discuss a possible API.

>> For me the key question is, does it make sense to use "extbase" the
>> other way too. By creating very basic v4 compatible localization and
>> access control features in extbase now, most of the extbase-based
>> extension would use the same api. If v5 comes in we would find a  
>> way to
>> develop the same api there with an v5-"extbase" package. What do  
>> you and
>> especially Jochen think about this?
> I think while it is generally possible, to me it sounds like very much
> work for the last 5% - so for only a marginal gain. I guess I wouldn't
> work on that, but if somebody wants to try, why not? :)

I'm not sure if this will be a big deal, but I guess not. For me this  
aren't the last 5% because it's clear that extbase will never become  
FLOW3. What I imagine would basically be a small workaround, almost  
like a wrapper. There will be a v5 access control and localization  
concept. Yet there is no answer to the question if the differences  
are some sort of "bridgeable" or not, but to me this doesn't matter  
right now. I'm pretty sure there will be something around like  
languages or FE Users & Groups - and so it should be a doable task.  
Im just talking about something like an importer and the wrapper  
class called "extbase" for providing the old v4 extbase api.

> Given the complex possibilities for localization by overlaying  
> "writing back" an object is probably
> not easy. As long as I can localize the records via standard BE and  
> display them correctly in the FE
> I'm content. Actually tslib offers IMHO also no support for editing  
> of localized records for FE
> users. So here's the same situation as with ACLs, it would be nice  
> to have the feature, but there's
> not a lack in comparison to the "classic" features.
> Masi

Yes, I know - and these are points where I start getting very  
frustrated with v4 FE development.
Well, until now we always found a way to convince people to work with  
the BE list-module and spare the development costs ;-)

But I guess with Jochen and extbase my frustration finally comes to  
an end. To take another really promising quote from forge:

Bug #4639 Localized Domain Models can not be persisted
2009-11-27 17:50 - Jochen Rau
Target version set to Extbase 1.1.0

I'm really looking forward to this!

Greets,
Andreas Rieser