Skip to main content

  We are currently changing user password from the PORTAL via the API ENDPOINT using:
<update_person>
<person>
<person_id>****</person_id>
<password>*******</password>
<insert_update />
</person>
<authentication>
<session_info>
<token_id>xxxxxxxxxxxxxxxxxxx</token_id>
<session_id>xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</session_id>
</session_info>
</authentication>
</update_person>

This is working fine - means it is changing the password - but is bypassing especially the system check if the password was reused:
PASSWORD_REUSE_LOCK_DAYS 365

From "PERSON" screen - this check is done and works fine.
Via the API endpoint we are unable to trigger the same checks as done from the screen.

Testing with FSM 6.5 and 6.1.

 

Any idea how to ensure the password is checked as from log-in in Smartclient?

 

Thanks!

Hi,

As you are using the Restful gateway, any metadata requirements for FSM will be adhered to when creating/updating records as this will relate to the SQL tables.

Anything in app params such as password complexity and password last used will be ignored as the Restful Gateway will not be able to read these configurations.

Kind regards,

Paul

Dear Paul

Thank you for the clarification. This was also our presumption.

Anyhow: an API must keep the system integrity, there should not be a different behavior as from Screen. How to link the API call with the system parameters? Any ideas or recommendations?

Kind Regards

Monica

 

Hi,

I don’t believe there is a way to link the ResfulAPI call with the FSM system parameters.

However, there is a password_history table that can be referenced by the API call and this table has a reuse_dt column that lists the earliest date that the password can be re-used.

Your API can be use this table as validation before updating the password in the person table.

Kind regards,

Paul

Hi Paul

We are checking this now. Coming back with the results soon.

Thank you very much for your support so far

Kind Regards

Monica

For documentation purpose, might be that also others will encounter the same issue: the password is saved very good secured, with changeable key. so if we use password A, on SQL level is saved as A_encrypted_version1. Using again A later, we have on SQL level A_encrypted_version2, so way to match and check the reuse_dt since we can’t see it is password A the second time. So from mobile or others, using API the system integrity is not covered.

Opened a Case by IFS and awaiting reply. Support was able to reproduce.

Reply


Terms & ConditionsCookie settings