Ansicht
Dokumentation
ABENBDL_DEF_AUTH_CONTEXT - BDL DEF AUTH CONTEXT
BAL_S_LOG - Application Log: Log header data BAL Application Log DocumentationThis documentation is copyright by SAP AG.
- define authorization context
define authorization context ContextName
$[${for disable(${modify$|read$|modify,read$})$}$]
{
AuthObject1;
$[AuthObject2;$]
$[...$]
}
Effect
A CDS behavior definition can define authorization contexts using the statement define authorization context. Authorization contexts list several authorization objects that are used for the ABAP statement AUTHORITY-CHECK OBJECT. When an authorization context is activated, authority checks for all associated authorization objects are always successful; in other words, the respective authorization checks are skipped. This can be useful, for example, when a BDEF implements its own authorization check and then calls existing code, which again has its own authorization checks.
One CDS behavior definition can define one or multiple authorization contexts. The contexts may be defined before, between, or after the entity behavior definitions. Each context can contain one or more authorization objects AuthObject1, AuthObject2, .... It is also possible to define an empty authorization context. This can be useful when using BDEF privileged mode: to enable BDEF privileged mode, it is mandatory to specify at least one authorization context. However, some RAP BOs use authority checks that don't rely on authorization objects. In this case, an empty authorization context can be specified.
The optional addition for disable(${modify$|read$|modify,read$}) activates the authorization context in question for certain handler methods. When a context is activated for a handler method, then the corresponding handler method is automatically and implicitly disabled for the authorization context in the ABAP behavior pool.
Example:
define authorization context ReadContext
for disable (read)
...
in the BDEF has the effect that
METHOD read.
...
ENDMETHOD.
in the ABAP behavior pool behaves as if the code was
METHOD read.
AUTHORITY-CHECK DISABLE BEGIN CONTEXT demo_context~ReadContext.
...
AUTHORITY-CHECK DISABLE END.
ENDMETHOD.
Currently, only the handler methods modify and read are available. They can be specified individually, or both together. Each handler method can only be assigned once within a CDS behavior definition.
Activating an Authorization Context
There are the following possibilities to activate an authorization context and skip the corresponding authorization objects:
- by using AUTHORITY-CHECK DISABLE BEGIN CONTEXT ... AUTHORITY-CHECK DISABLE END in the ABAP behavior pool for a handler or saver method.
- implicitly by registering a context for use in privileged mode.
- implicitly by registering a context for a category of handler method, as described above.
Availability
- Projection BDEF: a projection BDEF can define an authorization context independently of the projected BDEF. That means, an authorization context can be defined in the projection layer even if the projected entity does not have an authorization context.
Note
The optional registration of an authority context to a dedicated purpose using the syntax for disable(${modify$|read$|modify,read$}) does not generate an AUTHORITY-CHECK DISABLE BEGIN CONTEXT ... AUTHORITY-CHECK DISABLE END brace within handler methods that are introduced by RAP extensions. In other words, no such brace is generated in implementation classes that are named in extension BDEFs.
Example
The following managed BDEF defines two authorization contexts: ac1 and ac2 with the addition for disable.
The example Using the addition PRIVILEGED with an Statement defines an authorization context and registers it for use in privileged mode. It then demonstrates access to the RAP BO, first without the addition PRIVILEGED, afterwards with using PRIVILEGED.
Fill RESBD Structure from EBP Component Structure Vendor Master (General Section)
This documentation is copyright by SAP AG.
Length: 7172 Date: 20240511 Time: 162134 sap01-206 ( 88 ms )
