CODEWITHSUNDEEP
symfony1
Stick it to THE MAN
Stick it to THE MAN

Reputation: 5701

Symfony Admin Generator in multi user setup (restricting records in LIST view)

I am using SF 1.2.9 to build a website. I want to use the admin generator to provide admin functionality for the object models I have used (specifically LIST, edit and delete).

I have read the Symfony docs (Chapter 14), but unless, I am very much mistaken, all examples I have come accross so far, seems to be written for a single user environment only. Meaning that the list of records returned to the user is essentially, ALL the records in that table. In a multiuser environment, this is irresposible at best, and potentially, a security threat. It is a necessary requirement to restrict the list of records returned to a user to only those that they own (i.e. created).

Suppose I have a table with (YML) schema like this:

foobar_dongle:
    id:          ~
    title:       varchar(255)
    info:        longvarchar
    owner_id:   ~
    created_at:  ~

where owner id is a FK into a user table.

Assume I generate an admin module like this:

symfony propel:generate-admin backend FoobarDongle --module=dongle

Question: How do I modify the list of records returned to a user in the LIST part of the code generated by the admin generator? As I mentioned above, currently, (i.e. out of the box), the admin generator presents the user (rather naively, I feel), with the ENTIRE set of records for the model being administered. I need to be able to restrict that list somehow, so that I can only return records owned by that user.

This is what I am trying to find out how to do.

I would be most grateful to anyone who can show me how I can restrict the list of records returned when using the admin generator for administration of an object model. Ideally, I would like to be able to specify a custom method that has all the custom 'filtering' logic - but so long as I can restrict the LIST of records a user can see (in admin), to only the records that he is the owner of, that is all I want to be able to do.

Upvotes: 4

Views: 3639

Answers (2)

Felix Kling
Felix Kling

Reputation: 816472

If you only want to restrict the returned objects in one or two modules, do this:

Go to the actions.class.php file of your module. There should be no methods by default and the class should inherit from autoModuleNameActions you. Insert the following method: 

protected function buildQuery()
{
   $query = parent::buildQuery();
   // do what ever you like with the query like
   $query->andWhere('user_id = ?', $this->getUser()->getId());
   return $query;
}

But this becomes unhandy if you do it for more modules. In this case I would advice to create a new admin generator theme.

And if you want to make the query depending on some custom parameter in the admin generator config file, then you have to extend this file. But is not just done with adding a new parameter. You can read this article how to do this.

If you want to know more about the auto generated classes, have a look at this class: cache/[app]/[env]/modules/auto[ModuleName]/actions/actions.class.php.

Edit after comments:

I think you looked at the wrong class. Look here: cache/[app]/[env]/modules/auto[ModuleName]/actions/actions.class.php.

I set up a Propel project to check it and the method that is interesting for you is:

protected function buildCriteria()
{
  if (is_null($this->filters))
  {
    $this->filters = $this->configuration->getFilterForm($this->getFilters());
  }

  $criteria = $this->filters->buildCriteria($this->getFilters());

  $this->addSortCriteria($criteria);

  $event = $this->dispatcher->filter(new sfEvent($this, 'admin.build_criteria'), $criteria);
  $criteria = $event->getReturnValue();

  return $criteria;
}

I also posted the whole content of this class to pastebin. It is a lot, the function is in line 245. Even if you don't find this class, you should be able to override this method like this:

protected function buildCriteria()
{
  $criteria = parent::buildCriteria();
  // do something with it
  return $criteria;
}

I don't know about these criteria objects, so I can't help you with that but I hope the other things help you.

Upvotes: 5

benlumley
benlumley

Reputation: 11382

You should use sfGuardPlugin to provide your login/user functionality - it includes user groups and permissions that can be assigned to users and/or groups.

Using security.yml you can then configure which permissions/credentials are required to access individual actions. IE: you can allow everyone to access the list/update/delete actions, but only people with the create permission to access the create page.

The docs for sfGuardPlugin are worth reading:

http://www.symfony-project.org/plugins/sfGuardPlugin

Plus this section from the jobeet tutorial covers sfGuard and also use of security.yml and credentials:

http://www.symfony-project.org/jobeet/1_2/Propel/en/13

And to round off, this page from the book is relevant too:

http://www.symfony-project.org/reference/1_2/en/08-Security (although not sure it covers anything that isn't in the page i linked from jobeet)

Upvotes: 1

Related Questions