FormsAuthentication.SetAuthCookie не устанавливает путь или домен?

Question

У меня есть веб-приложение, которое можно установить на множество доменов и путей.

Итак:

• client1Name. {MySite.com}
• client2Name. {MySite.com}
• демо. {MySite.com} / prospect1Name
• демо. {MySite.com} / prospect2Name
• демо. {MySite.com} / prospect3Name

Все отдельные экземпляры приложения одного и того же кода.

Проблема заключается в том, что если клиент входит в систему client1Name. {MySite.com} , а затем посещает один из других сайтов, его браузер отправляет файл cookie аутентификации.

Во всех случаях FormsAuthentication.SetAuthCookie не устанавливает ни Path, ни Domain.

Что бы я ожидал, это:

• client1Name. {MySite.com} - Domain = client1Name. {MySite.com} Path = /
• client2Name. {MySite.com} - Domain = client2Name. {MySite.com} Path = /
• demo. {MySite.com} / prospect1Name - Domain = demo. {MySite.com} Path = / prospect1Name
• demo. {MySite.com} / prospect2Name - Domain = demo. {MySite.com} Path = / prospect2Name
• demo. {MySite.com} / prospect3Name - Domain = demo. {MySite.com} Path = / prospect3Name

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

Я что-то упустил? Есть ли способ заставить FormsAuthentication.SetAuthCookie установить Path и Domain?

Если нет, то как лучше всего динамически читать лучшие Path и Domain? Один и тот же код должен выполняться на всех сайтах, и я не хочу добавлять дополнительный ключ конфигурации.

Обновление

Вот мое текущее решение:

// replacement for FormsAuthentication.SetAuthCookie(user.UserName, false);
// as that fails to limit the cookie by domain & path and fails.

var cookie = FormsAuthentication.GetAuthCookie(username, false);
cookie.HttpOnly = true;
cookie.Path = this.Request.ApplicationPath;
cookie.Secure = string.Equals("https", this.Request.Url.Scheme, StringComparison.OrdinalIgnoreCase);

// the browser will ignore the cookie if there are fewer than two dots
// see cookie spec - http://curl.haxx.se/rfc/cookie_spec.html
if (this.Request.Url.Host.Split('.').Length > 2)
{
    // by default the domain will be the host, so www.site.com will get site.com
    // this may be a problem if we have clientA.site.com and clientB.site.com
    // the following line will force the full domain name
    cookie.Domain = this.Request.Url.Host;
}

this.Response.Cookies.Add(cookie);

Тем не менее, это похоже на много обходных путей, которые FormsAuthentication.SetAuthCookie должен уметь делать. Это действительно лучший способ?

Answer 1

Мне пришлось много копать, но похоже, причина в том, что FormsAuthentication.SetAuthCookie не поддерживает это, потому что не должно - IIS должен никогда задать пути к файлам cookie для аутентификации, и вот почему ...

Пути к файлам cookie чувствительны к регистру , поэтому:

• http://site/path
• http://site/PATH

Это 2 разных куки для браузера - ни один из них (IE, FX, Safari, Opera или Chrome) не отправит куки /PATH на /path или наоборот.

IIS нечувствителен к регистру , но всегда сбрасывает URL в регистр имени приложения ASP.

Это означает, что если приложение IIS называется «PATH»и пользователь переходит на http://site/path, после чего он будет перенаправлен на вход в http://site/PATH/LogOn?ReturnUrl=/path IIS / ASP.Net

. После успешного входа пользователь перенаправляется обратно на указанный ReturnUrl., так:

1. Пользователь переходит на http://site/path
2. Получает отправку на http://site/PATH/LogOn?ReturnUrl=/path по IIS
3. Вводит данные для входа и отправляет
4. Response устанавливает cookie на /PATH, а местоположение на /path (как определено ReturnUrl)
5. Перенаправлено обратно на http://site/path
6. Браузер не распознает /path,он имеет cookie только для /PATH, поэтому ничего не отправляет!
7. Нет файлов cookie, отправленных приложению, поэтому он перенаправляет обратно на http://site/PATH/LogOn?ReturnUrl=/path
8. Перейти кшаг 2 и повторите.

Это создает проблему для пользователей, если у них есть http://site/path в качестве URL для приложения, которое они никогда не смогут войти в систему.

В дополнение к этому, если они уже вошли в систему http://site/PATH и получили URL-адрес, скажем, по электронной почте http://site/path/resource/id, им будет предложено снова войти в систему и они не смогут перейти на новыйpath.

Это означает, что, если вам не нужны /PATH и /path, чтобы быть совершенно разными сайтами (маловероятно, что за пределами определенных сред только UNIX), вы никогда не должны устанавливать свойство пути в куки аутентификации.

Answer 2

Файл cookie устанавливается на уровне домена и является статическим.По умолчанию FormsAuthentication использует TLD для его установки, в данном случае {mySite.com}.Чтобы сделать его конкретным, вы должны указать ему использовать client1Name.{mySite.com}.Однако при этом вы ограничите использование cookie этим конкретным поддоменом, и поддомен client2Name больше не сможет получить доступ к cookie.

Путь файла cookie ограничивает подпапку, к которой относится файл cookie.В случае FormsAuthentication снова по умолчанию установлен корень /.Вы можете вручную установить его на что-то другое, но, опять же, установив его на /prospect1Name, все другие папки немедленно потеряют доступ к cookie.

Я не уверен, какое поведение вы пытаетесь создать, используя этиограничения, но маловероятно, что cookie является подходящим инструментом для этого.Взлом доменов ограничит эффективность ваших средств проверки подлинности (если это не то, что вы пытаетесь сделать).