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

Andreas Rieser A.Rieser at T3site.com
Tue Jan 12 14:28:37 CET 2010


Am 07.01.2010 um 07:08 schrieb Sebastian Kurfürst:
> Hi,
>> - cObj->enableFields()
>> from the end of
>> http://typo3.org/documentation/document-library/tutorials/ 
>> doc_tut_frontend/0.0.1/view/3/2/
> enableFields is fully respected, but you can disable it for your own
> queries if you do:
> $query->getQuerySettings()->setRespectEnableFields(FALSE);

Thank you, good to know.

>> 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.
> Agreed so far.
> I'd suggest that if you are interested in trying such thing out,  
> create
> a new extension which encapsulates your proposed way of access  
> control.
> IMHO it is enough to create an extended version of the  
> ActionController
> and put the access control logic into that controller - and you'll use
> that one.

Yes, see Jochen's post below.

> So, I'd suggest that if you are interested, just try it out and try to
> make a prototype :) I'd like to have some working code which we can
> discuss, as this is a lot easier then. Additionally, I think such code
> parts should *not* be part of Extbase itself when they are created, as
> this is still the "incubation" phase of such a feature - that's why  
> I'd
> suggest using a separate extension for now, and if everything is  
> working
> nicely, we can then integrate it into extbase.

The big problem as always is time. I already got a first impression  
of Extbase & Fluid while developing some random test extensions. For  
know I'm struggling with DDD while modeling a first draft of my  
domain. It's quite a big one, I guess - i have to deal with a small  
shop, the management of production (mostly just-in-time so deep  
interaction with the shop), billing with HBCI-integration and a  
customer portal with functionality like saving datasets and  
visualizing them. So please don't expect too much from me in the  
short run. But I will take that route and would be glad to contribute  
something in the long run.

Am 07.01.2010 um 11:09 schrieb Jochen Rau:
>> 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.
>
> That's my opinion for the localization topic, too. We should try to  
> replicate the already built in features of TYPO3 and add new  
> Features later on. The localization (and workspaces) should work  
> already in the FE direction (please file an isue if not). I have  
> tried to implement "reverse" mapping but struggled due to the lack  
> of time before the release of Extbase v1.0.2. So, I'll be glad if  
> anybody can provide an implementation for this.

It's great that this already seems to work. I have a customer project  
in the pipeline where it might get quite interesting concerning the  
use of IRRE and localization. When this job comes in I probably can  
provide you with further feedback. Currently I have no need for the  
"reverse" mapping, as I don't want to manipulate localized content  
through the FE in my project.

> The access topic is more in focus to be imlemented in Extbase 2.0.  
> I would like to have a solution that enables us to define ACLs the  
> FLOW3 way and "connect" them with the acces rights implementation  
> of TYPO 4.x. That could be another top-level configuration  
> "security" and offer the same options as described in
>
> http://flow3.typo3.org/documentation/manuals/flow3/ 
> flow3.securityframework/#AccessControllLists

Thanks, didn't know that section.

> As we probably never backport AOP to 4.x (lets keep some things to  
> FLOW3 ;-)), we will have to implement access control half- 
> transparently and not ressouces aware, which is no handicap imo.  
> The point to hook in is imo the AccessController::processRequest()  
> method as we have to check access rights to arguments. But we can  
> also hook into the RequestBuilder.

I'll try ActionController::processRequest() first... ;-)

> Any other Ideas?


The question is how to "connect" these two worlds properly. Did you  
spend some time on this? I think in v4 the v5 roles can be expressed  
by FE&BE groups and FE&BE users. So it would be a good thing to  
invent a role in v4 as well. The roles could be linked to FE&BE  
groups as well as directly to FE&BE users. BTW: Are roles defined  
system-wide? Or isn't this a matter of one package/extension?
Then we could adopt the concept with the security top-level  
configuration and combine it with my suggestion of a BE module for  
changing this accordingly.
ACL's regarding content should imo reside somewhere in the repository  
logic, but that's the next step I guess...

Andreas


More information about the TYPO3-project-typo3v4mvc mailing list