Extbase Authorization/Permission Layer

Archive Discuss Topics
1

Websites nowadays are not about publishing content so much any more but also a lot about data handling in extbase.
TYPO3 lacks a very important layer which is the security layer. There are ideas about creating a role based approach with the rbac extension but in this case you can either call an extbase action or not at all.

What is missing is a nice layer for checking permissions if you are allowed to modify data or not.

Speaking about the blog_example, you should be able to edit your own post/comment but not others.

I fell in love with Laravel which has a really great layer for that: https://laravel.com/docs/5.6/authorization

I really love the simple way of calling a policy just by these lines:

if ($user->can('update', $post)) {
    //
}

and define in the policy, if you are allowed to update the post or not.

I’m aware of the “initialize” actions in extbase but the permissions checks should be abstracted into an own layer and not in the controller imho.

What do you think about that?

2

I think it should be, technically, possible to use Doctrine for this. There should be a way to configure how the current request can interact with persistence:

  • Allow retrieval of data.
  • Allow updating of data.
  • Allow deletion of data.
  • …

This way the code itself does not need to be changed in any way and keeps clean by only providing business logic. Access restrictions should be implemented once in the Framework, which is Extbase for example.

This is also coupled to https://decisions.typo3.org/t/api-layer-for-reading-and-changing-content-based-on-tca/418 from my point of view. As both are also about a permission layer controlling who is able to interact with which data in which way.

Once this is done, together with https://typo3.org/community/teams/typo3-development/initiatives/persistence/, it should be already implemented and there is no need to implemented it again for Extbase.

So better join forces and get it right in TYPO3, where Extbase is built on.

3

I’m sorry, but category “site feedback” is about suggestion about decisions,typo3.org, not about arbitrary topics.

In general this page here is dedicated to make the TYPO3 core development process and decision finding more transparent, not about general discussions about feature ideas (unless mentored by one or more core team members)

Thanks

4

Helmut, I was not able to choose a different category. I think that’s a wrong configuration in this system here.

5

I would greatly appreciate a “core” implementation of handling extbase permissions / ACLs, not only in FE use cases, but especially when writing extbase backend modules. It is hard to explain to your customers that they can configure every access detail inside TYPO3 - except for the special BE module you coded just for them.

I’ve written a custom extension to handle this (sadly not public yet since it has a few limitations). A few ideas from my implementation:

Persistence is not the only relevant part to protect. I divided the access management into three parts:

  • Persistence/Object access. Use case: Some blog entries are marked as “internal” and are only delivered to specific user groups/roles. Very handy feature, slims down repository code. In my implementation you could define access based on specific property values inside a domain object.

  • Action access: Limitations on which controller action a user can do.

  • Template/partial access: Extends or slims down the user interface. This part is probably the trickiest. I did not implement it because, well, fluid is a bit more complicated to hook in here.

The API allowed for blacklists as well as whitelists, example:

$configuration->forRole(“BlogReader”)->disallowActions([“create”, “edit”]);

Of course the target audience for such a feature should also be discussed. If this is mainly for developers/integrators, a config file / TCA / API is fine.
If website administrators should be able to handle access, there probably needs to be some kind of visual access module in BE and additional meta information provided by extension developers (so actions become more “human-readable”). This probably goes a bit too far and exposes too much logic to the backend user.

Also, just for inspiration, symfony has security / access package as well: https://symfony.com/doc/current/security.html

6

maybe it makes sense to have a look into the FLOW permission model. It’s really flexible and nicely to configure in the yaml files

7

As Helmut said, Threads for core relevant topics may only be started by core team members (suggested by everyone, but you have to find a core team member to mentor you) as we want to avoid having discussions without decisions/resolutions. Please read the guidelines for this platform (especially the pinned post in the discussion category).

To continue, please look for a core team member willing to mentor your topic (and aligning that with the existing persistence initiative for example). To discuss topics more freely use Slack or - in the future - talk.typo3.org.

9

Moved as archive post to discuss category and closed.