CatalystCode / windows-registry-node

Read and Write to the Windows registry in-process from Node.js. Easily set application file associations and other goodies.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Failed to open key error: undefined

LeetCodes opened this issue · comments

hi, i tried to run the test code for the file handler and it gave me an error, this is the only function i need, can you please help?

var utils = require('windows-registry').utils;
utils.associateExeForFile('myTestHandler', 'A test handler for unit tests', 'C:\\path\\to\\icon', 'C:\\Program Files\\nodejs\\node.exe %1', '.zzz');

PS C:\mystuff\code\regedit> node .\mozilla-handler.js
PHKEY LENGTH: 8

C:\mystuff\code\regedit\node_modules\windows-registry\lib\registry.js:129
            throw 'Failed to open key error: ' + error[result];
            ^
Failed to open key error: undefined

i needed to elevate privilege with the other code, sorry, closing

var utils = require('windows-registry').utils;
utils.elevate('C:\\Program Files\\nodejs\\node.exe', 'index.js', function (err, result){console.log(result);});

I have the same problem. With elevate() it works for me like for you, too, but I don't understand why I need admin rights to set file association.

The code currently writes to HKEY_CLASSES_ROOT. If you try to create a new key there then it's created in HKLM, which needs elevated permissions:

If you write keys to a key under HKEY_CLASSES_ROOT, the system stores the information under HKEY_LOCAL_MACHINE\Software\Classes. If you write values to a key under HKEY_CLASSES_ROOT, and the key already exists under HKEY_CURRENT_USER\Software\Classes, the system will store the information there instead of under HKEY_LOCAL_MACHINE\Software\Classes.

You could change the code to explicitly write to HKEY_CURRENT_USER\Software\Classes if you only want to associate it for the current user.

Thanks! Your help is very useful. Changing HKEY_CLASSES_ROOT to HKEY_CURRENT_USER in lib/tools.js does the trick. You may consider allowing an API option for that in future versions.

@kovzol its because file association could be used against a user maliciously, for example, if you ran something that copied a malicious application(to a directory in a user's home folder, to avoid elevating priv's for disk writing when they ran a downloaded app and had higher suspicion), and then set mp3's to open with that, the user could get tricked into allowing elevated privileges(thinking their mp3 software updated or something) not knowing they were actually running something else, or you could set it so that images open with an application which uploads to a remote server and then displays locally using the original associated application

@LeetCodes Thanks for the explanation, but I don't think this is a good reason to completely disallow creating file associations without admin rights. First of all, it can be done programmatically (I did it directly by copying the code from utils.js), also with other means (from Windows API or e.g. NSIS also allows to do that).
On the other hand, elevate() is not an option for me because I need to use file association setting in an installer and I cannot start another program that performs the setting when it is launched with admininistrator rights. (I have only one bundle that should do all installation steps on its own.) It would be OK to ask for admin rights inside the installer and perform file association setting without calling an external .exe, but I am unsure if it is possible.