Hello la commu,
J'ai un problème avec le user Symfony et le firewall.
En gros j'ai une app SF6 qui me gère l'API, et un front React,
J'ai 2 firewalls avec une connextion JSON (locataire et propriétaire),
Et mes firewall on le pattern ^/api/(locataire ou propriétaire)
. Donc ma session est côté serveur et api.
Le reste de mes pages d'affichage, sont prise en charge par mon routeur React.
Ce que je veux accomplir c'est au chargement d'une page, je souhaite faire quelques redirections en fonctions de l'état de ma session (rediriger sur le login si le user n'est pas connecté, si il est connecté et qu'il va sur la page de login, rediriger vers le dashboard etc...)
Le soucis, c'est que mes user sont authentifiés dans le firewall avec le pattern ^/api/(locataire ou propriétaire)
, et moi je veux les récupérer sur une URL qui ne match pas ce pattern.
Tout ce que je récupère avec $security->getUser()
etc... est toujours null
car je ne suis pas dans le contexte du firewall en question.
Ma quesstion est donc, est-il possible de séléctionner manullement le firewall dans lequel on veut piocher la session ?
Mon security.yml
security:
enable_authenticator_manager: true
# https://symfony.com/doc/current/security.html#registering-the-user-hashing-passwords
password_hashers:
Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface: 'auto'
# https://symfony.com/doc/current/security.html#loading-the-user-the-user-provider
providers:
# used to reload user from session & other features (e.g. switch_user)
app_user_provider:
entity:
class: App\Entity\Admin
property: email
user_provider:
entity:
class: App\Entity\User
property: email
firewalls:
dev:
pattern: ^/(_(profiler|wdt)|css|images|js)/
security: false
tenant_login:
pattern: ^/api/tenant/
provider: user_provider
custom_authenticators:
- App\Security\TenantAuthenticator
json_login:
check_path: api_tenant_login
username_path: email
password_path: password
logout:
path: api_tenant_logout
invalidate_session: true
landlord_login:
pattern: ^/api/landlord/
provider: user_provider
custom_authenticators:
- App\Security\LandlordAuthenticator
json_login:
check_path: api_landlord_login
username_path: email
password_path: password
logout:
path: api_landlord_logout
invalidate_session: true
main:
lazy: true
provider: app_user_provider
form_login:
login_path: app_admin_login
check_path: app_admin_login
logout:
path: app_admin_logout
target: /login
# activate different ways to authenticate
# https://symfony.com/doc/current/security.html#the-firewall
# https://symfony.com/doc/current/security/impersonating_user.html
# switch_user: true
# Easy way to control access for large sections of your site
# Note: Only the *first* access control that matches will be used
access_control:
- { path: ^/admin, roles: ROLE_ADMIN }
- { path: ^/api/tenant/app, roles: ROLE_TENANT }
- { path: ^/api/landlord/app, roles: ROLE_LANDLORD }
when@test:
security:
password_hashers:
# By default, password hashers are resource intensive and take time. This is
# important to generate secure password hashes. In tests however, secure hashes
# are not important, waste resources and increase test times. The following
# reduces the work factor to the lowest possible values.
Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface:
algorithm: auto
cost: 4 # Lowest possible value for bcrypt
time_cost: 3 # Lowest possible value for argon
memory_cost: 10 # Lowest possible value for argon
La seule solution que j'ai trouvé c'est de récupérer toute la session et voir ce que j'ai dedans avec $request->getSession()->all()
La réponse est oui. L'ordre est de haut en bas. Que ce soit pour les "firewall" et " access_control"
des fois j'utilise :
Symfony\Component\Security\Core\Authentication\Token\Storage\TokenStorageInterface
et $this->tokenStorage->getToken()->getUser();
vérifie également que tu es sur la bonne request, des fois il est lancé sur le debug et dans ce cas tu n'as pas d'utilisateur authentifié (je me fais avoir quelques fois avec ca)