Skip to Content
avatar image
Former Member

Change own Password via Coding on a remote System (tRFC)


following up in this old thread I found (

), I would like to know if I can gain some more insight with my Problem:

We have a 2-Server Application, with a Frontend serving a UI5 Website and providing oData Services for the customer, and a Backend keeping all the data/logic and providing WebDynpro for the employees to interact with the data/customers.

When a customer forgets his/her Password an Initial Password is sent out via E-Mail. After that the Website lets the user provide his/her new Password after loggin in with the Initial one.

Changing the Password is done via an Update-only oData-service. The user is logged into the frontend, but the call is processed in the BL on the backend side. changing the password on the frontend is done by an tRFC call to the


function. after that we try to change the password in the current System, the backend.

Here is where the Problem occurs: The Password is valid, the user is acting for itself, but the change ist not allowed. As I understand the user is not logged in in the way, that he/she used the Initial Password before, since the tRFC call does not check the Password.

Does the User have to login before at the backend since the call via tRFC does not count?

Is there a way to simulate the users Login in the backend (Login in the frontend is active, but the backend is reached via tRFC).

To sum up the activity here:

* User logs in with Initial Passwort to the frontend (UI5 App)

* Password Change via oData calls FB in the Backend via tRFC as the registered user

* FB changes Password via tRFC in the Frontend (success)

* FB tries to change the local Password (change_not_allowed, due to missing login?)

Both Systems have the same Initial Password for the user beforehand.

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Best Answer
    avatar image
    Former Member
    Oct 04, 2017 at 09:29 AM

    We solved this issue by deactivating the passwords of the candidates in the backend, so no Passwords would be running into invalidation Problems if not changed after time. In the end the users did not need a password in that System anyway, so security is formal up, although this was no issue in the former setting.

    Add comment
    10|10000 characters needed characters exceeded