CI metožu aizsardzība

[Blitz]

Kā pareizi un ērti aizsargāt metodes kuras ir pieejamas tikai autorizētam lietotājam?

 

Viens variants ir pārbaudīt klases konstruktorā, ja nav autorizējies, redirect uz login lapu. Priekš tiem kas neklausa redirektiem, jāliek exit vai kas tml, kas no stila viedokļa, galīgi neliekas pareizi.

 

Otrs ir pārbaudīt vai ir autorizējies katrā metodē, kas atkal liekas neerti un nepareizi.

 

Kādi vēl ieteikumi?

 

Paldies.

 

Te kods piemēram: http://paste.php.lv/12905b7d73c724cbe828283f8b6d15ee

if ( ! defined('BASEPATH')) exit('No direct script access allowed');

class Tyres extends CI_Controller {

function __construct() {
 parent::__construct();
 if(!$this->session->userdata('admin')) {
  redirect('login');
  exit;
 }
}
function method() {

}
}

[briedis]

Ir arī metode before(). (vai arī CI tādas nav?)

 

Es daru tā, ka uztaisu abstraktu klasi, kas satur pārbaudes before() metodē (vai konstruktorā, kāda starpība?), un tad vajadzīgie kontrolieri vienkārši manto šo abstrakto kontrolieri.

Muļķīgi būtu pārbaudes rakstīt katrā kontrolierī, tas ir klajš DRY principa pārkāpums.

 

Šo gan es nesapratu:

Priekš tiem kas neklausa redirektiem, jāliek exit vai kas tml

 

Kā tad var neklausīt šim?

 

if(!$logged_in){


redirect(login.php); //Vai attiecīgā redirect metode, kas ir CI
}

[daGrevis]

Dari tā kā briedis skaidroja ar mantošanu un before(), bet... vēl vari pietaisīt tādu fīču, ka iekš konfigurācijas direktorijas ir /permissions direktorija kur tālāk ir faili, kuru nosaukums ir identisks kontrolera nosaukumam.

 

/config
   /permissions
       index.php
       article.php
       shop.php

 

Katrs tāds fails atgriež masīvu kur masīva atslēgas ir ekšena ('action') nosaukums. Citiem vārdiem, metodes nosaukums. Un masīvā pretī atslēgai glabājās vēl viens masīvs kurš satur kalbekus ("callback"), kas atgriež būleānu. Ja kaut kas nesakrīt, parādam exception vai ko tamlīdzīgu.

 

article.php:

 

return array(
   'index' => array('A11n_Basic::is_in', 'A11n_Article::can_read')
);

[Blitz]

Ir arī metode before(). (vai arī CI tādas nav?)

hz, tādu neatrodu itkā

Es daru tā, ka uztaisu abstraktu klasi

Neesu spēcīgs OOP, bet vai tad šai gadījumā CI_Controller jau nav klases Tyres abstraktā klase, un vai vienai klasei var būt vairākas abstraktās klases? Bet tā domu sapratu, liekas...

Kā tad var neklausīt šim?

redirect jau nosūta tikai http hederi, to ignorējot (izslēdzot sekošanu redirektiem) viss turpina notikties. Vai tad tā nav?

 

pietaisīt tādu fīču

pagooglēšu par šo tēmu

Edited November 1, 2011 by Blitz

[daGrevis]

hz, tādu neatrodu itkā

 

Tad izmanto __construct() metodi.

 

Neesu spēcīgs OOP, bet vai tad šai gadījumā CI_Controller jau nav klases Tyres abstraktā klase, un vai vienai klasei var būt vairākas abstraktās klases? Bet tā domu sapratu, liekas...

 

CI_Controller ir abstrakta, ja pie deklarācijas ir abstract class, nevis tikai class. Tas, kas tev ir jāizdara... viens no veidiem: class Tyres extends Permissions, tad abstract class Permissions extends CI_Controller.

 

Labojums:

 

Classes defined as abstract may not be instantiated...

[briedis]

hz, tādu neatrodu itkā

 

Neesu spēcīgs OOP, bet vai tad šai gadījumā CI_Controller jau nav klases Tyres abstraktā klase, un vai vienai klasei var būt vairākas abstraktās klases? Bet tā domu sapratu, liekas...

 

redirect jau nosūta tikai http hederi, to ignorējot (izslēdzot sekošanu redirektiem) viss turpina notikties. Vai tad tā nav?

 

Ir, bet tas neliedz izveidot vēlvienu klasi, Abstract_Admin_Controller, kas manto CI_Controller. Tad arī savā Tyres klasē manto to Abstract_..

 

Nu jā, bet tas jau ir tikai normāli, ka pēc header("Location tiek likts arī exit(), lai tālāk nekas neizpildās. Domāju, ka CI atbilstošajā redirect metodē tas jau ir implementēts.

[Blitz]

CI_Controller ir abstrakta, ja pie deklarācijas ir abstract class, nevis tikai class. Tas, kas tev ir jāizdara... viens no veidiem: class Tyres extends Permissions, tad abstract class Permissions extends CI_Controller.

Ir, bet tas neliedz izveidot vēlvienu klasi, Abstract_Admin_Controller, kas manto CI_Controller. Tad arī savā Tyres klasē manto to Abstract_..

 

Tad iznāk jātaisa mantošanas ķēdīte nevis Tyres->CI_Controller bet Tyres->Permisions->CI_Controller. Viss skaidrs. To jau principā var taisīt tādu universālu, kas glabā visas kontrolieru kopīgās/vienādās metodes utt. ne tikai permisions tēmu?

 

Domāju, ka CI atbilstošajā redirect metodē tas jau ir implementēts.

paskatījos, ir gan tomēr ;)

Edited November 1, 2011 by Blitz

[daGrevis]

Var taisīt kā vēlies. Domu jau uztvēri! :)

[Mr.Key]

Nu re, Zend Framework to taisa kā Front Controller pluginu, ļoti ērti, nav jātaisa ekstendētās klases, nemaz nerunājot par pārbaudi katrā klasē vai metodē.

 

Plugina metode tiek izsaukta pirms kontrolliera klases izsaukšanas, attiecīgi, iespējams veikt pārbaudi pēc moduļa, kontrolliera, action un parametriem, vienāršā ACL gadījumā mappojot autorizētajam lietotājam pieejamo ar ACL tabulu, pavisam vienkāršā gadījumā pārbaudot, vai eksistē aktīva autorizācija un redirect uz login lapu, ja nē.

 

Nevar būt, ka CI kaut kas tāds nav...

 

Edit - okay, ir hooks

http://codeigniter.com/forums/viewthread/75526/P15/#950101

Edited November 5, 2011 by Mr.Key

[Turecky]

Var paskatīties http://codeigniter.tv varbūt arī kas noder.

 

Variants:

lai nebūtu jāraksta kāds plugin vai biblotēka kontroles metodes var mēģināt ielikt paplašinātājā controlieri. Ideja tāda, ka application/core mapē izveido MY_Controller.php, kas extendē CI_Controller. Līdz ar to iekš MY_Controller var uztaisīt pārbaudes vai izsaukt kādas metodes, kas pārbauda vai lietotājs ir ielogojies vai nav, ja nav redirektējam uz login. Līdz ar to atkrīt atkārtošanās.

Pats izmantoju šādu struktūtu. Arī iepriekš nevarēju iebraukt, kā korekti un bez liekas rakstīšanas veikt pārbaudes uz login. Cerams, ka vēl aktuāla un noderīga lieta.