Symfony2 Doctrine Users

Question

I am looking for the best methods for getting user-generated content. I have a $ user object form 'security.context' and I need to get a separate record created by this user using $ record_id,

what should I do?

$this->getDoctrine()->getRepository('AcmeRecordBundle:Record') ->findOneBy(array( 'id' => $record_id, 'user' => $user->getId() )); 

This does not look good to me, because I have a lot of information to look for, we are looking for a user (so that other users do not try to get it using some id). And for any content (personal photo, some other closed content) do I need to pass "user" => $ user-> getId ()?

Or is it better to create a UserRepository with all these features? getRecordById ($ id), getPhotoById ($ id), getPrivateInformationById ($ id), etc.

I worked with Rails a bit, and there I was able to define the current_user method

 def current_user return @current_user if defined?(@current_user) # .... end 

and then just use it like

 current_account.records.find(params[:id]) 

Is there any way to get this to work with Doctrine2 and Symfony2? how

 $user->getRecords()->find($recordId) 

Answer 1

In any situation, you need to specify the user that you pass to your functions, which are related to the selection logic inside the custom repository, as indicated in the official documentation for the Doctrine.

Answer 2

Of course, you should pass the user id for the sql clause "WHERE" just because ROR did it magically behind the scenes (which is very bad imo practice) does not mean that he did not do it at all.

As for the other question, both solutions are fine:

• Extract data from a specific repository and pass the identifier of the object + user ID or:
• Create methods that internally get the user ID and put them in the requests

And remember that the user ID is selected only once during the request, so do not worry about getting it too much from the security context.

Answer 3

You need to implement the Symfony 2 ACL functions. This allows you to specify ownership of the "domain objects" (individual instances of database classes) and which access users have on the domain object. Then you can use, for example, JMSSecurityExtraBundle and implement access control based on object ownership. After implementation, your users will not be able to change each other (by manipulating the parameters), and you will not need an additional parameter in your requests.

Here are some relevant links:

• Access Control Lists (ACLs)
• JMSSecurityExtraBundle

Answer 4

Personally, I found that the repository classes are a little inflating things in a small and medium sized application. Not sure what your approach is, but most of everything I read (and what I posted in a recent Doctrine 2 application) should have had a "service" level that managed entities. This is b / c in D2, the implementation of save / delete, etc. In essence, it undermines the purpose of the system, which is to facilitate the knowledge of persistence from entities and treat them as objects Plain Old Php (TM);)

The thing that seems strange to me is to pass in the primary key identifier and user id to retrieve the user. It seems to me that the pk of the User table will be the user ID, or at least if the user ID is not pk (not sure why this would be), you should be able to get entries using only pk. Here is a method to retrieve a User object on my system

 /** * @param int $iId user id * * @return object */ public function fetch($iId) { return $this->_oEm->find('AwesomeApp\Entity\User', $iId); } 

The current user function you are looking for must be associated with a session in your application. In zf, I created a session handler that stores the user doctrine object in the session store, and then when the session is read, I reattach the User object to the entity manager. You probably want to do something like this in sf, then calling getCurrentUser will return the same User object as pulling it out of the database. Saving the User object in the session prevents you from having to return to the database for it each time the page loads, for example, if you just saved the user ID in the session.

At the end of the day, you were "supposed" to put complex selection queries in the repository, but this obviously remains at the discretion of the user when it comes to best practices. In this case, when you only have pk, I would say that it makes no sense to write a repository class.