I am learning Symfony 4 and i want to change role of somes users to ROLE_ADMIN.
How can do this with a database ?
I tried to change it manually in database but it doesn't work...
(a:1:{i:0;s:9:"ROLE_USER";} -> a:1:{i:0;s:10:"ROLE_ADMIN";})
Thank you ;)
To promote users you can use command lines tools for FosUser:
php bin/console fos:user:promote testuser --super
php bin/console fos:user:promote testuser ROLE_ADMIN
check the doc here: https://symfony.com/doc/current/bundles/FOSUserBundle/command_line_tools.html
Related
I use Symfony 4 (more precise 4.1) with SonataAdminBundle and SonataMediaBundle.
This is my config/routes/sonata_media.yaml:
sonata_media_gallery:
resource: '#SonataMediaBundle/Resources/config/routing/gallery.xml'
prefix: /media/gallery
sonata_media:
resource: '#SonataMediaBundle/Resources/config/routing/media.xml'
prefix: /media
If I run php bin/console debug:router there are the following routes in the output:
sonata_media_gallery_index ANY ANY ANY /media/gallery/
sonata_media_gallery_view ANY ANY ANY /media/gallery/view/{id}
sonata_media_view ANY ANY ANY /media/view/{id}/{format}
sonata_media_download ANY ANY ANY /media/download/{id}/{format}
The first two routes work fine, but when I try the other two routes, for example:
http://localhost:8000/media/view/
http://localhost:8000/media/view/1/default
http://localhost:8000/media/download/1
http://localhost:8000/media/download/1/default
then I always get AccessDeniedException, even though I'm authenticated as ROLE_SUPER_ADMIN.
The error happens in vendor/sonata-project/media-bundle/src/Controller/MediaController.php in downloadAction and in viewAction. I was digging around in the source code, but can't find the reason for the exception thrown.
After some research I found the culprit and solved the problem. Here I'd like to share my knowledge.
As I mentioned in the question, the exceptions were thrown from:
vendor/sonata-project/media-bundle/src/Controller/MediaController.php
in the methods downloadAction and viewAction. It was the following if-condition:
if (!$this->get('sonata.media.pool')->getDownloadSecurity($media)->isGranted($media, $this->getCurrentRequest())) {
throw new AccessDeniedException();
}
which is present in both methods. This led me to vendor/sonata-project/media-bundle/src/Provider/Pool.php, and further to vendor/sonata-project/media-bundle/src/Security/RolesDownloadStrategy.php. I couldn't find any bug or problem there, but it opened my eyes to another position in my own configuration:
access_control:
- { path: ^/admin/, role: [ROLE_ADMIN, ROLE_SONATA_ADMIN] }
- { path: ^/.*, role: IS_AUTHENTICATED_ANONYMOUSLY }
How could I be so stupid? The path /media is not declared in security.yml and can be accessed by not authenticated users. The SonataMediaBundle requires per default ROLE_ADMIN or ROLE_SUPER_ADMIN for downloading/viewing the media.
The routes for the Gallery were accessible because vendor/sonata-project/media-bundle/src/Controller/GalleryController.php doesn't check if access is granted.
After finding the culprit the question was which approach to chose to solve the problem
1) Change the route prefix:
sonata_media:
resource: '#SonataMediaBundle/Resources/config/routing/media.xml'
prefix: /admin/media
The declared path in security.yml covers now the media and ROLE_ADMIN and ROLE_SUPER_ADMIN can access the routes.
Disadvantage: what if you want to expose the media outside of the admin? And what if other roles should be able to access them.
2) Declare a new path in security.yml:
access_control:
- { path: ^/media/, role: [ROLE_ADMIN, ROLE_SONATA_ADMIN] }
Now we can expose the media outside of the admin. But the other issue is still there: what if other roles need to access the media?
3) Configure another download strategy in the config for SonataMedia:
sonata_media:
# ...
contexts:
default: # the default context is mandatory
download:
strategy: sonata.media.security.connected_strategy
mode: http
# ...
and adjust the path:
access_control:
# ...
- { path: ^/media/, role: [IS_AUTHENTICATED_FULLY, IS_AUTHENTICATED_REMEMBERED] }
# ...
Now every logged in user can access the media. This solution worked for me.
However it is not a one-size-fits-all recipe. Please check the chapter security from the official documentation to get more detailed information.
I use ACL in Sonata Admin Bundle. Аnd when I log in as a root (which has ROLE_SUPER_ADMIN) I can create new users. I've created one (named qwer) and then loged in as qwer.
PROBLEM: in my situation qwer user has empty dashbord, even having roles like
ROLE_SONATA_USER_ADMIN_USER_GUEST, ROLE_SONATA_USER_ADMIN_USER_STAFF, ROLE_SONATA_USER_ADMIN_USER_EDITOR
Please tell my -- what should I do to understad where the problem is.
Did you follow the documentation for ACL fully? You should add your sonata_admin configuration and security.yml just to be sure. Mine looks like:
sonata_admin:
# ...
security:
handler: sonata.admin.security.handler.acl
# acl security information
information:
LIST: [LIST]
GUEST: [VIEW, LIST]
STAFF: [LIST, CREATE]
EDITOR: [OPERATOR, EXPORT, EDIT]
ADMIN: [MASTER]
admin_permissions: [CREATE, LIST, DELETE, UNDELETE, EXPORT, OPERATOR, MASTER]
# permission related to the objects
object_permissions: [VIEW, EDIT, DELETE, UNDELETE, OPERATOR, MASTER, OWNER]
Also ensure your security.yml has the required configuration:
security:
# ...
providers:
fos_userbundle:
id: fos_user.user_manager
acl:
connection: default
access_decision_manager:
strategy: unanimous
And add a PermissionMap to your app/config/parameters.yml or bundle parameters:
# src/AppBundle/Resources/config/services.yml
parameters:
# ...
# Symfony 3 and above
security.acl.permission.map:
class: Sonata\AdminBundle\Security\Acl\Permission\AdminPermissionMap
# Symfony < 3
security.acl.permission.map.class: Sonata\AdminBundle\Security\Acl\Permission\AdminPermissionMap
Then there are 3 commands you will need to run:
Initialize your ACL setup (only once)
php app/console init:acl
Reload changes to the configuration (every change in the sonata_admin configuration file)
php app/console sonata:admin:setup-acl
To generate (new) ACL rules for already existing entities/objects. (every change in the sonata_admin configuration file)
php app/console sonata:admin:generate-object-acl
Then once the configuration is setup, logout and log back in again for the roles to apply.
to resolve this problem check that your have in of your app bundle lines:
services:
security.acl.permission.map:
class: Sonata\AdminBundle\Security\Acl\Permission\AdminPermissionMap
parameters:
after migrating from php5.6 to php7.0 on (dev and prod), i'm prevented to connect on my admin account although i can create a new one !
i get "Bad credentials"
My security.yml :
security:
encoders:
Symfony\Component\Security\Core\User\User: plaintext
Application\Sonata\UserBundle\Entity\User: sha512
any idea please.
I'm not sure why you have two encoders specified, try to comment the first one as you're loading user from database use
security:
encoders:
Application\Sonata\UserBundle\Entity\User: sha512
I am trying to configure SonataAdmin to display certain entity management for different roles. Read sonata docs, lots of QnA on stackoverflow, cannot find the problem...
Problem:
If I login as ROLE_ADMIN user, I can see all blocks, so sonata admin is working fine. But if I log in with other user, I just see empty page with no blocks. I would say I only need to add role ROLE_SONATA_CONTRACT to my user but as it did not work I tried every role I could think of including all roles auto-generated in user admin form.
I can give more information from configs, now I just copied parts I think are relevant.
My config:
Reference: http://sonata-project.org/bundles/admin/master/doc/reference/security.html#role-handler
# services.yml
services:
sonata.block.admin.contract:
class: STH\OrderBundle\Admin\ContractAdmin
tags:
- { name: sonata.admin, manager_type: orm, group: "Orders", label: "Orders" }
arguments: [null, STH\OrderBundle\Entity\Contract, SonataAdminBundle:CRUD ]
# security.yml
role_hierarchy:
ROLE_SONATA_CONTRACT:
- ROLE_SONATA_BLOCK_ADMIN_CONTRACT_VIEW
- ROLE_SONATA_BLOCK_ADMIN_CONTRACT_GUEST
ROLE_ADMIN: [ROLE_USER, ROLE_ALLOWED_TO_SWITCH, ROLE_SONATA_PAGE_ADMIN_PAGE_EDIT, ROLE_SONATA_PAGE_ADMIN_BLOCK_EDIT]
ROLE_SUPER_ADMIN: ROLE_ADMIN
SONATA:
- ROLE_SONATA_PAGE_ADMIN_PAGE_EDIT # if you are using acl then this line must be commented
- ROLE_SONATA_PAGE_ADMIN_BLOCK_EDIT
access_decision_manager:
strategy: unanimous
# config.yml
security:
handler: sonata.admin.security.handler.role
# acl security information
information:
GUEST: [VIEW, LIST]
STAFF: [EDIT, LIST, CREATE]
EDITOR: [OPERATOR, EXPORT]
ADMIN: [MASTER, ROLE_ADMIN]
# permissions not related to an object instance and also to be available when objects do not exist
# the DELETE admin permission means the user is allowed to batch delete objects
admin_permissions: [CREATE, LIST, DELETE, UNDELETE, EXPORT, OPERATOR, MASTER]
# permission related to the objects
object_permissions: [VIEW, EDIT, DELETE, UNDELETE, OPERATOR, MASTER, OWNER]
System: Symfony 2.5.2, SonataAdminBundle, SonataUserBundle, FOSUserBundle.
I think you are not correctly defining your role hierearchies. Did you tried something like:
role_hierarchy:
ROLE_USER: [ROLE_SONATA_BLOCK_ADMIN_CONTRACT_VIEW,ROLE_SONATA_BLOCK_ADMIN_CONTRACT_GUEST ]
ROLE_ADMIN: ROLE_USER
ROLE_SUPER_ADMIN: ROLE_ADMIN
Just to trigger some insights about the way you define your hierarchies. hope it helps.
I developed a little management application with Symfony. It works a lot on local. I put it all on my webserver (called Planethoster), and I've got the following message when I try to login in my application using app.php:
SQLSTATE[HY000] [1045] Access denied for user 'root'#'localhost' (using password: NO)
But in my parameters.yml file, I have not put the root user, it's another standard user that can only SIUD. I believe that app.php does not load my parameters.yml or config.yml file.
The last but not the least, I can log in using app_dev.php. It works but not with app.php.
Verify your Database settings in app/config_prod.yml for production use.
clear your cache by php app/console cache:clear --env=prod