我在Web应用程序中创建了一个网站集，其中用户A作为网站集管理员。我在网站功能页面中添加了一个链接。点击该链接我试图创建一个计时器job.Below是点击链接时执行的代码
//Allow unsafe updates.
SPContext.Current.Web.AllowUnsafeUpdates = true;
//Get current web application.
SPWebApplication webApp = SPContext.Current.Site.WebApplication;
// Create new job.
ArchiveJob automaticArchiveJob = new ArchiveJob(scheduleDetails.scheduleName, webApp);
SPHourlySchedule hourlySchedule = new SPHourlySchedule();
hourlySchedule.BeginMinute = 0;
hourlySchedule.EndMinute = 1;
automaticArchiveJob.Schedule = hourlySchedule;
//Finally update archival job.
automaticArchiveJob.Update();
现在，当我使用用户A登录并点击“网站设置”页面上的该链接时，我在第automaticArchiveJob.Update()行收到一条安全例外消息“拒绝访问”。
但是，如果我使用管理员用户登录（我也使用此用户登录到该计算机）并单击该链接，则会成功创建作业。
此外，我使用户成为WSS_ADMIN_WPG组的成员，但仍然遇到同样的问题。我还需要做些什么来解决这个问题。
答案 0 :(得分：23)
根据您尝试执行的操作，“拒绝访问”是预期的行为。请允许我解释一下。
创建计时器作业实例时，它将持久保存到服务器场配置数据库。访问此数据库以进行写入是一项特权操作;根据经验，只有服务器场帐户（即OWSTIMER.EXE执行的帐户）或明确拥有在配置数据库（通常是管理员）上执行此类操作所需权限的帐户才会成功。 / p>
默认情况下，尝试从网站集上下文中实例化计时器作业将失败。在提升的权限块中尝试操作（通过SPSecurity.RunWithElevatedPrivileges）只会导致使用Web应用程序的应用程序池帐户上下文而不是当前用户上下文;如果应用程序池帐户有权写入服务器场配置数据库，则此操作仅会成功。如果发生这种情况，通常是因为（a）服务器场服务帐户正在其不应该使用的角色中（例如，运行内容Web应用程序），或（b）已向应用程序池授予额外权限帐户。这两种情况都表示偏离了最佳实践操作模型。
计时器作业实例通常在功能区域中的功能范围内的功能激活时创建。为什么？因为这些功能通常由管理员从命令行激活（假设管理员还拥有服务器场配置数据库中的权限）或从管理中心（通过服务器场帐户激活的位置）激活 - 保证拥有配置数据库的权限）。激活功能并调用SPFeatureReceiver的FeatureActivated方法时，安全（从安全角度来看）设置计时器作业是安全的。
正确解决您的特定问题将涉及将问题转移到头上。我建议您在激活功能时设置等效的“扫描”计时器作业，而不是尝试从网站集中按需实例化计时器作业。不可否认，这需要比你想要做的更多的计划和努力，但是如果安全性以某种方式调整，你的当前路径才会起作用 - 而且不建议这样做。
当我整理我的BLOB缓存场刷新功能（http://blobcachefarmflush.codeplex.com）时，我必须自己做同样的事情。您可以在FeatureReceiver类（BlobCacheFarmFlushSweepJobFeatureReceiver）中查看我如何通过计时器作业创建的具体细节。其余代码和相关文档也可能有助于解决其他一些挑战。
随意使用您发现的任何内容;这就是为什么它在那里！
我希望有所帮助。如果有后续问题，请开火，我会尽可能地回答： - ）
答案 1 :(得分：0)
尝试覆盖SPPersistedObject.HasAdditionalUpdateAccess（）方法并返回true。
>>> a = "3213>1234<3213"
>>> re.findall(">(\d+)<", a)
['1234']
答案 2 :(得分：-3)
我使用过RunWithElevatedPrivileges
SPSecurity.RunWithElevatedPrivileges（委托（） { }）;
它对我有用.....有人有另一种解决方案吗？如果是这样，请告诉我。