Feature request: clientPreAuthorization or clientOnConnection

Submitted by amatveev on #1

It would be very useful to have an ability to give user permissions even before it connects to USB device:

For example:
- show only permitted USB devices (this is the most desired option for me)
- restrict user rights (disable all Auto-Use options, Properties, Rename, etc)
- become an admin without using /admin key (or restrict admin access even the user specifies /admin key)

It looks like a user management functionality. Very strange that such nice peace of software doesn't have it already.

Submitted by Michael on Thu, 2015/10/15 - 22:25

#2

You can hide any menu items you want in the client by editing the client vhui.ini file and changing the line HideMenuItems. List the exact (case senstive) names of the menu items you want to hide.

e.g in the vhui.ini
[General]
...
HideMenuItems=Start minimized,System Messages
...

Ive tended to steer clear up to now of implementing full device/user/rights management because I dont get many requests for this, and its adds unnecessary complexity for most users, and administration can get very complicated very quickly. ill see what i can come up with regarding the password protection for a device. I think i can create a simple password callback mechanism, i will work on this and let you know.

Submitted by amatveev on Thu, 2015/10/15 - 22:35

#3

Michael, thanks for answer

Well, hiding menu option it's quite useful but what to do with hiding (filtering) USB devices user can see in the client (in case when there lots of USB devices connected and user has an access to only one?

+1 Vote to full user management on server side :)

Submitted by amatveev on Thu, 2015/10/15 - 23:46

#4

[General]
AdminMode=0
HideMenuItems=Auto-Use Device,Auto-Use Port,Auto-Use Device/Port,Rename...,Properties,Auto-Find Hubs,Ignore...

Restarted the client - all the menu items on there place(

Submitted by Michael on Fri, 2015/10/16 - 10:03

#5

I did this:

1. Stop and exit the client
2. I copied that exact line as you specified into my c:\Users\Michael\AppData\Roaming\vhui.ini
3. I started the client, and now i dont see any of those menu items, in the device menu i just see "Use" and "Custom Event Handler..."

So its definately working, you probably edited the wrong file or changed it while the client was running.

Submitted by amatveev on Fri, 2015/10/16 - 20:10

#6

Right, it works as expected

(it started the client with -c parameter and relative path - see my another thread/bug report)

Submitted by Michael on Sat, 2015/10/17 - 09:01

#7

I checked and implementing filtering per user is too complicated a change at this point, its probably useful but it will be towards the bottom of my todo list...

Submitted by toxot on Thu, 2017/04/13 - 06:40

#8

Michael, maybe you can implement same funcionality that we already have (clientAuthorization) but for renaming device, it doesnt add complexity but it can really overclose this question. Is it possible?

Submitted by Michael on Fri, 2017/04/14 - 07:35

#9

Yes i can add that in the next build...

Submitted by slakwik on Wed, 2017/04/26 - 17:22

#10

- show only permitted USB devices (this is the most desired option for me)
Yes, this option is the most desired!

Submitted by Michael on Thu, 2017/04/27 - 11:29

#11

Showing only the permitted devices cannot be implemented easily so it wont be added for the time being...

Submitted by Michael on Thu, 2017/04/27 - 14:26

#12

@toxot

OK if you download the virtualhere server 3.3.0 it contains support to selectively deny the device rename feature. Just return 1 to deny the rename request.

E.g use it like this:

config.ini 

...
...
onChangeNickname=/home/pi/onChangeNickname.sh "$VENDOR_ID$" "$PRODUCT_ID$" "$DEVPATH$" "$NICKNAME$" "$NEW_NICKNAME$"

onChangeNickname.sh 

#!/bin/sh
#  "$VENDOR_ID$" "$PRODUCT_ID$" "$DEVPATH$" "$NICKNAME" "$NEW_NICKNAME$"

logger "\"$1\"" "\"$2\"" "\"$3\"" "\"$4\"" "\"$5\""

# OK to change nickname
# exit 0 (or leave out exit entirely as the default is 0)

# NOT ALLOWED TO CHANGE NICKNAME
# exit 1

Submitted by slakwik on Thu, 2017/04/27 - 18:49

#13

2Michael
>>>#11 Showing only the permitted devices cannot be implemented easily so it wont be added for the time being...
thanks for reply
I'll be waiting for this feature.

Submitted by toxot on Fri, 2017/04/28 - 06:39

#14

@Michael,
Hi, ive checked and it works! I used client only for connection, not for managment, so my opinion that users (client side) should be readonly in most of cases (if its tunable its really awesome), for stable operating of system with multi-clients/customers etc.

Submitted by Michael on Fri, 2017/04/28 - 10:42

#15

Ive avoided having too much server admin in the client but i will add more in the future so that the server is more configurable from the client without having to edit config.ini files etc.

Submitted by toxot on Fri, 2018/02/02 - 01:57

#16

Hi Michael, do we have any chance to get this functionality "show only permitted USB devices" - it can be realized like onClientAuth, because it really can be tricky when you have more that 30-40 usb devices per server
Thanks

Submitted by houxn on Tue, 2018/07/03 - 19:13

#17

I also want this feature：show only permitted USB devices (this is the most desired option for me too)

Submitted by lordgaga on Sun, 2022/07/17 - 18:50

#18

Will the feature "show only permitted USB devices" be added in the future?

Submitted by Michael on Sun, 2022/07/17 - 19:28

#19

No, that wont be added

Submitted by omarb1989 on Sun, 2022/08/28 - 22:56

#20

Hi, I fully understand why you won't add this feature, cus this depends on user custmization and scripting, that's why I'm here to ask you about adding alternative feature that would make sense. It seams quite good to let server send back dialog messages about the reason behind unauthorization and limitation of using a device. so the client would be aware of it, such as, "client reached expiration date of using this device", "client can't use more than one device at the same time" , hence the client would react after figuring out the reason.
Thanks!