Admin password change of other users still requires the old password parameter (doesn't matter if it's correct or not)? about apiko

[ilabacheuski]

In the core.js it is written that this parameter is required. Apiko checks all requirements before doing anything. That's why it sends "code": 1.
In other hand we have passwordchange.js which checks if the current session user is admin, or access with a secret key. If so - no need for old password. And gibberish data is just skipped and not used at all.

So. If we have admin session (after login), or access using secret key - we don't use "old"" 'oldPasswordExample', but still "old" parameter is required because it's written so in core.js

This little bit confusing behavior could be change in future to allow admin user skip checking required parameters, or to separate api for normal and admin users.

[alewiahmed]

So, you need current password for a normal user, but for admin there is no extra security to check if the user changing the password is the owner of the admin account.

The purpose of the current password is if someone found your account open, he couldn't lock you out of your account by changing the password because the system asks for the current password. In our case, if someone found the admin account open, that someone can change the password of the admin & everybody else without any hassle, because the system doesn't require the current password of the admin. could you explain that?

[ilabacheuski]

Do you mean the user can change admin password?
Because now it should be like only admin can change any user password skipping comparing old password.
The current session holds information of the current user and his role. The session is filled with user data while logging in.
Skipping password checks is only possible in 2 situations:

1. If the session holds information of the user role and one of roles is 'admin'
2. You access with apiko secret key which should be hold in server only private space in 'apiko.json' file.

I had one weird situation for common, not admin user. The session holded information from previous logged in user. But I couldn't repeat this strange behaviour and thought it's just because of some problem in my pc only. (I checked out branches and might be not all data was saved.)

In conclusion

Situation	Apiko compare password	Apiko doesn't compare password	Note
Any access with secret key	NO	YES	User is like admin
Common user try to change his own password	YES	NO	Access is done with token after logging in only
Common user try to change not his own password	NO	-	Request rejected before apiko try to change password
Admin user try to change his or not his password	NO	YES	Admin access with token. Checking if the current user is admin is done by checking server-side session. If user role includes 'admin' = user is admin

If session holds open - apiko don't check password at all. Might be it's a good idea to check admins password. But If you have admin token your system already is in dangerous. You cannot ask for password all the way you use api. For this we have token which is valid for session.
If you are admin and you have session token - you already were compared your password. Making another compare? Could be done but what is a reason? UI could ask twice for example.
The situation when admin didn't log out is bad. Actually I didn't check how the user can log out.

[ilabacheuski]

The key 'old' will be changed to 'current' and we can check admin's password for security reason