check,Query execution:Authorization Check Logic

check,Query execution:Authorization Check Logic
check,Query execution:Authorization Check Logic
Summary
Symptom
The tabular block of the detail check in the authorization check of a query is hard to understand.
Other terms
RSECADMIN, RSECPROT, log
Reason and Prerequisites
Note 1234567 provides a description of the whole RSECADMIN log.
Solution
The RSECADMIN log informs you that:
In the next section, all other characteristics are checked in detail:
This means that all optimizations and advance simplifications are completed and the query selection has been split into subselections (SUB numbers), if necessary.
Now the main part of the authorization check runs for the individual SUB numbers. The process flow is displayed in a table.
The table has a blue header line that begins _disibledevent=>To display sets, the relevant characteristics are always listed in the left part of a column. In the right part, a language similar to SQL is used to describe the sets.
To understand the check, you must be familiar with the following logic:
The background: During each authorization check, the query gives the selected set to the authorization check. The system then checks whether this set is fully covered by the authorized set (= "authorized") or not (="not authorized").
A user may have several individual authorizations. If this is the case, the check is carried out step by step iteratively: The selected set is compared with the first authorization (first authorization set). If this authorization set already covers the selected set, the check is complete because the selected set is already successfully authorized. If the authorization set does not cover the selected set completely, the remaining set that is not yet authorized is determined and displayed: This is the part of the selected set that was not covered by the first authorization (= authorized).
The same check process begins with this remaining set (remaining selection). However, now the second authorization is used. The following applies: If the second authorization set covers the remaining selection, the check is complete because the whole selected set is now successfully authorized.
If this is not the case, the system determines the remaining set again. This is now part of the selected set that was not covered by the first or the second authorization.
This process is now repeated until the whole selected set is covered by the authorized sets. Then the check is successful.
Alternatively, this process is repeated until all authorizations of the user have been checked but there is still some of the selection set remaining. This remaining set is then not authorized: The check for this SUB number returns "No authorization".
Important:
Bear in mind that the log may display an unsuccessful partial check during the first iteration steps. However, the selected set may be authorized later _disibledevent=>If a subselection (SUB number) is authorized, the system displays the following line in green:
"Subselection (SUBNR) Is Authorized".
However, if a subselection is not authorized, the system displays the following lines:
"All Authorizations Tested"
Message EYE 007: "You do not have sufficient authorization"
(in yellow).
"No Sufficient Authorization for This Subselection (SUBNR)"
(in yellow).
Then the system may display the text block
"Following CHANMIDs Are Affected:"
123 ( )
345 ( )
The specification of the technical characteristic names (after CHANMID) indicates the characteristics for which the check failed. Note that each selected characteristic may be authorized _disibledevent=>Consider the following points in particular:
1. The first field "Following Set Is Checked", at the top left of the blue table is usually the most important: Here, you have the unchanged selected set as it is requested by the query. If you think there may be a problem with the authorization check, you should first always check whether this set is what you expect:
Does the query request the correct data? Or does it try to read more data than expected? (This may lead to "No authorization").
If this is the case, it does not mean that the error lies in the authorization check, rather that you must check the query definition: To narrow down the error, first replace all variable selections with fixed selections. If there are "constant selections" in the query, deactivate them or check them. If there are "cell definitions", deactivate them or check them. (Note that a customer message can be processed more quickly if the component is correct.)
2. If long lists of single values are selected or authorized, for example, the table may be very large. However, the main structure is always the same.
3. Due to the internal flow of the authorization check, a block in the table may be displayed twice _disibledevent=>4. "NOT" conditions may appear in the remaining set, in particular. This is not an error, rather the logical sequence of creating a remaining set: Selected set minus authorized set.

After _disibledevent=>"Subselection (technical SUBNR) 2"
(Highlighted in light orange)
The processing of all subselections is completed with the entry:
"Authorization Check Complete"
(In italics and highlighted in orange)
源文档
Tags:  checkin logic check

延伸阅读

最新评论

发表评论