Working with OpenPetra Security: Difference between revisions
(Created page with '== Overview == ''OpenPetras' security system is based on PETRA 2.x's security system.'' * Module Security is implemented in OpenPetra. * Table Security is implemented in OpenPet…') |
|||
| Line 15: | Line 15: | ||
=== Programmatically Accessing an OpenPetra Users' Security Details === | === Programmatically Accessing an OpenPetra Users' Security Details === | ||
An OpenPetra Users' Security Details can be easily accessed both on the client and on the server side, using the same mechanism. | |||
=== GUserInfo Class === | |||
* The GUserInfo Class is populated with data from the DB when the user logs in. Refreshing of that data is not possible at present once the user has logged int (that could be desirable when the System Administrator changes permissions for a logged-in user, though). | |||
* It has various Methods to check different security aspects: IsInModule. IsTableAccessOK, etc. | |||
Note: Though the TPetraPrincipal Class has Fields 'FRoles' and 'FFunctions' Fields and a Method 'IsInRole', those aren't populated/are not returning anything useful as they tie in with the planned improvements to the security model. | |||
'''TODO''' | |||
==== Client-side specific ==== | |||
* On the client side we have a convention of coding OpenPetra Users' Security checks into Forms and UserControls in a standard way: we create a Method called 'ApplySecurity' in the relevant *ManualCode.cs file and add code to that that performs the necessary checks. That Method is usually called when a Form is opened or a UserControl gets instantiated. | |||
For an example of such a Method refer to <code>\csharp\ICT\Petra\Client\MCommon\Gui\UC_PartnerAddresses.cs</code>. There you also see the standard XML Documentation that we decorate such a Method with. | |||
'''TODO''' | '''TODO''' | ||
Revision as of 12:59, 7 April 2014
Overview
OpenPetras' security system is based on PETRA 2.x's security system.
- Module Security is implemented in OpenPetra.
- Table Security is implemented in OpenPetra.
- Security Groups: not fully implemented - while security groups exist in the DB, they can at present not be assigned to users.
Enhancements that would allow more fine-grained security and other special features are planned. Provision for those enhancements are already in the DB Schema, but no functionality to access those DB Tables is implemented yet.
Specifying OpenPetra Module-level Security for Screens (Client-side)
TODO
Specifying OpenPetra Module-level Security for Screens and their functionality (Server-side)
TODO
Programmatically Accessing an OpenPetra Users' Security Details
An OpenPetra Users' Security Details can be easily accessed both on the client and on the server side, using the same mechanism.
GUserInfo Class
- The GUserInfo Class is populated with data from the DB when the user logs in. Refreshing of that data is not possible at present once the user has logged int (that could be desirable when the System Administrator changes permissions for a logged-in user, though).
- It has various Methods to check different security aspects: IsInModule. IsTableAccessOK, etc.
Note: Though the TPetraPrincipal Class has Fields 'FRoles' and 'FFunctions' Fields and a Method 'IsInRole', those aren't populated/are not returning anything useful as they tie in with the planned improvements to the security model.
TODO
Client-side specific
- On the client side we have a convention of coding OpenPetra Users' Security checks into Forms and UserControls in a standard way: we create a Method called 'ApplySecurity' in the relevant *ManualCode.cs file and add code to that that performs the necessary checks. That Method is usually called when a Form is opened or a UserControl gets instantiated.
For an example of such a Method refer to \csharp\ICT\Petra\Client\MCommon\Gui\UC_PartnerAddresses.cs. There you also see the standard XML Documentation that we decorate such a Method with.
TODO