使用带有重写 URL 的表单身份验证/授权

发布于 2024-07-23 04:42:54 字数 1790 浏览 6 评论 0原文

我正在使用一些重写的​​ URL(示例取自 Scott Guthrie 的博客)和表单身份验证/授权进行快速沙箱测试。

我有一个非常简单的设置。

~/View/(\d{1,6})      =>      ~/Public/View.aspx?ContentID=$1

并且

~/Buy/(\d{1,6})       =>      ~/Private/Purchase.aspx?ContentID=$1

我通过分别浏览以下每个内容来确认 URL 重写正在工作

接下来我去并为 Web.Config 中的这 2 个目录启用了表单身份验证/授权。 设置如下

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

当我浏览到 2 个原始 URL(.aspx)时,效果非常好 但当我浏览到 URL 重写版本时根本不会触发。

我尝试为 Buy 单独添加 部分,但这仍然无法导致授权/身份验证模块启动。

大概这是因为它不是'不要将这些 URL 视为 ASPX 资源...我可以通过让重写器规则查找来绕过它,

    <LookFor>~/Buy/(\d{1,6})\.aspx</LookFor>

即强制重写版本在末尾有一个 ASPX,但这看起来很难看。 无论如何,是否有办法让身份验证处理程序针对任何 url 类型触发,无论扩展名如何(或缺少扩展名)

I'm doing a quick sandbox test with some Rewritten URLs (example taken from Scott Guthrie's blog) and Forms Authentication / Authorization.

I've a very simple setup.

~/View/(\d{1,6})      =>      ~/Public/View.aspx?ContentID=$1

AND

~/Buy/(\d{1,6})       =>      ~/Private/Purchase.aspx?ContentID=$1

I've confirmed the URL Rewriting is working by browsing to each of the following seperately

Next I went and enabled my Forms Authentication/Authorization for those 2 directories in the Web.Config. Setup as follows

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

This works perfectly when I browse to the 2 original URLs (the .aspx's)
but doesn't fire at all when I browse to the URL Rewritten versions.

I've attempted to add <location> sections for Buy seperately but this still fails to cause the authorization/authentication module to kick in.

Presumably this is because it isn't treating these URLs as ASPX Resources... I can get around it by making the rewriter rule look for

    <LookFor>~/Buy/(\d{1,6})\.aspx</LookFor>

i.e. force the rewritten version to have an ASPX at the end, but this just seems ugly.
Is there anyway to get the Auth Handlers to fire for any url type regardless of the extension (or lack there of)

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

扫码二维码加入Web技术交流群

发布评论

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

评论(4

雪若未夕 2024-07-30 04:42:54

要使用内置身份验证,您必须决定是否要基于原始“原始”URL 或重写的 URL 进行身份验证。 您正在使用的 URL 重写器似乎在执行身份验证后连接到一个事件,这就是为什么仅遵循“公共”和“私人”文件夹规则的原因。 如果您想根据重写的 URL 进行身份验证,则必须使用重写器来连接到较早的事件(例如 BeginRequest),并使用重写的 URL 更新您的 web.config。

或者,您可以插入自己的身份验证提供程序并执行一些奇特的操作,例如检查重写的 URL 和原始 URL,但这对于沙箱测试站点来说可能有点过大了。

有关详细信息,请参阅本文:

http://msdn.microsoft.com/ en-us/library/ms972974.aspx

我希望这有帮助。

To use built-in auth, you will have to decide whether you want to authenticate based on the original 'raw' URLs or the rewritten ones. It appears as if the URL rewriter you're using is hooked up to an event after the authentication has already been performed, which is why only the 'Public' and 'Private' folder rules are being followed. If you want to authenticate based on the rewritten URLs, then you'll have to use a rewriter that hooks up to an earlier event (such as BeginRequest) as well as updating your web.config with the rewritten URLs.

Alternatively, you can plug-in your own authentication provider and do fancy things like checking both rewritten and original URLs, but that's probably overkill for just a sandbox test site.

Please see this article for more information:

http://msdn.microsoft.com/en-us/library/ms972974.aspx

I hope this helps.

红尘作伴 2024-07-30 04:42:54

在 ASP.NET 4.0 中(我相信是在 3.5 SP1 中),包含了一个新的路由功能。 使用此路由功能的好处是,现在 ASP.NET 内部直接支持它,因此您可以指定在执行路由时,它应遵循实际 .ASPX 文件的授权设置。

因此,我建议您研究一下是否可以实现此路由功能。

In ASP.NET 4.0 (and I believe it is in 3.5 SP1), there is included a new routing feature. The benefits of using this routing feature is that it is now supported directly inside ASP.NET, and you can therefore specify that when a route is executed, it shall respect the authorization settings for the actual .ASPX file.

So I would reccomend you to investigate if you can implement this routing feature instead.

橘寄 2024-07-30 04:42:54

目前尚不清楚您使用的是什么 url 重写库,但从外观来看,我认为它可能是 urlrewriter.net,但我没有看到任何标签?

Its not clear what url rewriting library you use but from the looks of things I think its probably urlrewriter.net however I dont see any tag?

深巷少女 2024-07-30 04:42:54

尝试对所有请求启用表单身份验证和授权。 默认情况下,它仅针对 .aspx 等 asp.net 请求启用。
可以在 IIS (7) 中完成或直接在 webserver/modules 部分的 web.config 中完成

<system.webServer>
   <modules>
        <remove name="FormsAuthentication" />
        <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" preCondition=""/>
        <remove name="UrlAuthorization" />
        <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" preCondition="" />
   </modules>
</system.webServer>

try enabling formsauthentication and authorisation on all requests. By default it is only enabled for asp.net requests like .aspx.
Can be done in IIS (7) or directly in web.config in webserver/modules section

<system.webServer>
   <modules>
        <remove name="FormsAuthentication" />
        <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" preCondition=""/>
        <remove name="UrlAuthorization" />
        <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" preCondition="" />
   </modules>
</system.webServer>
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文