Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [Symfony] Kwestia zabezpieczenia dostępu do akcji
Forum PHP.pl > Forum > PHP > Frameworki
zimi
tak się zastanawiam czy i jeśli tak to w jaki sposób robicie w Symfony możliwość edycji z poziomu panelu administracyjnego serwisu www ustalania praw dostępu danych grup do określonych akcji

przychodzą mi do głowy 2 opcję:
1. generowanie pliku security.yml
2. wrzucenie do pliku security.yml kodów PHP opierających się na danych zgromadzonych gdzieś indziej

jedno gorsze od drugiego szczególnie że trzebaby wyczyścić cache symfony po każdej edycji tych ustawień

drugie rozwiązanie nie jest zbyt eleganckie, pierwsze natomiast, cóż generowanie plików konfiguracyjnych, że tak to ujmę "nie widzi mi się"

w jaki sposób rozwiązujecie tą kwestię?
AxZx
dane mozesz trzymac w bazie
tabela z kolumniami: controller, action, access, iduser, idgroup
do tego odpowiednie zapytanie.

a juz w samym symfony to mozesz zrobic klase class customActions extends sfActions i w jej konstruktorze sprawdzac prawa dostepu i wykonywac odpowiednia akcje.
jeszcze tak nie probowalem bo nie mialem potrzeby. mam tak zrobione w kohanie i fajnie dziala.
jarek_bolo
Cytat(AxZx @ 6.08.2008, 10:58:49 ) *
a juz w samym symfony to mozesz zrobic klase class customActions extends sfActions i w jej konstruktorze sprawdzac prawa dostepu i wykonywac odpowiednia akcje.
jeszcze tak nie probowalem bo nie mialem potrzeby. mam tak zrobione w kohanie i fajnie dziala.



Znaczy, że jak masz?
Normalnie klasa actions.class.php rozszerza klasę sfActions, a Ty między te klasy wpisałeś swoją klasę customActions, która dziedziczy po sfActions i doimplementowywuje tylko sprawdzanie uprawnień każdego requesta? Robi to w konstruktorze, a więc na poczotku zanim w ogóle jakiekolwiek akcje zostaną wywołane.
Następnie każdą actions.class.php w każdym module aplikacji dziedziczysz po customActions??

I mówisz, że tak samo zrobiłeś w Kohanie??

Ja tak opisałem, bo chcę się upewnić czy dobrze rozumiem oraz zapytać czy takie podejście do implementacji złożonej autoryzacji z podziałem na grupy i role jest ok.
Cysiaczek
Można też zbudować uprawnienia dla usera w filtrze. Ja tak dopisuję credentiale z bazy do już istniejących.
Prosty generator crendentiali dla każdego modułu i każdej akcji (np. operacje CRUD), który wypełnia bazę. Następnie, w filtrze wyciągam uprawnienia z owej tabeli i dodaję do tablicy uprawnień akcji, potem request leci dalej.

Przykład. (wymaga pewnie poprawek)

Budujemy uprawenienia (zawiera nawet tworzenie grup uprawnień)
actions.class.php
  1. <?php
  2. public function executeRebuildPermissionList()
  3. {
  4. $dir = sfConfig::get("sf_app_dir")."/modules";
  5. $modules=sfDirectoryActions::listDirs($dir);
  6. foreach($modules as $moduleName=>$actions)
  7. {
  8.  
  9. $g=new sfGuardGroup();
  10. $g->setName($moduleName.'_admin');
  11. $g->save();
  12.  
  13. $p=new sfGuardPermission();
  14. $p->setName($moduleName);
  15. $p->setModuleName($moduleName);
  16. $p->save();
  17.  
  18. $gp=new sfGuardGroupPermission();
  19. $gp->setsfGuardPermission($p);
  20. $g->addsfGuardGroupPermission($gp);
  21. $g->save();
  22.  
  23.  
  24. foreach($actions as $action)
  25. {
  26. $p=new sfGuardPermission();
  27. $p->setName($moduleName.'_'.$action);
  28. $p->setModuleName($moduleName);
  29. $p->setActionName($action);
  30. $p->save();
  31. }
  32.  
  33. $this->buildGroups($g, $moduleName);
  34.  
  35. }
  36.  
  37. return $this->forward('sfGuardPermission', 'list');
  38. }
  39.  
  40. protected function buildGroups($g, $moduleName)
  41. {
  42.  
  43. $mainGroups=array
  44. (
  45. 'edit'=>array
  46. (
  47. "index",
  48. "list",
  49. "create",
  50. "edit",
  51. "save"
  52. ),
  53.  
  54. 'list'=>array
  55. (
  56. "index",
  57. "list"
  58. ),
  59.  
  60. 'delete'=>array
  61. (
  62. "index",
  63. "list",
  64. "edit",
  65. "delete"
  66. )
  67. );
  68.  
  69. $names=array(
  70. "delete"=>"usuwanie",
  71. "list"=>"oglądanie",
  72. "edit"=>"modyfikowanie"
  73. );
  74.  
  75.  
  76.  
  77. foreach($mainGroups as $type=>$actionName)
  78. {
  79. $g=new sfGuardGroup();
  80. $g->setName($moduleName.'_'.$names[$type]);
  81. $g->save();
  82.  
  83. foreach($actionName as $action)
  84. {
  85. $c=new Criteria();
  86. $c->add(sfGuardPermissionPeer::NAME, $moduleName.'_'.$action);
  87. $p=sfGuardPermissionPeer::doSelectOne($c);
  88. if($p instanceof sfGuardPermission)
  89. {
  90. $gp=new sfGuardGroupPermission();
  91. $gp->setsfGuardPermission($p);
  92. $gp->setGroupId($g->getId());
  93. $gp->save();
  94. $g->addsfGuardGroupPermission($gp);
  95.  
  96. }
  97. }
  98. $g->save();
  99. }
  100. ?>


Modyfikujemy filtr
  1. <?php
  2.  
  3. /*
  4.  * This file is part of the symfony package.
  5.  * (c) 2004-2006 Fabien Potencier <fabien.potencier@symfony-project.com>
  6.  * (c) 2004-2006 Sean Kerr.
  7.  * 
  8.  * For the full copyright and license information, please view the LICENSE
  9.  * file that was distributed with this source code.
  10.  */
  11.  
  12. /**
  13.  * sfBasicSecurityFilter checks security by calling the getCredential() method
  14.  * of the action. Once the credential has been acquired, sfBasicSecurityFilter
  15.  * verifies the user has the same credential by calling the hasCredential()
  16.  * method of SecurityUser.
  17.  *
  18.  * @package symfony
  19.  * @subpackage filter
  20.  * @author  Sean Kerr <skerr@mojavi.org>
  21.  * @version SVN: $Id: sfBasicSecurityFilter.class.php 5001 2007-09-08 08:34:34Z fabien $
  22.  */
  23. class mySecurityFilter extends sfSecurityFilter
  24. {
  25. /**
  26.    * Executes this filter.
  27.    *
  28.    * @param sfFilterChain A sfFilterChain instance
  29.    */
  30. public function execute($filterChain)
  31. {
  32. // get the cool stuff
  33. $context = $this->getContext();
  34. $controller = $context->getController();
  35. $user  = $context->getUser();
  36.  
  37. // get the current action instance
  38. $actionEntry = $controller->getActionStack()->getLastEntry();
  39. $actionInstance = $actionEntry->getActionInstance();
  40.  
  41. // disable security on [sf_login_module] / [sf_login_action]
  42. if (
  43. (sfConfig::get('sf_login_module') == $context->getModuleName()) && (sfConfig::get('sf_login_action') == $context->getActionName())
  44. ||
  45. (sfConfig::get('sf_secure_module') == $context->getModuleName()) && (sfConfig::get('sf_secure_action') == $context->getActionName())
  46. )
  47. {
  48. $filterChain->execute();
  49.  
  50. return;
  51. }
  52.  
  53. // get the credential required for this action
  54. $credential = $actionInstance->getCredential();
  55.  
  56. // TU NASZA MODYFIKACJA
  57. $actionName=$actionInstance->getRequestParameter('action');
  58. $moduleName=$actionInstance->getRequestParameter('module');
  59.  
  60. if(is_array($credential[0]))
  61. {
  62.  $credential[0][]=$moduleName;
  63. $credential[0][]=$moduleName.'_'.$actionName;
  64. }
  65. else
  66. {
  67. $tmp[0][]=$credential;
  68. $credential=$tmp;
  69.  $credential[0][]=$moduleName;
  70. $credential[0][]=$moduleName.'_'.$actionName;
  71. }
  72.  
  73. $cred=$actionInstance->getSecurityConfiguration();
  74. $cred['all']['credentials'][0]=$credential;
  75. $actionInstance->setSecurityConfiguration($cred);
  76. // KONIEC NASZE MODYFIKACJI
  77.  
  78. // for this filter, the credentials are a simple privilege array
  79. // where the first index is the privilege name and the second index
  80. // is the privilege namespace
  81. //
  82. // NOTE: the nice thing about the Action class is that getCredential()
  83. //  is vague enough to describe any level of security and can be
  84. //  used to retrieve such data and should never have to be altered
  85. if ($user->isAuthenticated())
  86. {
  87. // the user is authenticated
  88. if ($credential === null || $user->hasCredential($credential))
  89. {
  90. // the user has access, continue
  91. $filterChain->execute();
  92. }
  93. else
  94. {
  95. // the user doesn't have access, exit stage left
  96. $controller->forward(sfConfig::get('sf_secure_module'), sfConfig::get('sf_secure_action'));
  97.  
  98. throw new sfStopException();
  99. }
  100. }
  101. else
  102. {
  103. // the user is not authenticated
  104. $controller->forward(sfConfig::get('sf_login_module'), sfConfig::get('sf_login_action'));
  105.  
  106. throw new sfStopException();
  107. }
  108. }
  109. }
  110. ?>


Wady: Każdemu userowi dodajemy uprawnienia, a to trwa niekiedy długo i może być skomplikowane
Zalety: Pełen ACL z automatu snitch.gif

Pozdrawiam.
sticker
Chyba wolałbym edytor ymla i podmiana na orginale i w cache od razu. (Edytor jakiś jest w pluginach z tego co pamiętam a jak nie to pisanie powinno zając minimum czasu)
Dla duzej liczy userów nadawanie uprawnień będzie bardzo uciążliwe
AxZx
przewaznie ustawia sie uprawnienia grupom do ktorych przypisujemy userow. ale jak jakis user ma miec specjalne uprawnienia to system rowniez musi pozwalac na ustawienie mu specjalnych uprawnien.
wiec w tabeli trzymasz idgroup, iduser.
0 - wszystkie grupy, wszyscy userzy.

jarek_bolo:
w kohanie i symfony wyglada to podobnie

main_controller
-> my_controller
-> action controller
athabus
Cytat(zimi @ 6.08.2008, 01:35:22 ) *
tak się zastanawiam czy i jeśli tak to w jaki sposób robicie w Symfony możliwość edycji z poziomu panelu administracyjnego serwisu www ustalania praw dostępu danych grup do określonych akcji

przychodzą mi do głowy 2 opcję:
1. generowanie pliku security.yml
2. wrzucenie do pliku security.yml kodów PHP opierających się na danych zgromadzonych gdzieś indziej

jedno gorsze od drugiego szczególnie że trzebaby wyczyścić cache symfony po każdej edycji tych ustawień

w jaki sposób rozwiązujecie tą kwestię?

Spróbuj tego pluginu sfGuardPlugin - nigdy nie korzystałem, ale plugin jest popularny i zbiera niezłe recenzje.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.