Hello everyone, we are migrating from old traccar version to the latest one (5.7). In older versions there was an option to set a "token" for users, so you could use it as an alternative authentication method to Basic Auth (user & password).
This was super helpful for us because we could impersonate as any user to have access to their account (e.g. give support ,etc).
In the new traccar version we see this is not possible anymore (at least not in the same way) because the token architecture was refactored.
Tokens have to be requested now through the API or the UI and tokens have expiration.
So there's a couple of flaws on the design as I see it, or maybe it is just ignorance from my side, but:
1.- You can request tokens and define their expiration, however, tokens don't get stored, so there's no way to force to revoke/expire a token. This is a security risk because what happens if the token gets compromissed? you're pretty much f**ed up. Token doesn't even expires when you change your password. So as of now, due to the design, it seems that a good practice would be to consider this tokens as "access tokens" and make them not have an expiration date more than 24 hrs. If this is the case at leats it should be documented somewhere in the API or the docs so devs can take that in consideration when designing their architecture.
2.- There's an alternative way to impersonate, and this is only found if you explore enough the web app to realize there's a "login" icon under the users module where, if you are an admin, you can login (impersonate) as any user just by clicking on it. This, again, is not documented anywhere (so theres a flaw right there). But more importan than that, is that, once you impersonate as a user, you're automatically logged out from the admin user, so there's no comming back, there's no way to go back again as admin. This is another flaw, as it block you from designing a propper impersonation system where an admin should be able to: 1) impersonate as one user, do some stuff and then 2) go back as admin, and impersonate again as another user.
So for now apparently the only way to do that is to logout and login again as admin and impersonate again.
Can anyone clarify if I'm right? and that is the expected behaviour by design? or is any API endpoint or feature I'm missing? thank you.
the password and the admin user are saved in the browser, that is to say, leaving the user's account and coming back is only 2 clicks, it would not make sense to put a button to return since you are sure that you can see the area in this way , page, panel EXACTLY as the user you entered as would see it
and if there is documentation of the tocken and everything mentioned online, it is only a matter of searching a bit
Hello everyone, we are migrating from old traccar version to the latest one (5.7). In older versions there was an option to set a "token" for users, so you could use it as an alternative authentication method to Basic Auth (user & password).
This was super helpful for us because we could impersonate as any user to have access to their account (e.g. give support ,etc).
In the new traccar version we see this is not possible anymore (at least not in the same way) because the token architecture was refactored.
Tokens have to be requested now through the API or the UI and tokens have expiration.
So there's a couple of flaws on the design as I see it, or maybe it is just ignorance from my side, but:
1.- You can request tokens and define their expiration, however, tokens don't get stored, so there's no way to force to revoke/expire a token. This is a security risk because what happens if the token gets compromissed? you're pretty much f**ed up. Token doesn't even expires when you change your password. So as of now, due to the design, it seems that a good practice would be to consider this tokens as "access tokens" and make them not have an expiration date more than 24 hrs. If this is the case at leats it should be documented somewhere in the API or the docs so devs can take that in consideration when designing their architecture.
2.- There's an alternative way to impersonate, and this is only found if you explore enough the web app to realize there's a "login" icon under the users module where, if you are an admin, you can login (impersonate) as any user just by clicking on it. This, again, is not documented anywhere (so theres a flaw right there). But more importan than that, is that, once you impersonate as a user, you're automatically logged out from the admin user, so there's no comming back, there's no way to go back again as admin. This is another flaw, as it block you from designing a propper impersonation system where an admin should be able to: 1) impersonate as one user, do some stuff and then 2) go back as admin, and impersonate again as another user.
So for now apparently the only way to do that is to logout and login again as admin and impersonate again.
Can anyone clarify if I'm right? and that is the expected behaviour by design? or is any API endpoint or feature I'm missing? thank you.