Hello Michael. Can you please update the correspoding topic for the auth script with the new parameter that can be passed? I suppose it is something like $USERNAME$ but I need your confirmation, in order to update my scripts.
When the authorization dialog appears in the client when they try to use a device, there is a box for username and password. The username is actually the client id passed to the script.
Oh ok. So what about all other events that use the ClientID parameter? The username is passed to every other event, automatically, as the one that the user input at the authorization script?
I have also noticed that if the password is saved for a device with by a previous version of the client, it still passes the old ClientID based on the machine name and user name.
That is a good point. ( I was reluctant to add this change because there are side-effect issues like this but i kept getting requests for it.)
Anyway it works like this:
1. It is backwards compatible, if you saved the password in a previous version of the client it will work like before and pass the old clientid.
2. If you use an older server with a new client or vice versa , the client id defaults to the old method client id
3. If you dont want to specify the client id it always defaults to the os client id (as before) in the "username/password" device authorization dialog and will pre-populate it.
4. The clientid/parameter is not universal. Its only related to the clientAuthorize/deauthorize events, it wont be carried through to other events.
Essentially, i think the use case is that a set of users in an office are using devices, and some need to use particular devices and dont normally have permission do to so, so an admin walks over and logs a user in to a device by using the their username/password just for that device.
The end result is that everything works as before except there is the option to use a device on behalf of another person on a case-by-case basis
.
Its still
$CLIENT_ID$When the authorization dialog appears in the client when they try to use a device, there is a box for username and password. The username is actually the client id passed to the script.
.
Oh ok. So what about all other events that use the ClientID parameter? The username is passed to every other event, automatically, as the one that the user input at the authorization script?
I have also noticed that if the password is saved for a device with by a previous version of the client, it still passes the old ClientID based on the machine name and user name.
.
That is a good point. ( I was reluctant to add this change because there are side-effect issues like this but i kept getting requests for it.)
Anyway it works like this:
1. It is backwards compatible, if you saved the password in a previous version of the client it will work like before and pass the old clientid.
2. If you use an older server with a new client or vice versa , the client id defaults to the old method client id
3. If you dont want to specify the client id it always defaults to the os client id (as before) in the "username/password" device authorization dialog and will pre-populate it.
4. The clientid/parameter is not universal. Its only related to the clientAuthorize/deauthorize events, it wont be carried through to other events.
Essentially, i think the use case is that a set of users in an office are using devices, and some need to use particular devices and dont normally have permission do to so, so an admin walks over and logs a user in to a device by using the their username/password just for that device.
The end result is that everything works as before except there is the option to use a device on behalf of another person on a case-by-case basis
.
Crystal clear.
Thanks