I follow this manual to configure my multiple entity manager: https://symfony.com/doc/current/doctrine/multiple_entity_managers.html
When I try to persist with my "customer" entity manager, it works.
The authenticate layer works fine, I can login/signup, I use "customer" entity manager (I follow this manual, to get user by uuid or email https://symfony.com/doc/current/security/user_providers.html#security-entity-user-provider)
When I try to persist with my "default" entity manager, I get this error:
Class 'App\\Entity\\Cas\\Client' was not found in namespaces configured in string App\\Entity\\Main.
I think it's because when I authenticate the user on my API, the entity that's used to do that is Client, and it's handled only by my client entity manager.
I don't know how to handle this problem, because if I cast $security->getUser() to type User, I can't persist with client entity manager.
Anyone have an idea to solve this problem?
Related
I have a Symfony2 application which has the following process when a user logs in:
User enters their login details
The details are authenticated with a 3rd party API
If the login details are correct we sync a load of information from the API and into the database that the application needs
All the information is attached to the user object via relationships set up in Doctrine
The problem is when the PDO session handler puts this information into the session it seems to be storing the user object plus all the relationships resulting in a huge amount of data being stored most of which isn't needed as Doctrine can lazy load them back in anyway.
This is also causing problems as the amount of data is sometimes so big that it doen't fit in the session_value field even though it's a LONGTEXT which results in the session being corrupted.
So, is there a way I can safely remove the relationship data from doctrine entities before they get put into the session? I've tried using __sleep and __wake but they don't get invoked.
Implement the Serializable interface and serialize only what you need.
I've got a custom user provider entity which permits me to connect the users. This custom user provider entity implements UserInterface in accordance to this interface I've got a "getRoles()" function which give me the user's roles.
But my roles are recursive.
Example: a user got a role1, the role1 inherited the role2 so the user has gotten the role1 and the role2. To make this recursivity I create a role table, a role_role table (parent/child), a user table and finally a user_role table.
To get ALL the user's roles I have to query my DB with Doctrine so from where can I do that ?
It seems to be forbidden to query from an entity and I can't put the query in entity repository classe because I can't overwrite the entity's "getRoles()" and it seems not to be a good idea to access the repository form entities.
P.-S.: thank you for your indulgence with my grammar, it's my first English message (I'm French).
There is no role hierarchy in DB in Symfony 2.x. It's configure in security.yml check out http://symfony.com/doc/current/book/security.html#hierarchical-roles .
If you don't want to use this feature straight from Symfony 2, you'll have to implement yourself a RoleVoter that get the roles hierarchy direct from the DB.
Another possibility is to use Doctrine Events Listeners ( http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/events.html ) to load the hierarchy from the DB. You'll probably need to listen to the postLoad event.
The solution is to use fully the Doctrine's ORM.
Add a collection variable in the User entity which reference all the UserRole linked to him with an ORM:
#ORM\OneToMany(targetEntity="RoleUser", mappedBy="user")
...
protected $roleUser;
In RoleUser entity add an ORM which permit to bind the User with the right RoleUser:
#ORM\ManyToOne(targetEntity="User", inversedBy="roleUser")
...
protected $user;
Now you can get all the UserRoles linked to the User.
To get the roles write the "sames" ORM between UserRole entity and Role and between RoleRole and Role. Finally you access to your roles from User by $rolesUtilisateur.
I just implemented my own authentication provider performing facebook authentication. It works for exactly one request and then it goes:
There is no user provider for user "Nourdine\BasicBundle\Security\User\FacebookUser"
The thing is:
1 - a FacebookProvider is there and kicking.
2 - I registered it as a service:
<service id="facebook_user_provider" class="Nourdine\BasicBundle\Security\User\FacebookUserProvider" />
3 - and made it available in security.xml
First question: Why does he now "see" it?
Second question: is it mandatory that one creates a related user provider every time he implements an authentication provider?
Thanks
I think you have something wrong with your user provider refreshUser method. This method is used when you use session persistence (token is serialized and stored in session) so user can be fetched from database (or other place) next requests.
It see provider cause you register it as service and use service id in security.yml
UserProvider is responsible for fetch user from db or other layer (webservice or something) and AuthenticationProvider authenticate user (do authentication logic) and it can use provider but it is not necessary most the time we use Symfony\Component\Security\Core\User\UserProviderInterface not concrete implementation. So not mandatory
I have a login form in Symfony2.1, which is posted to my route, which has no controller attached, as Symfony takes care of the login internally.
Now how would I add a field to this form, call a SetXxxx() method on an entity, and persist it? I have no way of intercepting the POST value of my login form.
You can do this by implementing a custom Authentication Provider and creating your own authentication Token which persists one of it's members.
You can save yourself a lot of trouble creating an AuthenticationSuccessHandler ( see http://blog.alterphp.com/2011/10/set-up-authenticationsuccesshandler.html ), and injecting the entity manager or whatever service you have that takes care of updating your entity and persist it.
That blog implements directly the interface AuthenticationSuccessHandlerInterface, but you can do it as well extending Symfony\Component\Security\Http\Authentication\DefaultAuthenticationSuccessHandler and making your additions in onAuthenticationSuccess
I'm trying to design an entity model for an application that uses ASP.Net membership for it's user authentication. In most of the database schemas I create, records typically end up related to users via the UserId field on the aspnet_users table. That's worked fine for me in the past, but now that I'm using EF, I'm having some conceptual issues with figuring out how I'm going to reference the user from an entity.
For example, let's say we have a "post" entity that contains a "postedBy" property. I'd LIKE to be able to do get the username of the user that created this post with something like post.user.username, but I'm wary of creating an entity based on the aspnet_user table for fear of creating a model that let's me bypass the Membership class when making changes to the database.
I've considered just leaving the post.userId field as a guid and then requiring that any code that needs to know the username use that guid to get the user from the Membership class, but that seems "ineligant".
Does anyone have any recommendations for entity model designs that integrate with Membership? I'd be reasonably happen with a "read-only" user entity.
My advice is: "Don't."
Let me be more specific.
Using UserId as a mapped, foreign key ties your entity model not to ASP.NET Membership in general, but to the SQL Membership Provider in general. What happens if you then want to use domain authentication or OpenID?
Don't get me wrong: 99.9% of the time it's correct to tie DB references together with a foreign key. Heck, you could even do it here, but don't map it into your entity model. You need to keep a wall of logical separation between membership providers and your own data. You access your data through the EF. You access membership data through the membership API. The fact that they happen to live in the same DB because you happen to be using the SQL membership provider is an implementation detail.
Update: I've expanded upon this idea in a blog post.