sandraros / abap-soar

Seamless Outsourced ABAP Run

abap-soar

Seamless Outsourced ABAP Run

abap-soar's Issues

Hash key in authorization ZSOAR_HASH is changed to upper case

Example of value: u0aMPY04s941N3230HFrAg==.
In PFCG, it becomes: U0AMPY04S941N3230HFRAG==.

The field is based on the data element DYN_ABAP_DTE_FINGERPRINT which is CHAR 24 but no domain assigned, so it's all upper case (although it may technically contain lower case characters, see in table DYNABAPHDR).

After an authorization error (hash key or date), subsequent runs always return CX_SY_REF_IS_INITIAL

It's because an entry with null instance is inserted even if initialize fails. See current code:

      INSERT VALUE #(
              srp_id = srp_id
          ) INTO TABLE managers
          REFERENCE INTO manager.

      manager->instance = NEW zcl_soar_manager( ).

      manager->instance->srp_id = srp_id.
      manager->instance->provider = provider.

      manager->instance->initialize( ).

Should insert only if initialize succeeds e.g.:

      DATA(manager_instance) = NEW zcl_soar_manager( ).

      manager_instance->srp_id = srp_id.
      manager_instance->provider = provider.
      manager_instance->initialize( ).

      INSERT VALUE #(
              srp_id   = srp_id
              instance = manager_instance
          ) INTO TABLE managers
          REFERENCE INTO manager.

Hash key error message doesn't indicate the SRP ID and hash key

Current:

RAISE EXCEPTION NEW zcx_soar( text  = 'This version of the ABAP code is not authorized'(010)
                              msgv1 = srp_id ).

To be:

RAISE EXCEPTION NEW zcx_soar( text  = 'This version of the ABAP code is not authorized (&1 - &2)'(010)
                              msgv1 = srp_id
                              msgv2 = hash_key ).

Add RAISING zcx_soar to METHODS get_abap_source_code in zif_soar_provider

Uncaught CX_SY exceptions on GENERATE SUBROUTINE POOL

In the method which runs GENERATE SUBROUTINE POOL, the CX_SY exceptions mentioned in the ABAP documentation are not caught. Is it possible to add them? e.g. as follows:

    TRY.

        GENERATE SUBROUTINE POOL ...

      CATCH cx_sy_generate_subpool_full
            cx_sy_gen_source_too_wide
            INTO DATA(error).

        RAISE EXCEPTION TYPE zcx_soar
          EXPORTING
            text     = 'Global generation error'
            previous = error.

    ENDTRY.

Syntax error

RAISE EXCEPTION NEW does a syntax error in 7.40. Only RAISE EXCEPTION TYPE is accepted.

Replace this block:

abap-soar/src/zcl_soar_manager.clas.abap

Lines 190 to 220 in 5c402c2

	TRY.
	DATA(abap_source_code) = provider->get_abap_source_code( srp_id ).
	CATCH zcx_soar INTO error.
	RAISE EXCEPTION NEW zcx_soar( text = 'Error while getting the ABAP source code'(009)
	previous = error ).
	ENDTRY.
	" Calculate the hash key
	TRY.
	DATA(hash_key) = get_hash_key( abap_source_code ).
	CATCH cx_abap_message_digest INTO error.
	RAISE EXCEPTION NEW zcx_soar( text = 'Hash key calculation error. Please contact the support.'(006) ).
	ENDTRY.
	" Check authorizations for the hash key
	AUTHORITY-CHECK OBJECT 'ZSOAR_HASH'
	ID 'ZSOAR_SRP' FIELD srp_id
	ID 'ZSOAR_HASH' FIELD hash_key.
	IF sy-subrc <> 0.
	AUTHORITY-CHECK OBJECT 'ZSOAR_DATE'
	ID 'ZSOAR_SRP' FIELD srp_id
	ID 'ZSOAR_DATE' FIELD sy-datum.
	IF sy-subrc <> 0.
	RAISE EXCEPTION NEW zcx_soar( text = 'This version of the ABAP code is not authorized (&1 - &2)'(010)
	msgv1 = srp_id
	msgv2 = hash_key ).
	ENDIF.
	ENDIF.

with:

      TRY.
          DATA(abap_source_code) = provider->get_abap_source_code( srp_id ).
        CATCH zcx_soar INTO error.
          RAISE EXCEPTION TYPE zcx_soar
            EXPORTING
              text     = 'Error while getting the ABAP source code'(009)
              previous = error.
      ENDTRY.

      " Calculate the hash key
      TRY.
          DATA(hash_key) = get_hash_key( abap_source_code ).
        CATCH cx_abap_message_digest INTO error.
          RAISE EXCEPTION TYPE zcx_soar
            EXPORTING
              text = 'Hash key calculation error. Please contact the support.'(006).
      ENDTRY.

      " Check authorizations for the hash key
      AUTHORITY-CHECK OBJECT 'ZSOAR_HASH'
          ID 'ZSOAR_SRP'  FIELD srp_id
          ID 'ZSOAR_HASH' FIELD hash_key.

      IF sy-subrc <> 0.

        AUTHORITY-CHECK OBJECT 'ZSOAR_DATE'
            ID 'ZSOAR_SRP'  FIELD srp_id
            ID 'ZSOAR_DATE' FIELD sy-datum.

        IF sy-subrc <> 0.
          RAISE EXCEPTION TYPE zcx_soar
            EXPORTING
              text  = 'This version of the ABAP code is not authorized (&1 - &2)'(010)
              msgv1 = srp_id
              msgv2 = hash_key.
        ENDIF.
      ENDIF.

Rename objects to have non-ambiguous names for Shrinker

The following names are used for data elements, domains, authorization fields, authorization objects:

• ZSOAR_DATE
• ZSOAR_HASH

That's a problem with the tool https://github.com/sandraros/shrinker, when it's used to copy all SOAR objects to objects with different names. Each shrinked object should better have a distinct name.

Add MIT License notice at top of files

Just to make it clear.

Compatibility 7.40

Syntax error in 7.40 SP 23:

Field "NEW" is unknown. It is neither in one of the specified tables nor defined by a "DATA" statement.

at:

abap-soar/src/zcl_soar_manager.clas.abap

Line 169 in 63d2db4

RAISE EXCEPTION NEW zcx_soar( text = 'SOAR Internal Error. Please contact support.'(012) previous = error_2 ).

Solution: this should be compatible with 7.40:

  RAISE EXCEPTION TYPE zcx_soar EXPORTING text = 'SOAR Internal Error. Please contact support.'(012) previous = error_2.

Date format in authorizations

In PFCG, if the administrator types a date in the field ZSOAR_DATE of the authorization object ZSOAR_DATE, it's stored as is, e.g. 311223 (Dec 31st, 2023) is stored 311223.

It should be permitted to input date intervals, hence

One solution could have been to type the dates directly in YYYYMMDD format.

A more user-friendly solution is to do a fix, to input the dates in user format and they are converted internally into internal format YYYYMMDD, e.g. a date in European user format, either 311223 or 31.12.2023, should be stored as 20231231.

NB: by using the standard SDATE conversion exit, it would accept a date input in user date format, stored in format YYYYMMDD and the output is with month as a three-characters abbreviation e.g. 20231231 → 31.DEC.2023 ("DEC" = abbreviation of month number 12/December in English).

Do not regenerate subroutine pool in the same internal session

ZCL_SOAR_MANAGER should not regenerate the subroutine pool if it already exists in the current internal session, it should reuse the subroutine pool which exists in the current internal session.

To reproduce:

• Run ZSOAR_DEMO with option "Outsourced" twice during the same internal session.
• See that the subroutine pool name is incremented at each run, meaning that generate subroutine pool is executed each time.

Expected:

• The subroutine pool name should be unchanged.
• Only after clicking "Start a new internal session" a new subroutine pool is generated (new name).

Trace any temporary-permitted outsourced ABAP code

In case the outsourced ABAP code is permitted to be modified for a given period of time, it would be good to know which versions of ABAP code have been run, to be able to audit the ABAP code by looking at the GENERATE SUBROUTINE POOL trace (abap/dyn_abap_log = "on" / tables DYNABAPHDR and DYNABAPSRC / program RDYNABAP_SHOW).

To permit it, the SOAR hash key might be calculated the same way as the SAP one (UTF-8 encoding of ABAP code and MD5), be output to somewhere (custom table or SAP system log?), in order to display the ABAP code by running the program RDYNABAP_SHOW.

For information, the table column DYNABAPHDR-FINGERPRINT (e.g. fDC4bo1c6WRamshsWy7Mug==) is checked by program RDYNABAP_SHOW:

      cl_abap_gzip=>decompress_binary( EXPORTING
                                         gzip_in     = dynabapsrc-code
                                       IMPORTING
                                         raw_out     = decompressed_code
                                         raw_out_len = length ).

  cl_abap_message_digest=>calculate_hash_for_raw( EXPORTING
                                                    if_algorithm = `MD5`
                                                    if_data      = decompressed_code
                                                  IMPORTING
                                                    ef_hashb64string = fingerprint ).

Make it easier to instantiate the manager with dynamic reference

If an application is using SOAR and proposes to use either SOAR as embedded (duplicated objects delivered with the application) or SOAR installed separately, the code in the application is to be referring dynamically the official SOAR objects (because SOAR may not be installed, so referring statically would make the installation of the application fail at activating these objects), and the dynamic code is quite complex.

It should be possible to propose something simple in SOAR to make it easier to call it dynamically by the application.

ATC checks 7.56

ATC checks 7.56:

Caution: Due to the addition REDUCED FUNCTIONALITY in the statement REPORT/PROGRAM, not all ABAP commands are available.

abap-soar/src/zsoar_demo_inhousedev_form.prog.abap

Line 30 in 63d2db4

PROGRAM zsoar_demo_inhousedev_form REDUCED FUNCTIONALITY.

abap-soar/src/zsoar_demo_inhousedev_full_oo.prog.abap

Line 30 in 63d2db4

PROGRAM REDUCED FUNCTIONALITY.

abap-soar/src/zsoar_manager_test_inhousedev.prog.abap

Line 30 in 63d2db4

PROGRAM zsoar_manager_test_inhousedev REDUCED FUNCTIONALITY.

Appl. Comp. Check / Check Class / Message Code
BC-ABA-LA / CL_CI_TEST_SYNTAX_CHECK / MESSAGEGB8
Details of Analysis
•Caution: Due to the addition REDUCED FUNCTIONALITY in the statement REPORT/PROGRAM, not all ABAP commands are available.
•Cannot be suppressed using a pragma or pseudo-comment
What is checked?
Test Based on the Syntax Check
Variants controlled using attributes:
•More than one error message is displayed
•Warnings are displayed
•Information messages are displayed

Call Executable Program (SY-REPID)

abap-soar/src/zsoar_demo.prog.abap

Lines 118 to 125 in 63d2db4

	SUBMIT (sy-repid)
	WITH outsourc = outsourc
	WITH inhouse = inhouse
	WITH form = form
	WITH full_oo = full_oo
	WITH factory = factory
	WITH createob = createob
	VIA SELECTION-SCREEN.

Appl. Comp. Check / Check Class / Message Code
BC-ABA-LA / CL_CI_TEST_CRITICAL_STATEMENTS / 0005
Details of Analysis
•Call Executable Program (SY-REPID)
•Finding can be suppressed with pseudo comment "#EC CI_SUBMIT
What is checked?
Critical Statements
Executable program called: SUBMIT rep
The statement SUBMIT calls an executable program rep.
The message can be hidden using the pseudo-comment "#EC CI_SUBMIT.

Missing authorization check in report ZSOAR_DEMO

Appl. Comp. Check / Check Class / Message Code
BC-ABA-LA-EPC / CL_CI_TEST_EXTENDED_CHECK_SEC / 11A1
Details of Analysis
•Missing authorization check in report ZSOAR_DEMO
•Statement SELECT ZSOAR_INHOUSEDEV reached without authorization check (include
•ZCL_SOAR_MANAGER==============CM004, line 5).
•Execution path found:
•Include ZSOAR_DEMO, line 144
•Include ZCL_SOAR_MANAGER==============CM006, line 11
•Cannot be suppressed using a pragma or pseudo-comment
What is checked?
Potentially missing authorization check in a report
Message number 11A1
Authorization checks should be used to secure reports against being called by unauthorized users.
Procedure
Check whether an authorization check exists for this report and, if necessary, add a check at the start of the report. If the report is already being used or has been delivered, a switchable authorization check should be integrated using the method call CL_SACF=>AUTH_CHECK_SPEC( ).
It is also possible to assign an authorization group to the report, in which case an authorization check does not need to be integrated and no message is displayed (if the group is entered in database table TPGP and hence valid). The authorization group can be entered in the attributes of the report.
If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

Enrich exception returned by CREATE_OBJECT and CALL_STATIC_METHOD with class and method names

Currently, the methods CREATE_OBJECT and CALL_STATIC_METHOD of ZIF_SOAR_MANAGER return any class-based exception of the called method, as it is, but no information about the class and method names (or "CREATE OBJECT").

Hence, any application calling these two methods has to enrich the original exception.

Maybe it's worth encapsulating it into a ZCX_SOAR exception to systematically provide a message containing the information about which class and method (or "CREATE OBJECT") were called which have lead to this exception.