Martin Bartosch wrote:
I recommend to throw away this stuff an replace it by a simpler solution. The commands are always loaded. So why do we do not using them? I have the following idea:
Example: OpenCA::Server::Command::insert_csr.pm
$AC::operation = "csr insertion"; $AC::owner = "REQUEST";
The operation is the same like the today's XML tag operation. Owner is a simplification with a more powerful logic. If the value is an OBJECT CLASS (like REQUEST) then we use the parameter KEY to load the object from the database and take the role from the loaded object (e.g. approve_csr). If the value is ROLE then we use the parameter role to read the role from it (e.g. insert_csr). If the value is empty then there is no role.
sounds good. So later on there would be a simple check
$AC::check_authorization() || return undef;
No, the access control module uses the two variables to check the authorization. The variables only define the behaviour of this function. The access control should always be performed and invoked centrally. Otherwise a programmer can forget or uncomment the function for testing and then commit. If only the local configuration is damaged then the impact is not so heavy. Additionally I see no reason for the delegation of the access control to a command.
$AC is not the access control from the OpenCA::Server instance. It is a class variable of OpenCA::Server::Command::insert_csr. I was only too lazy to always write the full class. Shame on me ;)
Sorry Michael -- _______________________________________________________________
Michael Bell Humboldt-Universitaet zu Berlin
Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 [EMAIL PROTECTED] D-10099 Berlin _______________________________________________________________
smime.p7s
Description: S/MIME Cryptographic Signature
