Dispatcher: Auch Controller ermöglichen, die Admin-Login benötigen
Default ist für Controller, dass all ihre Funktionen User-Logins benötigen. Kann ein Controller ändern, indem er die Sub "get_auth_level" überschreibt (siehe Doku in SL::Contrller::Base). Dies schafft die Basis dafür, auch Admin-Dinge in der neuen Controller-Architektur zu implementieren.
Für die Zukunft kann man leicht ein weiteres Level neben 'user' und 'admin' einbauen, z.B. 'none' für Actions, die definitiv kein Login benötigen.
Funktionierendes Beispiel für einen solchen Controller (Aufruf dann über URL ".../controller.pl?action=AdminTest/proof_of_concept"):
package SL::Controller::AdminTest;
use strict;
use parent qw(SL::Controller::Base);
use Rose::Object::MakeMethods::Generic ( scalar => [ qw(business) ], );
#
actions
#
sub action_proof_of_concept { my ($self) = @_;
$::form->header; print $self->render(<<EOHTML, { inline => 1 }); <body> <p>I've been called with an ADMIN login only!</p> </body> </html> EOHTML }
Dispatcher: Auch Controller ermöglichen, die Admin-Login benötigen
Default ist für Controller, dass all ihre Funktionen User-Logins
benötigen. Kann ein Controller ändern, indem er die Sub
"get_auth_level" überschreibt (siehe Doku in
SL::Contrller::Base). Dies schafft die Basis dafür, auch Admin-Dinge
in der neuen Controller-Architektur zu implementieren.
Für die Zukunft kann man leicht ein weiteres Level neben 'user' und
'admin' einbauen, z.B. 'none' für Actions, die definitiv kein Login
benötigen.
Funktionierendes Beispiel für einen solchen Controller (Aufruf dann
über URL ".../controller.pl?action=AdminTest/proof_of_concept"):
package SL::Controller::AdminTest;
use strict;
use parent qw(SL::Controller::Base);
use Rose::Object::MakeMethods::Generic
#(
scalar => [ qw(business) ],
);
sub action_proof_of_concept {
#my ($self) = @_;
sub get_auth_level {
return 'admin';
}
1;