6

私のアプリケーションは、UserPrincipalクラスを使用してユーザーが属するグループを判別し、次にその情報を使用して、ユーザーが私のアプリケーションを使用するために認証されているかどうかを判別します。しばらくは問題なく動作しましたが、最近例外が発生し始めました

GUIDには、4つのダッシュを含む32桁の数字が含まれている必要があります（xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx）

を呼び出すときUserPrincipal.FindByIdentity。呼び出しは成功し、例外は適切に処理されているように見えますが、将来、認証が突然中断されるのではないかと不安になります。どこにもGUIDを明示的に作成していないので、例外がどこから来ているのかわかりません。

4

4 に答える 4

7

無効な GUID 値からある種のセキュリティ記述子を初期化しようとしているフレームワーク コードの深い場所で例外がスローされている可能性が最も高いです。フレームワークがそれをキャッチして内部で処理している場合、私はそれについて心配しません。

フレームワーク コードをトレースすると、次の場所で発生する可能性があります。

protected static bool IdentityClaimToFilter(string identity, string identityFormat, ref string filter, bool throwOnFail)
{
  if (identity == null)
    identity = "";
  StringBuilder filter1 = new StringBuilder();
  switch (identityFormat)
  {
    case "ms-guid":
      Guid guid;
      try
      {
        guid = new Guid(identity);
      }
      catch (FormatException ex)
      {
        if (throwOnFail)
          throw new ArgumentException(ex.Message, (Exception) ex);
        else
          return false;
      }
...

new を作成しようとGuidしており、失敗した場合は例外がスローされますが、コードはそれを飲み込み、単に false を返すことに注意してください。

于 2013-01-17T19:25:37.187 に答える
4

IdentityType を指定すると、値を Guid と見なそうとしないため、例外はスローされません。

FindByIdentityWithType(context, typeof(UserPrincipalEx), **IdentityType.SamAccountName**, identityValue);
于 2015-10-14T15:41:09.423 に答える