RS_CORR_INSERT: bypass DEVELOPER_CHECK, possible?

[alejandro_bindi]

I'm developing a program which updates ddic domains (using DDIF* function modules), and previously has to generate the transport request, for which I'm using function module RS_CORR_INSERT.

It works great except if the user has no developer key (internally it's calling function module DEVELOPER_CHECK).

Is there a way to bypass this check? Since the program is precisely to be used by non-developers, this check completely defeats its purpose.

I tried forcing a different user to RS_CORR_INSERT by parameter AUTHOR but it's not enough (DEVELOPER_CHECK uses sy-uname).

Thanks!

[alejandro_bindi]

Thanks for the Explanation!

Neal

[Former Member]

Do you really want someone who doesn't know what damage that he might be doing, altering Domains?

Neal

[Former Member]

One idea that comes to mind would be creating a local RFC destination with a specified user that does have a developer key and running all FMs that change or create repository objects in this RFC destination. I think you would have problems bypassing this check any other way than giving a user with a development key (one way or another) as although the developer keys are stored in the database I believe the checks on developer key are programmed in the system kernel and not in ABAP. I would also agree with Neal that allowing users who are not trusted with a developer key the ability to change domains sounds high risk.

[alejandro_bindi]

Ok, I feel I should clarify a bit since I would think the same upon this request.

First, the program allows only to modify fixed values, not other attributes such as lenght or type.

This reduces tremendously the risks, narrowing them to the deletion or description change of values already used in table records or referenced to in programs, and this is clearfully explained upon running the program with a big warning.

Secondly, the use case is for a specific standard domain, which was modified (repaired) years ago to add fixed values, and is used almost as a table nowadays. I receive monthly requests to add or change values on it, so I though why the heck couldn't the functional analyst update the values himself as he does for regular customizing tables (that's another risk reducer, not ANY user would run the program). It won't even reach quality client, it is to be used in dev only and domain changes to be transported as usual.

I could even restrict the program to only that specific domain, or disallow deletion of values, but I wanted to keep it pretty generic should a similar need arise later.

Now, to the problem at hand, the only workaround I thought of so far is exactly the same you suggest Jamie (create and use an RFC enabled wrapper of RS_CORR_INSERT with my username entered in the destination), and it seems I'll end up trying just that. Any other ideas are welcomed.

I could always program an enhancement at the beginning of DEVELOPER_CHECK to leave if my program is in the call stack, but that seems a bit extreme

Regards

[Former Member]

I think that Jamie's RFC idea should work well for you.  I've used the concept before on numerous occasions.

Neal

[alejandro_bindi]

It does work, I'm just testing it right now. But I really don't like this solution.

- I either have to let my password fixed in the destination (and keep it synched on every monthly change), or input it manually each time the program needs to be used on another machine.

- The field "modified by" in the domain is the real one, but my user is still the transport request owner.

This generates dependency on me, which I'm trying precisely to avoid. So I'm all ears to other suggestions. For now, I think i'll discard the idea (at least I got to explore the   STC1_FULLSCREEN_TABLE_CONTROL module capabilities a bit )

[Former Member]

You can store it encrypted in the DB and decrypt it.  You can define your own decryption routine and there by keep it from all but other programmers.  Again, that's what I did.  Except I used an artificial User ID.

Neal

[alejandro_bindi]

Neal, I'm not sure I'm getting your suggestion.

My options are either to complete my user (or anyone with a developer key) in the Logon & Security tab inside SM59, or leave it blank. How would I store it separately and then use it for connecting to the destination?

[Former Member]

Your are writing code inside of SAP, right?  That code can then call an RFC'able FM.  You call it remotely (ie sending it into the background as a new process), thus having to provide login.  This is where the storage and decryption come in.  I guess that some of this is unknown to you.  Please let me know which, so I can explain further.

Neal

[alejandro_bindi]

Neal, I've used RFC lots of times. But I don't know any other way of storing login data for RFC other than the standard, that is the Logon & Security tab inside SM59 (lower part), where you can specify a fixed user and password. Where else would you store it and how would you use it when calling the RFC with DESTINATION?

Besides, I still would have to use a separate developer user for this, so what would be the benefit comparing with the standard option?

[Former Member]

In response to your first problem if you have sufficent access you could  create a system user whose password was set to never expire and assign a developer key to them (unless there is some control that doesn't allow assigning devloper keys to system user that I am not aware of). Then you could use this user in your RFC destination.

In response to your second problem given how easy it is to change the owner of a transport in se01 i would have thought that it would be possible to change this programatically. Have you tried just updating field AS4USER of table e070 with the user who is running the program after the transport has been created?

[Former Member]

Another thought, personally I don't think your suggestion about checking the call stack and exiting if your program is present is too extreme provided you test it thourghly. At least not much more extreme than managing a system user with deloper key in a dedicated RFC destination. However, I remember looking at how developer keys were managed a few years ago and coming to the conclusion that there were controls programed at the kernel level - that is if you bypass DEVELOPER_CHECK there will be a system kerenl call needed to create the object that will fail if the user doesn't have a developer key. It was a cursory investigation I did three years ago so I could well be  wrong but I would be intrested to know the results if this is a route you decide follow.

[alejandro_bindi]

Well I did some more tests:

- The request's owner change wouldn't be a problem, function module TRINT_CHANGE_USERNAME can be used for that (it's the same SE10 uses).

- Bypassing DEVELOPER_CHECK by debug is enough, there are no further kernel checks (actually, the system calls are inside this f.m. itself).

Anyway, I just found my workaround: function group SCWG (those modules are precisely used to bypass developer checks when applying notes). No need for RFC nor "extreme" enhancement with those ones

Thanks to both!

[Former Member]

Thanks for the Explanation!

Neal