I have a user that has an inherited role of PERM_USER_READ.
when i tried to call $this->isGranted('PERM_USER_READ'); it always returns false. Is it the default behavior of the isGranted() ? If so, what can i do to evaluate inherited roles on my Twig and Controllers?
Thanks!
Try to rename your role to ROLE_PERM_USER_READ
Symfony 4 answer:
I find the ROLE with inherited ROLEs very confusing, so we've adopted a "a ROLE gives you ALLOWS"-system:
ROLE_PRODUCT_MANAGEMENT:
- ALLOW_PRODUCT_EDIT
- ALLOW_ASSORTMENT_READ
We ONLY check on ALLOW_* 'roles', which made everthing 100% less confusing.
We've ran into the same problem as you have. I've fixed that by creating a service which does the following:
// /vendor/symfony/security-core/Role/RoleHierarchyInterface.php
$reachableRoles = $this->roleHierarchy->getReachableRoleNames($user->getRoles());
// Check wether you have the required role, can you see this ENTITY in general?
if (!in_array('ALLOW_PRODUCT_EDIT', $reachableRoles, true)) {
return false;
}
Symfony 5 answer:
Unfortunally: none so far. From the source of RoleHierachyInterface:
* The getReachableRoles(Role[] $roles) method that returns an array of all reachable Role
* objects is deprecated since Symfony 4.3.
We're currently in the process of upgrading to Sym5, we havent arived at this point yet. If anyone has a neat solution for this, that would be great.
The role must start with ROLE_
As said in documentation
Every role must start with ROLE_ (otherwise, things won’t work as expected)
Other than the above rule, a role is just a string and you can invent what you need (e.g. ROLE_PRODUCT_ADMIN).
Related
I have five custom voters in my application and use strategy "consensus".
Sometimes my voters not work properly and after debugging I have found the reason.
The standard Symfony RoleHierarchyVoter always returns "1", therefore sum of "granted" results equals to sum of "deny" results. So, I need to disable this Voter, because I don't use RoleHierarchy.
1) How can I disable Voter in config?
2) Does it exist another solution for this issue?
Thanks a lot for any help!
UPDATED.
So, I have created own RoleHierarchyVoter which always return false.
This Voter replace standard Voter, but I'm not sure this solution is true way.
Maybe any other solutions?
So, currently I have solved the problem by creating own RoleHierarchyVoter, which always return false.
Currently impossible to remove definition of standard RoleHierarchyVoter, because it's registered with priority TYPE_BEFORE_OPTIMIZATION and performed before my own compiler.
Btw, you can find in SecurityBundle/DependencyInjection/SecurityExtension.php next lines:
private function createRoleHierarchy($config, ContainerBuilder $container)
{
if (!isset($config['role_hierarchy'])) {
$container->removeDefinition('security.access.role_hierarchy_voter');
return;
}
$container->setParameter('security.role_hierarchy.roles', $config['role_hierarchy']);
$container->removeDefinition('security.access.simple_role_voter');
}
Even when I set role_hierarchy: ~, isset($config['role_hierarchy'] will return true.
This issue has reported as bug https://github.com/symfony/symfony/issues/16358
Documentation of the RoleVoter says:
RoleVoter votes if any attribute starts with a given prefix.
The default prefix the RoleVoter will check is ROLE_, passed as default parameter value in the constuctor. These are required, because the voter has to check the current logged in user.
Make sure your own voters implements VoterInterface and also check the voter's implementation of YourVoter::supportsClass. The FQN of the element of which you want to know the user has access to should be checked over there. Then the following config should be enough:
app.security.download_voter:
class: AppBundle\Security\Voter\DownloadVoter
public: false
tags:
- { name: security.voter }
So:
1) You should not disable this voter, because all other voters rely on the RoleHierarchy this voter does create for the current user when passing a vote.
2) For better understanding of the Voter you can let the DIC inject the logger in your voter, and add extra info to the profiler. That way your own voters aren't a black box anymore.
I am attempting to migrate from version 3.2.0 to 3.3.0. I am getting a compile error. I could not find an entry in the "Breaking Changes" section but here are my two errors in hope someone can guide me to a workable alternative.
public void RegisterTypeSingleton<T>(Type component, string name)
{
if (_container.Kernel.HasComponent(name))
_container.Kernel.RemoveComponent(name);
_container.Register(Component.For<T>().ImplementedBy(component).Named(name).LifeStyle.Singleton);
}
It seems Kernel.RemoveComponent() function has been depreciated. What has replaced this?
The second compiler error is at _container.Register(Component.For<T>().ImplementedBy(component).Named(name).LifeStyle.Singleton);
I am getting "The Type 'TService' must be a reference type in order to use it as a parameter.
I think you might be upgrading from an older version than 3.2.0. See below.
The removal of IKernel.RemoveComponent() is documented in the Breaking Changes document with v3.0.0. Here is the extract where Krzysztof explains why it was removed:
change - Removed the following methods:
GraphNode.RemoveDepender,
GraphNode.RemoveDependent,
IKernel.RemoveComponent,
IKernelEvents.ComponentUnregistered,
INamingSubSystem.this[Type service],
INamingSubSystem.GetHandler,
INamingSubSystem.GetService2Handler,
INamingSubSystem.GetKey2Handler,
INamingSubSystem.UnRegister(String key),
INamingSubSystem.UnRegister(Type service)
Also INamingSubSystem.Register now takes only IHandler as its argument
impact - low
fixability - none
description - The methods were implementation of "remove component from the container" feature
which was flawed and problematic, hecen was scraped.
fix - Working around is quite dependant on your specific usage. Try utilizing IHandlerSelectors.
For changed Register method, just update your calling code not to pass the name.
handler.ComponentModel.Name is now used as the key, as it was happening in all places so far
anyway, so this change should have no real impact.
RegisterComponent() won't overwrite an existing service registration, it'll just register another component for the same service, unless you specify the same name where it'll throw an exception informing you there is another component registered with that name. If your application doesn't replace components very often you could use the IsDefault() method on the registration to get Windsor to resolve the new component by default, just note the other component is still registered.
If your application replaces components often and you don't want the other registrations left there, you'd be best using a custom IHandlerSelector or ISubDependencyResolver so Windsor will ask you each time what component you want used for a specific service.
Also in v3.0.0 a change was made to ensure that value types cannot be passed to the registration methods. You'll need to add a generic constraint to your method that accepts a generic parameter so that it also only accepts reference types:
public void RegisterTypeSingleton<T>(Type component, string name)
where T : class
{
...
}
I made an extended user schema in my Plone 4.3 site with the collective.example.userdata.
My problem is when I try to display my new fields in author.cpt page.
I used to get my user object with the getMemberById from membershiptool and then use getProperty on the userobject but it requires a "manager" permission.
Maybe a solution would be to extend the getMemberInfo with my new fields but I don't know how to do such a thing.
Anyone ?
Thanks
I had the same problem and ended up monkey patching Products.PlonePAS.tools.membership.MembershipTool.getMemberInfo so it supply more data to the caller. The method getMemberInfo can be called with/from the Anonymous role.
I'm working on a Symfony 2.3 Project that utilizes the Doctrine 2 ORM. As is to be expected functionality is split and grouped into mostly independent bundles to allow for code-reuse in other projects.
I have a UserBundle and a ContactInfoBundle. The contact info is split off because other entities could have contact information associated, however it is not inconcievable that a system may be built where users do not require said contact information. As such I'd very much prefer these two do not share any hard links.
However, creating the association mapping from the User entity to the ContactInfo entity creates a hard dependency on the ContactInfoBundle, as soon as the bundle is disabled Doctrine throws errors that ContactInfo is not within any of its registered namespaces.
My investigations have uncovered several strategies that are supposed to counter this, but none of them seem fully functional:
Doctrine 2's ResolveTargetEntityListener
This works, as long as the interface is actually replaced at runtime. Because the bundle dependency is supposed to be optional, it could very well be that there is NO concrete implementation available (i.e. contactInfoBundle is not loaded)
If there is no target entity, the entire configuration collapses onto itself because the placeholder object is not an entity (and is not within the /Entity namespace), one could theoretically link them to a Mock entity that doesn't really do anything. But this entity then gets its own table (and it gets queried), opening up a whole new can of worms.
Inverse the relation
For the ContactInfo it makes the most sense for User to be the owning side, making ContactInfo the owning side successfully sidesteps the optional part of the dependency as long as only two bundles are involved. However, as soon as a third (also optional) bundle desires an (optional) link with ContactInfo, making ContactInfo the owning side creates a hard dependency from ContactInfo on the third bundle.
Making User the owning side being logical is a specific situation. The issue however is universal where entity A contains B, and C contains B.
Use single-table inheritance
As long as the optional bundles are the only one that interacts with the newly added association, giving each bundle their own User entity that extends UserBundle\Entities\User could work. However having multiple bundles that extend a single entity rapidly causes this to become a bit of a mess. You can never be completely sure what functions are available where, and having controllers somehow respond to bundles being on and/or off (as is supported by Symfony 2's DependencyInjection mechanics) becomes largely impossible.
Any ideas or insights in how to circumvent this problem are welcome. After a couple of days of running into brick walls I'm fresh out of ideas. One would expect Symfony to have some method of doing this, but the documentation only comes up with the ResolveTargetEntityListener, which is sub-optimal.
I have finally managed to rig up a solution to this problem which would be suited for my project. As an introduction, I should say that the bundles in my architecture are laid out "star-like". By that I mean that I have one core or base bundle which serves as the base dependency module and is present in all the projects. All other bundles can rely on it and only it. There are no direct dependencies between my other bundles. I'm quite certain that this proposed solution would work in this case because of the simplicity in the architecture. I should also say that I fear there could be debugging issues involved with this method, but it could be made so that it is easily switched on or off, depending on a configuration setting, for instance.
The basic idea is to rig up my own ResolveTargetEntityListener, which would skip relating the entities if the related entity is missing. This would allow the process of execution to continue if there is a class bound to the interface missing. There's probably no need to emphasize the implication of the typo in the configuration - the class won't be found and this can produce a hard-to-debug error. That's why I'd advise to turn it off during the development phase and then turn it back on in the production. This way, all the possible errors will be pointed out by the Doctrine.
Implementation
The implementation consists of reusing the ResolveTargetEntityListener's code and putting some additional code inside the remapAssociation method. This is my final implementation:
<?php
namespace Name\MyBundle\Core;
use Doctrine\ORM\Event\LoadClassMetadataEventArgs;
use Doctrine\ORM\Mapping\ClassMetadata;
class ResolveTargetEntityListener
{
/**
* #var array
*/
private $resolveTargetEntities = array();
/**
* Add a target-entity class name to resolve to a new class name.
*
* #param string $originalEntity
* #param string $newEntity
* #param array $mapping
* #return void
*/
public function addResolveTargetEntity($originalEntity, $newEntity, array $mapping)
{
$mapping['targetEntity'] = ltrim($newEntity, "\\");
$this->resolveTargetEntities[ltrim($originalEntity, "\\")] = $mapping;
}
/**
* Process event and resolve new target entity names.
*
* #param LoadClassMetadataEventArgs $args
* #return void
*/
public function loadClassMetadata(LoadClassMetadataEventArgs $args)
{
$cm = $args->getClassMetadata();
foreach ($cm->associationMappings as $mapping) {
if (isset($this->resolveTargetEntities[$mapping['targetEntity']])) {
$this->remapAssociation($cm, $mapping);
}
}
}
private function remapAssociation($classMetadata, $mapping)
{
$newMapping = $this->resolveTargetEntities[$mapping['targetEntity']];
$newMapping = array_replace_recursive($mapping, $newMapping);
$newMapping['fieldName'] = $mapping['fieldName'];
unset($classMetadata->associationMappings[$mapping['fieldName']]);
// Silently skip mapping the association if the related entity is missing
if (class_exists($newMapping['targetEntity']) === false)
{
return;
}
switch ($mapping['type'])
{
case ClassMetadata::MANY_TO_MANY:
$classMetadata->mapManyToMany($newMapping);
break;
case ClassMetadata::MANY_TO_ONE:
$classMetadata->mapManyToOne($newMapping);
break;
case ClassMetadata::ONE_TO_MANY:
$classMetadata->mapOneToMany($newMapping);
break;
case ClassMetadata::ONE_TO_ONE:
$classMetadata->mapOneToOne($newMapping);
break;
}
}
}
Note the silent return before the switch statement which is used to map the entity relations. If the related entity's class does not exist, the method just returns, rather than executing faulty mapping and producing the error. This also has the implication of a field missing (if it's not a many-to-many relation). The foreign key in that case will just be missing inside the database, but as it exists in the entity class, all the code is still valid (you won't get a missing method error if accidentally calling the foreign key's getter or setter).
Putting it to use
To be able to use this code, you just have to change one parameter. You should put this updated parameter to a services file which will always be loaded or some other similar place. The goal is to have it at a place that will always be used, no matter what bundles you are going to use. I've put it in my base bundle services file:
doctrine.orm.listeners.resolve_target_entity.class: Name\MyBundle\Core\ResolveTargetEntityListener
This will redirect the original ResolveTargetEntityListener to your version. You should also clear and warm your cache after putting it in place, just in case.
Testing
I have done only a couple of simple tests which have proven that this approach might work as expected. I intend to use this method frequently in the next couple of weeks and will be following up on it if the need arises. I also hope to get some useful feedback from other people who decide to give it a go.
You could create loose dependencies between ContactInfo and any other entities by having an extra field in ContactInfo to differentiate entities (e.g. $entityName). Another required field would be $objectId to point to objects of specific entities. So in order to link User with ContactInfo, you don't need any actual relational mappings.
If you want to create a ContactInfo for a $user object, you need to manually instantiate it and simply setEntityName(get_class($user)), setObjectId($user->getId()). To retrieve user ContactInfo, or that of any object, you can create a generic function that accepts $object. It could simply just return ...findBy(array('entityName' => get_class($user), 'objectId' => $object->getId());
With this approach, you could still create User form with ContactInfo (embed ContactInfo into User). Though after you process the form, you will need to persist User first and flush, and then persist ContactInfo. Of course this is only necessary for newly created User objects, just so to get user id. Put all persist/flush in a transaction if you're concerned about data integrity.
I'm using Symfony2 with Doctrine2. I want to achieve the following:
$place = $this->getDoctrine()->getRepository('TETestBundle:Place')->find($id);
And on that place will be the info of the place (common data + texts) on the user language (in session). As I am going to do that hundreds of times, I want to pass it behind the scenes, not as a second parameter. So an English user will view the place info in English and a Spanish user in Spanish.
One possibility is to access the locale of the app from an EntityRepository. I know it's done with services and DI but I can't figure it out!
// PlaceRepository
class PlaceRepository extends EntityRepository
{
public function find($id)
{
// get locale somehow
$locale = $this->get('session')->getLocale();
// do a query with the locale in session
return $this->_em->createQuery(...);
}
}
How would you do it? Could you explain with a bit of detail the steps and new classes I have to create & extend? I plan on releasing this Translation Bundle once it's ready :)
Thanks!
I don't believe that Doctrine is a good approach for accessing session data. There's just too much overhead in the ORM to just pull session data.
Check out the Symfony 2 Cookbook for configuration of PDO-backed sessions.
Rather than setting up a service, I'd consider an approach that used a Doctrine event listener. Just before each lookup, the listener would pick out the correct locale from somewhere (session, config, or any other place you like in the future), inject it into the query, and like magic, your model doesn't have to know those details. Keeps your model's scope clean.
You don't want your model or Repository crossing over into the sessions directly. What if you decide in the future that you want a command-line tool with that Repository? With all that session cruft in there, you'll have a mess.
Doctrine event listeners are magically delicious. They take some experimentation, but they wind up being a very configurable, out-of-the-way solution to this kind of query manipulation.
UPDATE: It looks like what you'd benefit from most is the Doctrine Translatable Extension. It has done all the work for you in terms of registering listeners, providing hooks for how to pass in the appropriate locale (from wherever you're keeping it), and so on. I've used the Gedmo extensions myself (though not this particular one), and have found them all to be of high quality.