2011-07-13 3 views
6

У меня есть файл Global.asx, который должен выполнять пользовательскую аутентификацию, аудит и профилирование. Это необходимо, потому что оно поддерживает систему SSO на основе SAML и требует переопределения обычной .Net-аутентификации (которая не поддерживает SAML или смешанную аутентификацию)Проверьте статический файл во время Application_BeginRequest?

Я не хочу запускать ее для статических файлов, таких как .js, .css, .png, и т.д.

В Cassini/WebDev и IIS7 он делает.

Что я хочу иметь, это простая проверка, например (которой, к сожалению, не существует), чтобы идентифицировать статические файлы.

Я понимаю, что это было бы довольно просто написать, но оно похоже на то, что должно уже существовать - IIS уже применил кэширование материала политики для статических файлов и так далее.

Мне нужно решение для кода, а не изменение конфигурации IIS.

Update

Это мой текущий обходной путь:

/// <summary>Hold all the extensions we treat as static</summary> 
static HashSet<string> allowedExtensions = new HashSet<string>(StringComparer.OrdinalIgnoreCase) 
{ 
    ".js", ".css", ".png", ... 
}; 

/// <summary>Is this a request for a static file?</summary> 
/// <param name="request">The HTTP request instance to extend.</param> 
/// <returns>True if the request is for a static file on disk, false otherwise.</returns> 
public static bool IsStaticFile(this HttpRequest request) 
{ 
    string fileOnDisk = request.PhysicalPath; 
    if (string.IsNullOrEmpty(fileOnDisk)) 
    { 
     return false; 
    } 

    string extension = Path.GetExtension(fileOnDisk); 

    return allowedExtensions.Contains(extension); 
} 

Это работает и достаточно быстро, но чувствует себя ужасно неуклюжим. В частности, полагаясь на расширения, вы будете склонны к ошибкам, если мы добавим новые статические файлы, о которых не думал.

Есть ли лучший способ без изменения конфигурации IIS?

ответ

0

Возможно, у вас есть возможность проверить, какой обработчик имеет дело с запросом.

В IIS6 только .net-файлы, например aspx, отображаются в обработчик, который делает вещи.

В IIS7 с интегрированным конвейером все проходит через .net, что обычно хорошо. Однако разные обработчики все еще имеют дело с разными типами файлов. В частности, я считаю, что staticfilehandler - это тот, который вам нужно проверить. Свойство httpcontext.handler должно позволить вам понять это.

Вы можете создать метод расширения, чтобы добавить, что метод IsStatic ...

Simon

+0

Я понимаю, что я мог написать свою собственную реализацию (например, я говорю в вопросе), но это похоже на повторное изобретательство колеса. IIS и .Net уже знают, что это статический запрос файла, поэтому должен существовать существующий способ сделать это. – Keith

0

Есть несколько вариантов:

  • добавляя authorizationelement и отрицать ни для тех путей, которые вы не требует никакой проверки подлинности и содержит ваши статические файлы
  • Вы используете интегрированный трубопровод. Выключите его на вашем IIS 7.
+0

Мне пришлось полностью переопределить механизм авторизации .Net для поддержки SOML SSO (поэтому мне нужно много работать в «Application_BeginRequest» в первую очередь), поэтому вариант 1 отсутствует. Кроме того, как я уже сказал в вопросе, изменение конфигурации IIS не является вариантом - мне нужно решение для кода. – Keith

+0

Извините, вы должны были прочитать его полностью. Будет обновляться. – Aliostad

0

Существует никаких сомнений в том, что вам нужно создать метод пользовательского расширения, поскольку механизм маршрутизации ASP.NET использует этот код, чтобы решить, существует ли файл,

if (!this.RouteExistingFiles) 
{ 
    string appRelativeCurrentExecutionFilePath = httpContext.Request.AppRelativeCurrentExecutionFilePath; 
    if (((appRelativeCurrentExecutionFilePath != "~/") && (this._vpp != null)) && (this._vpp.FileExists(appRelativeCurrentExecutionFilePath) || this._vpp.DirectoryExists(appRelativeCurrentExecutionFilePath))) 
    { 
      return null; 
     } 
} 

Вы не сможете решить, является ли запрос статическим в Application_BeginRequest с использованием контекста.потому что модуль маршрутизации может изменить обработчик, и этот модуль всегда выполняется после Application_BeginRequest. Мое предложение - использовать тот же код, который использует механизм маршрутизации ASP.NEt.