SPSecurity.RunWithElevatedPrivileges 在控制台应用程序中执行任何操作吗？
根据我从反射器收集到的信息，RunWithElevatedPriveleges 只是将当前线程标识恢复为基本（非模拟）标识。 对于在 WSS 应用程序池内运行的代码来说，这是非常有意义的，因为基本服务帐户是超级用户。 当不存在模拟时，在外部（控制台或服务）应用程序中运行时它是否有任何影响？ 我猜不是，但我想确切地知道。 我通过谷歌搜索看到了对此的不同看法。
From what I have gleaned from reflector, RunWithElevatedPriveleges simply reverts the current thread identity to the base (non-impersonated) identity. This makes perfect sense in the case of code running inside the WSS application pool, since the base service account is a super-user. Does it have any effect when running in an external (console or service) application, when no impersonation exists? I'm guessing not, but I'd like to know for sure. I've seen varying opinions on this from googling.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为如果您在一个帐户下运行可执行文件，然后使用代码更改其凭据（就像 SP 那样），就会出现这种情况。 否则，如果没有某种方式生成 Credentials 对象，它就无法提升到开始时没有的权限。
I think it would if you ran the executable under one account and then changed it's credentials with code (like SP does). Otherwise, it cannot elevate to permissions it didn't have at start without some way of generating a Credentials object.
当 HTTPContext 为 null 时，RunWithElevatedPriveleges 不起作用。 在控制台中，HTTPContext 为空。
RunWithElevatedPriveleges don't work when HTTPContext is null. In console, HTTPContext is null.
通常，Runwithelevatedprivileges 将使您的代码以应用程序池身份运行，但它无法从控制台运行。 在这种情况下，我们所做的是使用 runas 或
a 将计划任务的标识设置为与应用程序池标识相同的帐户。
Normally Runwithelevatedprivileges will get your code running as the app pool identity, but it doesn't work from the console. What we've done in this case is either use runas or
a set the identity of a scheduled task to the same account as the app pool identity.