允许管理员从我的程序中修改用户设置——我的最佳选择是什么？
我一直致力于让管理员更容易使用我的应用程序。 我真正想做的一件事是允许管理员从程序内修改其他用户的设置 - 同时仍然允许普通用户修改他们自己的设置，因为我的应用程序不一定只用于想要强制用户使用特定设置的管理员。
我想到了两种可能的方法：
1）将用户设置文件路径从现在的位置移动（CLSID_APPDATA，通常文档和设置\用户名< /b>）到世界可访问的路径（CLSID_COMMON_APPDATA，通常是Documents and Settings\All Users）。 然后，将每个用户的设置保存到该用户的唯一文件中（可能具有与用户的文本 SID 相同的名称），因此该文件夹看起来类似于：
C:\Documents and Settings\All Users\My Company\My Program\settings\123-abc-456-def.settings
C:\Documents and Settings\All Users\My Company\My Program\settings\234-bcd-477-xyz.settings
C:\Documents and Settings\All Users\My Company\My Program\settings\946-hdc-743-ddd.settings
优点：缺点：
- 这允许管理员查看并直接修改任何用户的设置，因为 COMMON_APPDATA 路径对于所有用户都是相同的。 这就是我真正希望的方式——这是最简单的——但有一个主要缺点：
2) 不要将设置文件路径移动到全局可访问的路径并直接修改用户的设置文件，而是让我的应用程序在应用程序的 CLSID_COMMON_APPDATA 文件夹中创建并保存“覆盖”文件，以允许管理员覆盖用户的设置。
- 权限可能是一个问题。 要允许普通用户保存其设置，您必须允许用户对程序的 COMMON_APPDATA 设置文件夹进行写入访问。
当然，当保存设置并在磁盘上创建设置文件时，您希望将用户设置文件的写入权限限制为设置所属用户和管理员，以便其他受限用户无法访问修改它们。
然而，在用户有机会从程序内写入自己的设置之前，精明的恶意受限用户可能会在用户不知情的情况下为该特定用户创建设置文件。 如果受限用户创建了该文件，则意味着他们拥有该文件...然后该用户（设置的对象）将无法再修改设置，除非管理员更改该文件的权限。
< br> 也许这种情况不太可能发生，但我仍然担心。
当我的应用程序为该用户（其设置被“覆盖”）加载时，它将检测此文件并加载它，而不是加载位于 CLSID_APPDATA 中的常规设置文件（文档和设置\用户名）。
优点：缺点：
- 权限很容易处理。
默认情况下，对于Documents and Settings\用户名 APPDATA 文件夹，只有管理员和用户名可以从内部访问文件。 因此，这本身就可以保护用户自己的常规个人设置免受其他有限用户的影响。
为了保护“覆盖”设置，我的应用程序可以简单地拒绝除管理员之外的所有人对 COMMON_APPDATA 文件夹（写入覆盖文件的位置）的写入访问权限，仅此而已。 这些覆盖设置只能由管理员修改。
- 这种方法显然比较迂回。 如果用户修改自己的常规个人设置，管理员将看不到这些更改 - 管理员只能看到他用来覆盖用户常规设置的设置（他可以强制用户使用这些设置）。
< br> 在某些方面，这可能很好，但是...事实上，它的迂回让我有些厌烦。
我很想听听你们对此有何看法。 哪个是我最好的选择？ 我个人更倾向于#2，因为虽然它不太简单，但它似乎更安全，并且不会让管理员感到困惑。
不过，我也愿意接受建议。 您认为有更好的选择吗？
编辑 7/6/09： 我应该注意，对于选项#2，管理员不仅可以使用单个覆盖文件覆盖所有用户的设置，还可以使用特定的覆盖文件覆盖单个用户的设置到该用户（就像选项 #1 一样，该文件名可能是设置被覆盖的用户的 SID）。 不确定原始帖子中是否完全清楚这一点。
I've been working on making my app easier to use for administrators. One of the things I'd really like to do is allow admins to modify other user's settings from within the program -- while still making it possible for regular ol' users to modify their own settings, as my application isn't necessarily only for administrators who want to force users to use specific settings.
I thought of two possible ways of doing this:
1) Move the user setting file path from where it is now (CLSID_APPDATA, commonly Documents and Settings\Username) to a world-accessible path (CLSID_COMMON_APPDATA , commonly Documents and Settings\All Users). Then, save each user's settings to a unique file for the user (probably having a name which equals that of the user's textual SID), so the folder looks something like:
C:\Documents and Settings\All Users\My Company\My Program\settings\123-abc-456-def.settings
C:\Documents and Settings\All Users\My Company\My Program\settings\234-bcd-477-xyz.settings
C:\Documents and Settings\All Users\My Company\My Program\settings\946-hdc-743-ddd.settingsPros:
- This allows an admin to see and directly modify any user's settings, because the COMMON_APPDATA path is the same for all users. This is how I'd really like it to be -- it's the most straightforward -- but there's a major con:
Cons:
- Permissions could be a problem. To allow regular users to save their settings, you'd have to allow users write access to the program's COMMON_APPDATA setting folder.
Of course, when the settings are saved and the setting file created on disk, you'd want to limit write access on the user's setting file to the user who the settings are for, and for admins, so that other limited user's can't modify them.
However, it could be that before a user has a chance to write their own settings from within the program, a savvy, malicious limited user creates a setting file for that specific user, without the knowledge of the user. If the limited user creates the file, that means they own the file... and then that user (who the settings are for) can't modify the settings anymore, unless an admin changes the permissions on the file.
An unlikely situation perhaps, but it still worries me.
2) Instead of moving the setting file path to a globally-accessible path and modifying the user's setting file directly, have my app create and save an "override" file in the app's CLSID_COMMON_APPDATA folder, to allow the admin to override the user's settings.
When my app loads for that user (who's settings were "overridden") it'll detect this file and load it instead of the regular setting file, which is located in CLSID_APPDATA (Documents and Settings\Username).
Pros:
- Permissions are easy to deal with.
By default, for the Documents and Settings\Username APPDATA folder, only admins and Username can access the files from within. So that in itself protects the user's own regular personal settings from other limited users.
To protect the "override" settings, my app can simply deny write access to the COMMON_APPDATA folder -- where the override file is written -- to all but administrators, and then that's that. These overriding settings will only be modifiable by admins.
Cons:
- This method is obviously more roundabout. If a user modifies his own regular personal settings, an admin won't see those changes -- the admin can only see the settings he's overriding the user's regular settings with (which he can force the user to use instead).
In some ways, this might be good, but... the fact that it's roundabout turns me off somewhat.
I'm interested to hear what you guys think about this. Which is my best option? I'm personally leaning more towards #2, because while it's less straightforward, it seems to be more secure and isn't so roundabout where it'd be confusing for an admin.
However, I'm also open to suggestions. Is there a superior option you think would work better?
EDIT 7/6/09: I should note that for option #2, the admin could not only override all user's settings with a single override file, but also override an individual user's settings with an override file specific to that user (just like with option #1, that file name would likely be that of the SID of the user who's settings are being overridden). Not sure if that was completely clear in the original post.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
除非每台计算机上有多个用户帐户（即一台计算机由多个人使用），否则选项二是更好的选择。
即使每台计算机上有多个用户帐户，我认为选项二仍然是更好的选择。 最坏的情况是，管理员将不得不更改同一台计算机上的少数帐户（而不是一个帐户）的设置。
如果您的设施允许任何人随机使用任何计算机，那么选项一是更好的选择，因为选项二将使在每台计算机上维护这么多不同的帐户变得非常困难。
当然，您始终可以将应用程序设置放在服务器上的用户文件夹中。 这对于管理员来说非常方便。
Unless there is more than one user account on each computer (i.e. a computer is used by more than one person), option two is the better choice.
Even if there is more than one user account on each computer, I think option two is still a better choice. Worst case, the administrator will have to change settings on a handful of accounts on the same computer instead of one.
If your facility allows random usage of any computer by any person, then option one is the better choice, since option two will make it too difficult to maintain that many different accounts on every computer.
Of course, you can always put the application settings in user folders on the server. That would make it very convenient for an administrator.
如果管理员已经拥有存储其设置文件的用户目录的权限，那么这不是已经解决了您的问题吗？ 不管怎样，听起来选项 2 是最好的，然后你可以有一个可以覆盖一组用户的文件，然后每个用户也有自己的设置。 只要您的应用程序足够智能，能够判断何时覆盖设置、何时不覆盖设置，选项 2 就不应该成为一个大问题。
If the administrator already has rights to the user's directory where his setting's file is stored, wouldn't that already solve your problem? Either way though, it sounds like option 2 would be best, then you could have a single file that could override say a group of users, then each user have their own settings as well. Just so long as your application is smart enough to tell when to override a setting and when not too, option 2 shouldn't be that much of an issue.