Fix admin issues

[gavinhenderson]

EyeCommander currently has to run as admin in order to work. This is a massive pain for our users and prevents lots of people from using it. FaceCommander must work in non admin mode.

Assigning to myself as I have to test it with AAC apps.

[gavinhenderson]

So unsurprisingly its complicated.

It looks like there is a general rule of, if you want keypresses to be detected in another app your script has to run with the same level of permissions.

I tested with Grid and it works when FaceCommander is the focused app, it sends keypresses to grid and it detects them. However, as soon as Grid or anything else is focused it ignore/doesnt get inputs from FaceCommander.

When you run FaceCommander as admin, it always works.

The easy solution is to force it to always run as admin, however that wont do as most people dont have admin rights to the machine to put in every time they want to open it.

We need to figure out how Grid works and do the same thing. It runs as admin, however you only need admin rights at install time not for subsequent opens. We need to mirror this behaviour.

[gavinhenderson]

It looks like Grid is maybe installing explicitly for all users on the machine. The screenshot above shows an entry for my user on Grid.

When i manually add that local permission to FaceCommander it still doesn't send keypresses through to Grid from the background

[willwade]

So you are right.. A quick hack for our work is to

Try adding 'uac_admin=True,' in the build spec file here

https://github.com/AceCentre/FaceCommander/blob/main/build.spec

i.e.

exe_app = EXE(
    pyz_app,
    app.scripts,
    [],
    exclude_binaries=True,
    name='grimassist',
    debug=False,
    bootloader_ignore_signals=False,
    strip=False,
    upx=True,
    console=False,
    disable_windowed_traceback=False,
    argv_emulation=False,
    target_arch=None,
    icon='assets/images/icon.ico',
    codesign_identity=None, 
    uac_admin=True
    entitlements_file=None,
)

But its not quite nice. NB: I did a ton of work refactoring the upstram code to run in modern Windows locations like %LOCALAPPDATA% as, well, you know.. Security and all that. So I dont know what adding uac_admin will now do..

[sjjhsjjh]

Hi, I'm just testing the name change in the installer and noticed this message.

Warning: The [Setup] section directive "PrivilegesRequired" is set to "admin" but per-user areas (userstartup) are used by the script. Regardless of the version of Windows, if the installation is running in administrative install mode then you should be careful about making any per-user area changes: such changes may not achieve what you are intending. See the "UsedUserAreasWarning" topic in help file for more information.

[willwade]

@gavinhenderson - I think there is something going on with Windows when running apps in some kind of "Full-Screen" view. We had this problem in relaykeys too. Basically Grid/Communicator and all others seem to work OK/(Fine?) when they are a windowed app - but as soon as it goes fullscreen it causes headaches. Its defo funky.

[gavinhenderson]

I think there is something going on with Windows when running apps in some kind of "Full-Screen" view. We had this problem in relaykeys too. Basically Grid/Communicator and all others seem to work OK/(Fine?) when they are a windowed app - but as soon as it goes fullscreen it causes headaches. Its defo funky.

Hmmm I think rather than full screen it might be the difference between 'focused' and 'non-focused'. (full screen does effect this).

From my experience if FaceCommander is focused and grid is in the background then it 'works' as you would expect. However, you obviously want grid to be focused and thats when it stops working. You can literally click between the windows and it will stop working depending on which window is focused.

As you say though, when you full screen grid then its 'focused' so will break.

I do think there is a way to override this behaviour though and make it always work

[sjjhsjjh]

Hey I found this. https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-securityoverview The privilege documented there, UIAccess, looks promising. It's a lower privilege than admin.

However, this is called out on the page.

Note

Applications developed for the new Windows UI do not have UIAccess as an available option.

I don't know if that applies to FaceCommander.

[gavinhenderson]

Note from Smartbox:

I asked the devs about your admin rights issue for Face Commander. Apparently if you do this then you only need admin rights for installation and not at runtime: Grid uses an app.manifest manifest file to allow access to processes run as Admin: as the comment says EyeCommander would have to be signed and run from program files.

[gavinhenderson]

So in my debugging I have managed to get it working!

The trick was (as @sjjhsjjh suggested), use the uiAccess flag. The thing is, the uiAccess flag is protected to only work for signed executables. So we have to sign both the base executable and the installer.

Now, this is a pain because the signing process relies on a hardware key, so its hard to automate this process. Its also a pain because we need to sign in the middle of the build process (before the installer build). So basically it just ruins all automation.

So im going to look into somehow automating the process, but looks like it might have to be manual build process :(

[sjjhsjjh]

Hi Gavin, Good news and bad news it sounds like. Is there any way to bypass the signing requirement for developers working on the application? Maybe if the app is in foreground and had focus then it doesn't need to be signed.

[gavinhenderson]

Yeah for developers the solution is to 'right click and open as admin' that will fix all the issues. Or keep it in the foreground when you are testing as you suggest.

I think I have a plan to try and automate the build. We have a physical server with our key plugged in, so i am going to try and set that machine up as a 'github actions runner' and see if we can run the build on that machine. Never sone that before so will see how that goes.

[gavinhenderson]

This has now been resolved.

A brief summary is we now apply the UiAccess flag to our application giving it access to more of the system. However, for this to work the application + installer need to be signed. So now we have an automated process for that, which is documented.