I thought the rest-api policy should be checked for the account which was used to access rest api, but in fact the api policy required(no need rest-api).
So when to use the rest-api policy? Thank you.
Good question. Doc don’t say anything about rest-api policy:
https://help.mikrotik.com/docs/display/ROS/User#User-UserGroups
Yes, I don’t see any description about “rest-api” policy.
The other problem:
I see that connect via REST API is lack of changed policy.
Steps to check:
- Create user for API and its group with full permission (or must have read+sensitive permission).
- Connect to device via REST API and do something like listing users in user manager and see that sensitive data such as password must be shown.
- See System > Users > Active Users and you will see that “API” user still exists.
- Change group policy for this API user to not showing sensitive data or just no policy at all and apply.
- Try to connect via REST API again. You can still see users in user manager with sensitive data (password). This is the problem! This user (API) should has no permission to list anything.
- Check again like step 3 and you will see that that user (API) still active and it seems there is no way to kick it out or force log out. You have to wait for a while until it is automatically log out.
RouterOs v7.11
It’s actually similar issue as this:
http://forum.mikrotik.com/t/security-issue-changing-rights-disable-delete-the-users-has-no-effect-on-already-logged-in-users/168574/1
Since there is NO “sessions” in REST (e.g. auth is provided on EACH call) – agree it odd to have the active user hang around.
My question is how long does the “Active User” stick around? REST timeout is in 60 seconds for any operation, so perhaps they get flushed then. My thought is REST may internally cache some creds need, to avoid re-auth with OS – but even then, they should still be cleaned up at some point hopefully before a reboot…
I was curious. It caches the creds for 10 minutes.
Didn’t test. But I’d bet if you make another REST within 10 minutes, the session will keep using the old permissions.
The REST API seem to just wrap the older API (https://help.mikrotik.com/docs/display/ROS/API), so I’m think it opens a API session internal to the web server and leaves it open in expectation of another call – to avoid having to create a session to RouterOS API to for subsequent REST operations.
While similar to the delete/disable users does not effect logged in user issue in thread linked above. It’s slightly worse since a REST client could potentially poll continuously (unlike a user who has to keep winbox/etc open) – so REST theoretically never hit the 10 minute inactivity timeout if a server was polling RouterOS using REST.
edit: it does essentially re-check policy/user status, every 10 minutes.
I’d recommend you file an issue at help.mikrotik.com on this one. 10 minutes seems a long time to keep creds cached…
For me, it takes time about 1 minute or more but I’m sure it less than 10 minutes.
It’s just like this…
If you make a connection, the API user is active and start to countdown after finish the task.
If you make a connection again, the API start new countdown.. until no connection to Mikrotik at all then API user will be removed from active.
Yeah I was guessing 1 minute… but seems it’s 10 minutes off before cleared (and thus allow re-checking of access/policy).
It worse than just policy, since even if you disable a user… you can still make REST calls if within the 10 minute cache window. This part is pretty unexpected (even if explainable).
To be clear, I did confirm it does re-check creds after 10 minutes from the first REST call that created the active user. Why your times are appear variable.
So if you look in “Active Users” at the “At” time, it will recheck +10 minutes from that. Usage does not change the time – it from the first REST call without an existing active user.
Yes, you are correct. It spend 10 minutes to make active user disappear.
