如何覆盖某些网页的身份验证....？

发布于 2024-11-04 22:30:13 字数 324 浏览 0 评论 0原文

好吧，我在母版页中编写了以下代码： -

<authentication mode="Forms">
    <forms loginUrl="Loginpage.aspx" />
</authentication>

现在，如果身份验证失败，它将重定向到“Loginpage.aspx”。

现在，如果我想覆盖几页的此身份验证，该怎么办？另请注意，页面数和页面名称在设计时不可用，因此不能在配置文件中包含 aspx 页面名称。

有没有办法覆盖少数 aspx 页面的身份验证？

-阿尼尔

原文

Well I am having following code written in master page: -

<authentication mode="Forms">
    <forms loginUrl="Loginpage.aspx" />
</authentication>

Now it will redirect to "Loginpage.aspx" if authentication fails.

Now what If I would like to override this authentication for few pages. Also note that the number of pages and page names are not available at design time, so cannot include the aspx page names in configuration file.

Is there anyway to override authentication for few aspx pages?

-Anil

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

却一份温柔 2024-11-11 22:30:13

Henrik 的答案是一个很好的答案，如果实施得当，应该会起作用。然而，这是另一个从配置角度更多地解决问题的选项。我知道您提到您不会提前知道页面名称，因此您无法在每个页面的 web.config 中包含一个条目，但 web.config 也允许您保护文件夹。例如，您可以将所有需要身份验证的页面放置在名为“AuthRequired”的文件夹中，并将所有不需要身份验证的页面放置在名为“Anonymous”的文件夹中。然后在您的网络配置中您可以有以下条目：

<location path="AuthRequired">
  <system.web>
    <authorization>
      <deny users="?" />
      <allow users="*" />
    </authorization>
  </system.web>
</location>
<location path="Anonymous">
  <system.web>
    <authorization>
      <allow users="*" />
    </authorization>
  </system.web>
</location>

Henrik's answer is a good one and should work if properly implemented. However, this is another option which tackles the problem more from a configuration standpoint. I know that you mentioned that you won't know the page names ahead of time so you can't include an entry in web.config for each page BUT web.config allows you to secure folders too. You could have all pages that require authentication placed in a folder called "AuthRequired" and all pages that don't require authentication placed in a folder called "Anonymous", for example. Then in your web config you could have the following entries:

<location path="AuthRequired">
  <system.web>
    <authorization>
      <deny users="?" />
      <allow users="*" />
    </authorization>
  </system.web>
</location>
<location path="Anonymous">
  <system.web>
    <authorization>
      <allow users="*" />
    </authorization>
  </system.web>
</location>

回复收藏 0 原文

小…红帽 2024-11-11 22:30:13

您可以监听 AuthorizeRequest 事件并采取相应的行动。创建您自己的 Http 模块来执行此操作。

三个选项：

使用上面的配置设置以及生成带有 web.config 条目的文件夹。这是一种相当糟糕的方法。

监听事件AuthenticateRequest，代码如下：

公共类 UserAuthenticationModule : IHttpModule
{
私有 HttpApplication _Context；
私有 RoleManagerModule _RoleManager;

公共无效初始化（HttpApplication上下文）
{
    _上下文=上下文；
    context.AuthenticateRequest += AuthenticateUser;
    _RoleManager = (RoleManagerModule)context.Modules["RoleManager"];
    _RoleManager.GetRoles += roleManager_GetRoles;
}

// http://stackoverflow.com/questions/1727960/how-to-keep-roleprovider-from-overriding-custom-roles
私有无效 roleManager_GetRoles（对象发送者，RoleManagerEventArgs e）
{
    if (_Context.User 是 UserPrincipal)
        e.RolesPopulated = true; // 允许在 AuthenticateUser 中设置的角色保留。
}

私有静态无效AuthenticateUser（对象发送者，EventArgs e）
{
    var app = (HttpApplication) 发送者;
    if (app.Context == null) 返回；

    var 用户 = app.Context.User;

    // 未登录，表单身份验证模块负责重定向等。
    如果（用户==空）返回；
    // 那么我们就完成了。
    if（用户是IUser）返回；

    var userEntity = IoC.Resolve().FindByUserName(user.Identity.Name);

    // 我们在数据库中找不到该用户。
    if (userEntity == null)
        throw new ApplicationException(string.Format("用户\"{0}\"在登录应用程序时从数据库中删除或重命名。", 
            用户.身份.名称));

    // 登录，分配用户，也应该分配 Thread.CurrentPrincipal （它不会在 PostAuthenticateRequest 上执行此操作）。
    app.Context.User = new UserPrincipal(userEntity);
    userEntity.SetAuthenticated();
}

//实现IDisposable。
公共无效处置（）
{
}
}

如果您的 UserPrincipal 实现了 IPrincipal，则 IsInRole 用于提供对页面的基于角色的访问。

以服务为导向；设置一个小型透明代理服务器。在动态存储中列出您的端点/uri-s，就像您所描述的那样。设置授权服务，例如Rhino Security；将其服务接口公开为 REST-API 或请求/回复接口或其他接口。从 Web 应用程序的角度来看，假设每个请求都被允许，并注意重定向的位置。在代理服务器中，例如 nginx，它是 Linux 上一个非常好的基于 C 的异步代理服务器，从过滤器/模块调用您的授权服务。 “深度安全”，您可以在授权服务中共享安全配置。

您遵循的原则是，如果 Web 应用程序中不允许某些操作，您会抛出 new HttpException(405, "您尝试执行的当前操作现在对于您的角色或用户或选择的生活路径是允许的" ) 在 AuthorizeRequest 事件中。 请注意，有一个 AuthenticateRequest 和另一个 AuthorizeRequest 事件

You can listen to the AuthorizeRequest event and act accordingly. Create your own Http Module to do this.

Three options:

use the configuration settings above together with generating folders with web.config entries. This is a pretty shoddy way of doing it.

listen to the event AuthenticateRequest, the code looks something like this:

public class UserAuthenticationModule : IHttpModule
{
private HttpApplication _Context;
private RoleManagerModule _RoleManager;

public void Init(HttpApplication context)
{
    _Context = context;
    context.AuthenticateRequest += AuthenticateUser;
    _RoleManager = (RoleManagerModule)context.Modules["RoleManager"];
    _RoleManager.GetRoles += roleManager_GetRoles;
}

// http://stackoverflow.com/questions/1727960/how-to-keep-roleprovider-from-overriding-custom-roles
private void roleManager_GetRoles(object sender, RoleManagerEventArgs e)
{
    if (_Context.User is UserPrincipal)
        e.RolesPopulated = true; // allows roles set in AuthenticateUser to stick.
}

private static void AuthenticateUser(object sender, EventArgs e)
{
    var app = (HttpApplication) sender;
    if (app.Context == null) return;

    var user = app.Context.User;

    // not signed in, forms authentication module takes care of redirecting etc.
    if (user == null) return;
    // we're done then.
    if (user is IUser) return;

    var userEntity = IoC.Resolve<IUserRepository>().FindByUserName(user.Identity.Name);

    // we can't find the user in the database.
    if (userEntity == null)
        throw new ApplicationException(string.Format("User \"{0}\" deleted from, or renamed in, database while logged into application.", 
            user.Identity.Name));

    // signed in, assigning user, which should assign Thread.CurrentPrincipal as well (it wouldn't do this on PostAuthenticateRequest).
    app.Context.User = new UserPrincipal(userEntity);
    userEntity.SetAuthenticated();
}

//Implement IDisposable.
public void Dispose()
{
}
}

If your UserPrincipal implements IPrincipal, then IsInRole is used to give role-based access to your pages.

The service-oriented way; set up a small transparent proxy server. List your endpoints/uri-s in a dynamic store, like what you are describing. Set up an authorization service such as Rhino Security; expose its service interfaces as a REST-API or a request/reply interface or something. Assume from the web app's perspective that every request is allowed and take care of where you redirect. In the proxy server, e.g. nginx which is a very nice asynchronous C-based proxy server on Linux, call your authorization service from a filter/module. 'Security in depth' and you can share configuration for security in the Authorization Service.

The principle that you follow is that if something is not allowed in a web application you do throw new HttpException(405, "The current operation you are trying to perform is now allowed for your role or user or chosen path in life") in the AuthorizeRequest event. Note that there's a AuthenticateRequest and another AuthorizeRequest event

回复收藏 0 原文