Question

我正在尝试在Windows上设置测试应用程序，以通过“myapp：//website.com”样式的URI启动。大多数情况下，我基于这样的教程：

http://msdn.microsoft.com/en-us/library/ie/aa767914(v=vs.85).aspx

虽然我在HKEY_CLASSES_ROOT内部进行了初始设置，但新约束是在不需要管理员访问权限的情况下进行安装。因此，我删除了CLASSES_ROOT中的所有更改，并决定在HKEY_CURRENT_USER / Software / Classes / myapp中重试注册表添加，而不是使用HKEY_CURRENT_USER分支。

这似乎被浏览器检测到，并显示其确认对话框。但是，他们从未实际运行该应用程序。 Internet Explorer提供了最有用的错误消息，其中有一个对话框“无法为{uri}打开此帮助应用程序。此地址中指定的协议无效。请确保地址正确，然后重试。

我是否缺少非管理员设置的注册表部分？这是我的更改导出为.reg。（ Dashes审查我的用户名）。添加了EditFlags作为猜测，但没有它也没有。

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Classes\myapp]
"URL Protocol"=""
@="URL:David Protocol"
"EditFlags"=dword:02000000

[HKEY_CURRENT_USER\Software\Classes\myapp\DefaultIcon]
@="C:\\Users\\------\\AppData\\Roaming\\-----s Stuffs\\URISchemeTest.exe,1"

[HKEY_CURRENT_USER\Software\Classes\myapp\shell]

[HKEY_CURRENT_USER\Software\Classes\myapp\shell\open]

[HKEY_CURRENT_USER\Software\Classes\myapp\shell\open\command]
@="\"C:\\Users\\-------\\AppData\\Roaming\\------s Stuffs\\URISchemeText.exe\" \"%1\""

Answer 1

既然我有这个工作，我不能完全确定导致问题的是什么，但我至少可以说明我尝试做的事情有多么不同，希望这有助于未来的研究人员。 / p>

% - 路径声明可能不支持签名目录访问器。如果是，则可能需要以某种方式编码。降低在问题中链接的文章中，它提到了Internet Explorer如何解码某些URL参数，但其他浏览器可能不会。无论哪种方式，如果您一直将命令行指定为“％APPDATA％/ MyProgram.exe”，从“C：/”开始可能更可靠，直到您可以解决该问题。

编辑：我刚注意到的另一件事，如果我的问题中的粘贴是正确的：我的工作版本的注册表更改将根的默认密钥设置为“URI：David Protocol”。注意“URI”，而不是“URL”。错误命名（很容易将其他值声明为“URL协议”）可能会破坏最终的效果。

虽然您可能不必指定DefaultIcon，但您可能需要注意不要引用无效的。为了安全起见，我将我设置为专门指向.ico文件，而不是“.exe，1”

正如其他一些评论者提到的那样，我认为EditFlags不是真的必要，也可能没有关系。

对这个附近高度投票的答案的警示性反驳，但是：这个。工作。不需要UAC访问。从我的研究开始，我个人会相信一个解释，如果没有UAC管理员提示等等，它太冒险了。但是，我花时间测试它，并且可以用一个设置自己的按钮编写一个简单的程序在HKCU / Software / Classes下，浏览器可以访问。然后我从一个从未参与我的任何研究（干净环境）的开发人员的计算机上测试它，并且没有任何管理员提示，它工作正常。（显然，此程序只能由当前用户访问）

（为方便阅读，提醒：HKCU = HKEY_CURRENT_USER.HKCR = HKEY_CLASSES_ROOT.HKLM = HKEY_LOCAL_MACHINE）

任何可以写入用户的HKCU注册表的内容都已经具有非管理二进制访问权限。此外，所有浏览器都会在打开程序之前显示有关启动程序的警告消息（完全可以理解，因为它是本地代码）。其中一些甚至提供了您将要启动的可执行文件的完整文件夹路径。

我知道教程说把钥匙放在HKCR;而且这已知来自HKLM / Software。但是，值得一读的是这里：

http://msdn.microsoft.com/en-us/library/windows/desktop/ms724475(v=vs.85).aspx

此密钥部分源自HKCU配置单元 - 事实上，用户的设置将覆盖本地计算机设置。没有具体说明HKLM会在HKCR内显示此类钥匙时会超越HKCU。

Answer 2

你不能忽视MSDN文章告诉你的内容，在HKCR密钥中注册协议处理程序是一项艰难的要求。

有一个很好的理由，在文章中也明确指出，协议处理程序是危险的。它们允许任意网页在您的计算机上启动程序。它们甚至可以在Store应用程序中运行，这是一个高度安全的运行时环境的另一个例子，它在沙箱中运行代码，可以阻止危险的操作。

记录HKCR并没有帮助解决这个问题，它适用于具有16位代码的appcompat，现在是别名。显示HKCU和HKLM键的合并视图。 HKLM键与HKCU键不同，写入键值需要提升。只有可以获取提升的安全性令牌的程序才能创建新值或更改它们，通常通过UAC提示获取。 HKCU密钥的问题在于任何程序都可以在没有高程的情况下写入密钥。如果协议处理程序可以在HKCU密钥中注册，那么会打开安全漏洞。所以这不起作用，urlmon根本不会查看HKCU键来查找协议处理程序。

Answer 3

你的协议名称中确实有空格吗？ “大卫协议”？删除空格......

添加到HKCU / Software / Classes后无法通过URI启动Windows程序

3 个答案: