Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

NW74 authority check on call transaction

Former Member
0 Kudos

Hello,

On NW74, ABAP help mentions that usage of CALL TRANSACTION statement without the new additions WITH AUTHORITY-CHECK or WITHOUT AUTHORITY-CHECK is obsolete; And among other things, these additions override the content of TCDCOUPLES.

Does that mean maintenance of calling-called tcode pairs in SE97/TCDCOUPLES beyond NW731 is not longer necessary?

I actually ran a test for SM21 that calls SM21_OLD, when the SM21-->SM21_OLD check in SE97 is disabled, the auth.check for SM21_OLD still takes place and shows in trace too!

And is it correct to infer that MM-- tcodes calling MM01 mean MM01 will need to be added to the relevant security roles?

I've searched forum for relevant posts/blogs, could not find any close hits on this find. Please share your thoughts, and if you found a way to still enforce such checks.

Thanks,

Pawan.

1 ACCEPTED SOLUTION

Former Member
0 Kudos

🙂

CALL TRANSACTION has always checked S_TCODE, it is just that the sy-subrc was set to 0 regardless of authorizations.

SE97 gives you an option of coupling exceptions based on the calling transaction -> if checked before the call you can turn it OFF. If checked in the target transaction program you can turn ON (disable the check).

The new syntax basically hardcodes these two options in the calling program.

Not using them is obsolete, but that does not mean that CALL TRANSACTION does not work anymore. It just means that you should not use it anymore without explicitly indicating in the calling transaction whether the check is wanted there or not. It forces developers to think about it and show intention.

Whether it happens anyway and SE97 is respected in the called transaction is a different topic (if the target program performs AUTHORITY-CHECKs or calls AUTHORITY_CHECK_TCODE of it's own).

Cheers,

Julius

4 REPLIES 4

Former Member
0 Kudos

🙂

CALL TRANSACTION has always checked S_TCODE, it is just that the sy-subrc was set to 0 regardless of authorizations.

SE97 gives you an option of coupling exceptions based on the calling transaction -> if checked before the call you can turn it OFF. If checked in the target transaction program you can turn ON (disable the check).

The new syntax basically hardcodes these two options in the calling program.

Not using them is obsolete, but that does not mean that CALL TRANSACTION does not work anymore. It just means that you should not use it anymore without explicitly indicating in the calling transaction whether the check is wanted there or not. It forces developers to think about it and show intention.

Whether it happens anyway and SE97 is respected in the called transaction is a different topic (if the target program performs AUTHORITY-CHECKs or calls AUTHORITY_CHECK_TCODE of it's own).

Cheers,

Julius

0 Kudos

Thanks Julius for clarifying, I should have tested the statement first and it does work without the additions clause and I believe its introduced to enable secure development. But I am lost why override TCDCOUPLES!

Pawan.

0 Kudos

There are 2 checks in the kernel when you call a transaction -> the S_TCODE and the additional check in SE93 (table TSTCA). Sometimes this contains the S_TCODE as well (from days before the start check in the menu was there) and at other times a plausibility check as it makes no more sense to continue (it would seem).

CALL TRANSACTION sets sy-subrc = 0 for the transaction call on S_TCODE check. But TSTCA settings still set sy-subrc based on your authorizations.

The new syntax WITHOUT also bypasses this additional check. CALL TRANSACTION also commits the screens explicitly.

So yes, it forces the developer to show explicit intention and the checks MUST be performed beforehand.

Else, WITH will check S_TCODE and TSTCA etc and the calling program developer can leave the checks up to the target transaction. Eg, a list report with basic header data in ALV, with on-click navigation via CALL TRANSACTION to a document display with details and back again. But even here, you might not want to give users direct access to the target transaction, so the CALL TRANSACTION is still perfectly OK to use in several contexts.

Cheers,

Julius

0 Kudos

I proceeded to test and find on my own, and I must agree with what you wrote.

Denying a test user any authorizations on the called transaction only granting the calling transaction, after running a dozen test cases, I was able to find that:

WITHOUT clause - Does not check for TSTCA, TCDCOUPLES, and only stops at the hard-coded AUTHORITY-CHECK 'S_TCODE' statement in the called program with RC=4

Omit the clauses WITH/WITHOUT altogether - TSTCA is not checked, but properly maintained TCDCOUPLES and hard-coded checks in called program can come in handy

WITH clause - strongest with all other checks


Thanks again,

Pawan.