16

WebFormsとMVCページの両方を含む大規模なエンタープライズアプリケーションがあります。変更したくない既存の認証と承認の設定があります。

WebForms認証は、web.configで構成されます。

 <authentication mode="Forms">
  <forms blah... blah... blah />
 </authentication>

 <authorization>
  <deny users="?" />
 </authorization>

これまでのところかなり標準的です。この大きなアプリケーションの一部であるRESTサービスがあり、この1つのサービスの代わりにHTTP認証を使用したいと思います。

したがって、ユーザーがRESTサービスからJSONデータを取得しようとすると、HTTP401ステータスとWWW-Authenticateヘッダーが返されます。彼らが正しく形成されたHTTPAuthorization応答で応答する場合、それは彼らを受け入れます。

問題は、WebFormsがこれを低レベルでオーバーライドすることです。401（未承認）を返すと、302（ログインページへのリダイレクト）でオーバーライドされます。これはブラウザでは問題ありませんが、RESTサービスには役に立ちません。

web.configの認証設定をオフにして、「rest」フォルダーをオーバーライドしたい：

 <location path="rest">
  <system.web>
   <authentication mode="None" />
   <authorization><allow users="?" /></authorization>
  </system.web>
 </location>

許可ビットは正常に機能しますが、認証行（<authentication mode="None" />）により例外が発生します。

allowDefinition='MachineToApplication'として登録されているセクションをアプリケーションレベルを超えて使用するとエラーになります。

私はこれをアプリケーションレベルで構成していますが、これはルートweb.configにあり、そのエラーはサブディレクトリのweb.configsにあります。

サイトの残りのすべてがWebForms認証を使用し、この1つのディレクトリが何も使用しないように認証をオーバーライドするにはどうすればよいですか？

これは別の質問に似ています：ASP.NET MVCを使用したjsonリクエストの401応答コードですが、同じ解決策を探していません-WebForms認証を削除して新しいカスタムコードをグローバルに追加したくないので、はるかにあります多くのリスクと関連する作業に。構成内の1つのディレクトリのみを変更したい。

アップデート

単一のWebアプリケーションをセットアップしたいので、すべてのWebFormsページとMVCビューでWebForms認証を使用したいと思います。1つのディレクトリで基本HTTP認証を使用したい。

私が話しているのは認証ではなく、認証であることに注意してください。REST呼び出しにHTTPヘッダーのユーザー名とパスワードを含め、WebFormとMVCページに.Netからの認証Cookieを含める必要があります。いずれの場合も、承認はDBに対して行われます。

WebForms認証を書き直して、自分のCookieをロールバックしたくありません。HTTPで承認されたRESTサービスをアプリケーションに追加する唯一の方法はばかげているようです。

アプリケーションや仮想ディレクトリを追加することはできません。1つのアプリケーションとして使用する必要があります。

4

7 に答える 7

10

「残り」が単にルート内のフォルダーである場合は、ほとんどそこにいます。認証行を削除します。つまり

<location path="rest">
  <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
  </system.web>
 </location>

または、残りのフォルダーに web.config を追加して、次のようにすることもできます。

<system.web>
     <authorization>
          <allow users="*" />
     </authorization>
</system.web>

これをチェックしてください。

于 2011-01-06T16:49:01.917 に答える
4

私はまったく同じ問題を抱えていることに気づきました.次の記事は私を正しい方向に向けてくれました:

具体的には、FormsAuthenticationDispositionModule を構成して、フォーム認証の「トリック」をミュートし、応答コードを 401 から 302 に変更しないようにすることができます。これにより、残りのクライアントが正しい認証チャレンジを受け取ることになります。

MADAM ダウンロードページ：http ://www.raboof.com/projects/madam/

私の場合、REST 呼び出しは「API」領域のコントローラー (これは MVC ベースのアプリです) に対して行われます。MADAM ディスクリミネーターは、次の構成で設定されます。

<formsAuthenticationDisposition>
  <discriminators all="1">
    <discriminator type="Madam.Discriminator">
      <discriminator
          inputExpression="Request.Url"
          pattern="api\.*" type="Madam.RegexDiscriminator" />
    </discriminator>
  </discriminators>
</formsAuthenticationDisposition>

あとは、MADAM モジュールを web.config に追加するだけです。

<modules runAllManagedModulesForAllRequests="true">
  <remove name="WebDAVModule" /> <!-- allow PUT and DELETE methods -->
  <add name="FormsAuthenticationDisposition" type="Madam.FormsAuthenticationDispositionModule, Madam" />
</modules>

有効なセクションを web.config に追加することを忘れないでください (コードを貼り付けることができませんでした)。ダウンロードで Web プロジェクトから例を取得できます。

このセットアップでは、「API/」で始まる URL に対して行われたすべての要求は、フォーム認証によって生成された 301 ではなく、401 応答を取得します。

于 2012-01-21T04:52:19.627 に答える
4

既存のすべてのページに対して、global.asax でフォーム認証をスプーフィングするという厄介な方法で、これを回避しました。

まだ完全には機能していませんが、次のようになります。

protected void Application_BeginRequest(object sender, EventArgs e)
{
    // lots of existing web.config controls for which webforms folders can be accessed
    // read the config and skip checks for pages that authorise anon users by having
    // <allow users="?" /> as the top rule.

    // check local config
    var localAuthSection = ConfigurationManager.GetSection("system.web/authorization") as AuthorizationSection;

    // this assumes that the first rule will be <allow users="?" />
    var localRule = localAuthSection.Rules[0];
    if (localRule.Action == AuthorizationRuleAction.Allow &&
        localRule.Users.Contains("?"))
    {
        // then skip the rest
        return;
    }

    // get the web.config and check locations
    var conf = WebConfigurationManager.OpenWebConfiguration("~");
    foreach (ConfigurationLocation loc in conf.Locations)
    {
        // find whether we're in a location with overridden config
        if (this.Request.Path.StartsWith(loc.Path, StringComparison.OrdinalIgnoreCase) ||
            this.Request.Path.TrimStart('/').StartsWith(loc.Path, StringComparison.OrdinalIgnoreCase))
        {
            // get the location's config
            var locConf = loc.OpenConfiguration();
            var authSection = locConf.GetSection("system.web/authorization") as AuthorizationSection;
            if (authSection != null)
            {
                // this assumes that the first rule will be <allow users="?" />
                var rule = authSection.Rules[0];
                if (rule.Action == AuthorizationRuleAction.Allow &&
                    rule.Users.Contains("?"))
                {
                    // then skip the rest
                    return;
                }
            }
        }
    }

    var cookie = this.Request.Cookies[FormsAuthentication.FormsCookieName];
    if (cookie == null ||
        string.IsNullOrEmpty(cookie.Value))
    {
        // no or blank cookie
        FormsAuthentication.RedirectToLoginPage();
    }

    // decrypt the 
    var ticket = FormsAuthentication.Decrypt(cookie.Value);
    if (ticket == null ||
        ticket.Expired)
    {
        // invalid cookie
        FormsAuthentication.RedirectToLoginPage();
    }

    // renew ticket if needed
    var newTicket = ticket;
    if (FormsAuthentication.SlidingExpiration)
    {
        newTicket = FormsAuthentication.RenewTicketIfOld(ticket);
    }

    // set the user so that .IsAuthenticated becomes true
    // then the existing checks for user should work
    HttpContext.Current.User = new GenericPrincipal(new FormsIdentity(newTicket), newTicket.UserData.Split(','));

}

修正としてこれにはあまり満足していません。恐ろしいハックと車輪の再発明のように思えますが、フォーム認証ページと HTTP 認証 REST サービスが機能する唯一の方法のようです。同じアプリケーション。

于 2011-01-18T08:55:04.427 に答える
2

.NET 4.5 では、設定できるようになりました

Response.SuppressFormsAuthenticationRedirect = true

このページを確認してください: https://msdn.microsoft.com/en-us/library/system.web.httpresponse.suppressformsauthenticationredirect.aspx

于 2016-02-21T18:30:25.693 に答える
2

以前のプロジェクトでこれを機能させることができましたが、アカウントの検証は Windows ではなくデータベースに対して行われるため、HTTP モジュールを使用してカスタム基本認証を実行する必要がありました。

テスト Web サイトのルートにある 1 つの Web アプリケーションと、REST サービスを含むフォルダーを指定して、テストをセットアップしました。ルート アプリケーションの構成は、すべてのアクセスを拒否するように構成されています。

<authentication mode="Forms">
  <forms loginUrl="Login.aspx" timeout="2880" />
</authentication>
<authorization>
  <deny users="?"/>
</authorization>

次に、IIS で REST フォルダー用のアプリケーションを作成し、web.config ファイルを REST フォルダーに配置する必要がありました。その構成では、次のように指定しました。

<authentication mode="None"/>
<authorization>
  <deny users="?"/>
</authorization>

また、REST ディレクトリの構成内の適切な場所に http モジュールを接続する必要がありました。このモジュールは、REST ディレクトリの下の bin ディレクトリに移動する必要があります。Dominick Baier のカスタム基本認証モジュールを使用しました。そのコードはここにあります。そのバージョンはより IIS 6 固有のものですが、codeplexにも IIS 7 のバージョンがありますが、私はそれをテストしていません (警告: IIS6 バージョンには、IIS7 バージョンと同じアセンブリ名と名前空間がありません)。この基本認証モジュールは、ASP.NET のメンバーシップ モデルに直接プラグインされるため、非常に気に入っています。

最後の手順は、IIS 内のルート アプリケーションと REST アプリケーションの両方に対して匿名アクセスのみが許可されるようにすることでした。

完全を期すために、以下に完全な構成を含めました。テスト アプリは、VS 2010 から生成された単なる ASP.NET Web フォーム アプリケーションであり、メンバーシップ プロバイダーに AspNetSqlProfileProvider を使用していました。設定は次のとおりです。

<?xml version="1.0"?>

<configuration>
  <connectionStrings>
    <add name="ApplicationServices"
      connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;Database=sqlmembership;"
    providerName="System.Data.SqlClient" />
  </connectionStrings>

  <system.web>
    <compilation debug="true" targetFramework="4.0" />

    <authentication mode="Forms">
      <forms loginUrl="~/Account/Login.aspx" timeout="2880" />
    </authentication>

    <authorization>
      <deny users="?"/>
    </authorization>

    <membership>
      <providers>
        <clear/>
        <add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="ApplicationServices"
          enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="false"
          maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10"
        applicationName="/" />
      </providers>
    </membership>

    <profile>
      <providers>
        <clear/>
        <add name="AspNetSqlProfileProvider" type="System.Web.Profile.SqlProfileProvider" connectionStringName="ApplicationServices" applicationName="/"/>
      </providers>
    </profile>

    <roleManager enabled="false">
      <providers>
        <clear/>
        <add name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider" connectionStringName="ApplicationServices" applicationName="/" />
        <add name="AspNetWindowsTokenRoleProvider" type="System.Web.Security.WindowsTokenRoleProvider" applicationName="/" />
      </providers>
    </roleManager>

  </system.web>

  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
  </system.webServer>
</configuration>

REST ディレクトリには VS 2010 から生成された空の ASP.NET プロジェクトが含まれており、その中に単一の ASPX ファイルを配置しましたが、REST フォルダーの内容は新しいプロジェクトである必要はありませんでした。ディレクトリにアプリケーションが関連付けられた後、構成ファイルをドロップするだけで機能します。そのプロジェクトの構成は次のとおりです。

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section name="customBasicAuthentication" type="Thinktecture.CustomBasicAuthentication.CustomBasicAuthenticationSection, Thinktecture.CustomBasicAuthenticationModule"/>
  </configSections>
  <customBasicAuthentication
    enabled="true"
    realm="testdomain"
    providerName="AspNetSqlMembershipProvider"
    cachingEnabled="true"
    cachingDuration="15"
  requireSSL="false" />

  <system.web>
    <authentication mode="None"/>
    <authorization>
      <deny users="?"/>
    </authorization>

    <compilation debug="true" targetFramework="4.0" />
    <httpModules>
      <add name="CustomBasicAuthentication" type="Thinktecture.CustomBasicAuthentication.CustomBasicAuthenticationModule, Thinktecture.CustomBasicAuthenticationModule"/>
    </httpModules>
  </system.web>
</configuration>

これがあなたのニーズを満たすことを願っています。

于 2011-01-18T07:31:41.780 に答える
1

私の以前の回答に対するあなたのコメントを見て、REST ディレクトリへのアプリケーションの展開を Web アプリで自動化できないかと考えました。これにより、2 番目のアプリケーションの利点を得ることができ、システム管理者の展開の負担も軽減されます。

私が考えたApplication_Startのは、global.asax のメソッドに、REST ディレクトリが存在すること、およびそれに関連付けられたアプリケーションがまだ存在しないことを確認するルーチンを追加できるということでした。テストが true を返した場合、新しいアプリケーションを REST ディレクトリに関連付けるプロセスが発生します。

私が考えていたもう 1 つの考えは、WIX (または別の展開テクノロジ) を使用して、管理者がアプリケーションを作成するために実行できるインストール パッケージを作成できるということでしたが、それはアプリに依存関係を構成させるほど自動的ではないと思います。

以下に、IIS で特定のディレクトリをチェックし、アプリケーションがまだ存在しない場合はアプリケーションを適用するサンプル実装を含めました。コードは IIS 7 でテストされましたが、IIS 6 でも動作するはずです。

//This is part of global.asax.cs
//This approach may require additional user privileges to query IIS

//using System.DirectoryServices;
//using System.Runtime.InteropServices;

protected void Application_Start(object sender, EventArgs evt)
{
  const string iisRootUri = "IIS://localhost/W3SVC/1/Root";
  const string restPhysicalPath = @"C:\inetpub\wwwroot\Rest";
  const string restVirtualPath = "Rest";

  if (!Directory.Exists(restPhysicalPath))
  {
    // there is no rest path, so do nothing
    return;
  }

  using (var root = new DirectoryEntry(iisRootUri))
  {
    DirectoryEntries children = root.Children;

    try
    {
      using (DirectoryEntry rest = children.Find(restVirtualPath, root.SchemaClassName))
      {
        // the above call throws an exception if the vdir does not exist
        return;
      }
    }
    catch (COMException e)
    {
      // something got unlinked incorrectly, kill the vdir and application
      foreach (DirectoryEntry entry in children)
      {
        if (string.Compare(entry.Name, restVirtualPath, true) == 0)
        {
          entry.DeleteTree();
        }     
      }
    }
    catch (DirectoryNotFoundException e)
    {
      // the vdir and application do not exist, add them below
    }

    using (DirectoryEntry rest = children.Add(restVirtualPath, root.SchemaClassName))
    {
      rest.CommitChanges();
      rest.Properties["Path"].Value = restPhysicalPath;
      rest.Properties["AccessRead"].Add(true);
      rest.Properties["AccessScript"].Add(true);
      rest.Invoke("AppCreate2", true);
      rest.Properties["AppFriendlyName"].Add(restVirtualPath);
      rest.CommitChanges();
    }
  }
}

このコードの一部はhereからのものです。あなたのアプリで頑張ってください！

于 2011-01-18T20:40:39.443 に答える
1

これは最もエレガントなソリューションではないかもしれませんが、良いスタートだと思います

1)HttpModule を作成します。

2) AuthenticateRequest イベントを処理します。

3) イベント ハンドラーで、アクセスを許可するディレクトリに対する要求であることを確認します。

4) 手動で auth cookie を設定する場合: (または、制御できるようになり、認証がまだ行われていないので、別の方法を見つけることができるかどうかを確認してください)

FormsAuthentication.SetAuthCookie("Anonymous", false);

5) ほとんど忘れていましたが、アクセスを許可したいディレクトリに対するリクエストではない場合、認証 Cookie がクリアされていることを確認する必要があります。

于 2011-01-17T16:59:13.653 に答える