每台机器应用注册 [英] Per Machine App Registration
问题描述
我正在使用 WiX 构建一个安装程序，以按机器(而不是按用户)安装程序，它为他们提供了注册程序的选项.注册涉及输入用户名和组织(或接受 Windows 设置中的一些默认值)，并输入有效的注册密钥.验证注册密钥后，我在 HKEY_LOCAL_MACHINE 区域中使用此信息写入注册表设置.在 Windows 下，当运行 MSI 时，它会自动提示输入管理员密码，以便能够在 HKEY_LOCAL_MACHINE 中设置注册表值.到目前为止，生活是美好的......
I'm building an installer with WiX to install a program, per machine (not per user), and it gives them the option to register the program. Registration involves entering user name and organization (or accepting some defaults from Windows settings), and entering a valid registration key. When the registration key is validated, I write registry settings in the HKEY_LOCAL_MACHINE area with this information. Under Windows, when one runs the MSI, it prompts automatically for an admin password to be able to set registry values in HKEY_LOCAL_MACHINE. So far life is good...
我在 MSI 中加入了一个选项，让用户可以选择将注册推迟到以后的某个时间点.但是，如果用户是普通用户并且他们正在运行应用程序，如果我在应用程序中有一个对话框提示输入名称/组织/产品密钥，Windows 不会应用程序将信息写入 HKEY_LOCAL_MACHINE.因此，用户不能像 MSI 在提示输入管理员凭据后那样使用以普通用户身份运行的应用程序本身来执行每台计算机的注册.
I am including an option in the MSI to give the user the option to defer registration until a later point in time. However, if the user is a normal user and they are running the application, if I have a dialog in the app which prompts for name/org/product-key, Windows doesn't the app to write the information to HKEY_LOCAL_MACHINE. So a user cannot use the application itself, running as a normal user, to perform a registration per-machine as the MSI does after prompting for admin credentials.
我当时的想法是，对于安装后注册，要么 (a) 在应用程序中找到提升权限的方法，并提示输入管理员凭据，允许它编写 HEKY_LOCAL_MACHINE(这可能吗?)，(b) 在安装程序中包含一个选项，该选项在运行且应用程序已安装但未注册时，会像在正常安装期间一样进行注册.然后它会提示输入管理员凭据，生活又好起来了.或者，(c) 创建一个单独的 MSI 进行注册，将其与程序一起安装，并在用户在程序中选择注册..."命令时从程序中调用此 MSI.
My thought then was, for post-installation registration, to either (a) find a way from within the application to elevate privileges, with a prompt for admin credentials, allowing it to write HEKY_LOCAL_MACHINE (is this possible?), (b) include an option in the installer that, when run and the app is already installed and not registered, walks through the registration as it would during a normal install. It would then prompt for the admin credentials and life is good again. Alternatively, (c) create a separate MSI that just does registration, install this with the program, and call this MSI from the program when the user selects the "Register..." command in the program.
我之前没有见过任何应用程序使用这些方法中的任何一种，所以我不确定这两种方法是不是一个好方法.但是，除此之外，我不确定如何在安装后方便地允许用户进行每台机器的应用程序注册.理想情况下，我希望能够通过应用程序中的命令执行此操作，但重新运行安装 MSI 将是最低限度的可接受的.
I've not seen either of these approaches done by any applications before, so I'm not sure either is a good approach. Other than that, however, I'm not sure how, post-installation, I can conveniently allow the user to do a per-machine app registration. Ideally, I'd like to be able to do it from a command within the app, but re-running the installation MSI would be minimally acceptable.
这通常是如何完成的?还是每台机器的安装通常伴随着每台机器的注册?
How is this normally done? Or are per-machine installations even normally accompanied by per-machine registrations?
推荐答案
非常好的问题 - 我自己已经多次处理过这个问题.没有理想的解决方案，但有几种选择(正如您已经发现的那样).
Very good question - I have dealt with this issue many times myself. No ideal solutions, but several options (as you have already discovered).
在回答之前，我想指出我强烈反对在设置本身中进行过多的注册和配置.它很容易出错，并且由于多种原因在应用程序本身中做得更好:Windows 应用程序在线注册安装程序(推荐快速阅读 - 来自现实生活的花絮).
Before answering, I want to point out that I have a strong aversion against doing too much registration and configuration in the setup itself. It is error prone, and much better done in the application itself for a plethora of reasons: Installer with Online Registration for Windows Application (recommended quick read - tidbits from real life experience).
如您所知，一种选择是将许可证密钥和注册仅保留在 HKCU 中.这通常是可以接受的，除非您想在盒子上的许多用户之间共享许可证密钥.许可证密钥如果添加到 HKCU，通常也会随着用户漫游到其他计算机 - 这可能会有所帮助或可取.
As you already know, one option is to keep the license key and registration in HKCU only. This is often acceptable unless you want to share a license key between many users on the box. The license key, if added to HKCU, will also generally roam with the user to other computers - which can be helpful or desirable.
就个人而言，这是我更喜欢的选项:不在设置中注册任何内容，而是从应用程序写入 HKCU 或用户配置文件(如上面的链接中所述).如前所述，唯一的缺点是您无法将共享许可证密钥写入 HKLM，因此它适用于所有用户，而不仅仅是单个用户.这似乎是您所描述问题的核心.
Personally, this is the option I prefer: not registering anything in the setup, but writing to HKCU or the user-profile from the application (as explained in the link above as well). As stated, the only drawback is that you can't write a shared license key to HKLM so it applies to all users and not just a single user. This appears to be the core of the problem you are describing.
- 安装程序写入 HKLM:在安装过程中将 HKLM 许可证密钥(和注册)写入 HKLM，正如 Phil 使用默认 Windows Installer 属性在上面描述的那样(仅列出此作为一个选项 - 您已经知道).我认为这应该可以正常工作 - 但您的问题似乎是允许延迟注册".
- 自定义 HKLM ACL 权限:为了从您的非提升应用程序写入 HKLM，一种方法是使用您的设置应用自定义ACL 权限 到 HKLM 中您要从应用程序写入共享注册表项的位置.然后，您的应用程序可以随时在 HKLM 中自由更新此特定位置，而无需提升权限.您只需添加 ACL 用户"的写入权限.
- WiX 支持这一点，但我没有可用的示例，请查看 WiX 文档以获得许可.
- 通常不赞成使用自定义权限(我同意这不是理想的设计)，但它允许任何用户在安装后无需任何提升的情况下向 HKLM 添加许可证密钥(并且还允许任何用户删除它 - 这可能是个问题).
- 请参阅此处的第 14 节，了解为什么通常不建议使用自定义权限:如何避免我的 WiX/MSI 部署解决方案中的常见设计缺陷?
- 总而言之，我一般不建议设置自定义权限，但它肯定会起作用.当客户的要求是他们唯一会接受的时候，我自己就完成了.它会违反 Windows 应用程序的徽标要求，但应该没有以下选项 3 导致的安全问题严重.
- Setup writes HKLM: Write the HKLM license key (and registration) during the setup to HKLM as Phil has described above using the default Windows Installer properties (just listing this as an option - which you already know about). This should work OK in my opinion - but your issue seemed to be to allow the "deferred registration".
- Custom HKLM ACL permissioning: In order to write to HKLM from your non-elevated application, one way to do it is to use your setup to apply custom ACL permissions to the location in HKLM where you want to write the shared registry key from your application. Your application can then freely update this specific location in HKLM at any time without elevated rights. You simply add ACL write access for "Users".
- WiX supports this, but I don't have a sample for you available, please check the WiX documentation for permissioning.
- Using custom permissioning is generally frowned upon (and I agree it is not ideal design), but it allows any user to add a license key to HKLM without any elevation after the install (and also allows any users to delete it - which can be a problem).
- See section 14 here for a quick description of why custom permissioning is not generally recommended: How do I avoid common design flaws in my WiX / MSI deployment solution?
- In summary, I don't generally suggest setting custom permissions, but it will definitely work. I have done it myself when client requirements are such that this is the only thing they will accept. It will violate logo requirements for Windows applications, but it should be less serious than the security issues that result from option 3 below.
- 绝对不推荐这样做(但我们也想向人们展示什么是可能的).您的整个应用程序将始终以管理员权限运行，这根本不是一个好主意.
- 这样做会违反 Windows 应用程序徽标要求的关键部分，并且还会使您的应用程序容易受到恶意软件的攻击.</li>
- 一定要努力让您的用户了解这种简单修复"的后果.如果客户选择此选项，我会确保将所有责任推给客户 - 他们必须了解自己在做什么.
- 请注意，您应该能够使用此清单方法来启动一个单独的 EXE，该 EXE 具有提升的权限，只进行注册.请参阅下一个要点.
- This is most definitely not recommended (but we want to show people what is possible too). Your whole application will run with admin rights all the time, which is not a good idea at all.
- Doing this will violate a key part of logo requirements for Windows applications and you will also open your application up to attack from malware.
- Definitely try to make your users understand the consequences of this "easy fix". I would make sure to put all responsibility on the client if they go for this option - they must understand what they are doing.
- Note that you should be able to use this manifest approach to launch a separate EXE with elevated rights to do only the registration. See next bullet point.
- 在运行时提升(来自代码项目)
- 如何仅在需要时提升权限?(好读)
- 浏览上面的链接内容，您似乎可以启动一个具有更高权限的单独 EXE 来进行注册 - 我认为这是您已知的选项.
- 如果您决定尝试这样做，我们很乐意听取您的意见.可能对我们所有人都有用.
- Elevating during runtime (from Code Project)
- How to elevate privileges only when required? (good read)
- Skimming the linked content above, it seems like you can launch a separate EXE with elevated rights to do your registration - a known option for you I assume.
- Would love to hear back if this is something you decide to try. Could be useful for all of us.
- 我从设置中编写许可证密钥，并在针对 Internet 上的服务器启动应用程序时对其进行验证.那么您的应用程序或您的设置中就没有验证码可以破解.
- 您需要互联网握手"，并且可以为每个用户重复此过程 - 让您可以严格控制谁在使用您的许可证密钥.
- 没有什么是容易的，代理服务器问题可能会导致问题.企业部署也意味着这种在线激活"是不受欢迎的.他们希望在部署后完全安装应用程序.
这篇关于每台机器应用注册的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
