Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Вопрос про asp.net, web.config и печенье

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Есть веб приложение asp.net в котором ряд пользователей хочет работать под одним логином. Их желание уже не обсуждается.

Я настраиваю состояние сессии тривиальным образом

<sessionstate mode="InProc" stateconnectionstring="tcpip=127.0.0.1:42424" statenetworktimeout="10" sqlconnectionstring="data source=127.0.0.1;Integrated Security=SSPI" sqlcommandtimeout="30" customprovider="" cookieless="UseCookies" cookiename="ASP.NET_SessionId" timeout="20" allowcustomsqldatabase="false" regenerateexpiredsessionid="true" partitionresolvertype="" usehostingidentity="true">
      <providers>
        <clear/>
      </providers>
    </sessionstate>

то есть я считаю что в праве расчитывать на то, что если cookies отключены у клиента то он просто не будет их использовать. Вместо этого приложение начинает работать в режиме

cookieless="UseUri"

то есть выдавать идентификатор сессии в адресной строке.

причём, уже для всех пользователей сохраняется одна и та же сессия. (Это описано в книжке но всё равно не приятно)

обнаруживаю что в

<authentication mode="Forms">
      <forms loginurl="~/login.aspx" defaulturl="Default.aspx"/>
    </authentication>

cookieless по дефолту установлен в cookieless="AutoDetect", что видимо и приводило к такому поведению при отсутствии печенья у кого то из пользователей.

меняю его принудительно на cookieless="UseCookies"
заодно по выходу добавляю

Session.Abandon();
        Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", ""));

Остаётся вопрос — почему web.config несмотря на конкретное указание в каком режиме работать с печеньем продолжает искать дефолтные, скрытые тэги и вести себя в соответствии с ними а не с конкретным указанием.

Да — authentication mode расположено ниже чем sessionState, но это же не повод заменять дефолтным параметром конкретно установленный. Или повод?

Чтоб два раза не вставать — Есть структура каталога в IIS, объявляю одну внутреннию папку application. Но при этом вышестоящий application считает все web.config внутренних папок своим и соответственно наследует всё что находит. Можно ли как то объяснить IIS что это уже не папки главного приложения, а самостоятельное, независимое приложение и брать web.config отттуда не надо?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Новые улики.
Причина самопроизвольного изменения в использовании cookie для хранения состояния, предположительно крылась в исчерпании ресурсов приложения.
У меня очень сложная корзина в приложении и я вынужден был хранить её в Session как сериализованный объект.
Видимо это приводило к использованию всей отпущенной памяти на хостинге.

Возникает закономерный вопрос — почему при установленном timeout="20″ ресурсы конкретной сессии после её завершения не освобождаются автоматически? Может это где-то настраивается и дело конкретно в объекте который запихнут в Session?

В любом случае проблему удалось решить добавив в Global.asax.cs

protected void Session_End(object sender, EventArgs e)
{
Session.Clear(); //Параноя ?
Session.Abandon();
}

Теперь, даже несколько юзеров бросивших своё приложение на ночь открытым, не вызывают переполнения памяти (Которое не доказано полностью, потому что приложение не вываливалось, а продолжало работать)

Но вопросы и некоторая неуверенность осталась

Опять эти дотнетчики набежали....

Дядя, не нравится не кушай. А то у меня чувство, что меряться прибежал.

Можно ли как то объяснить IIS что это уже не папки главного приложения

веб.конфиги объединяются друг с другом. и вообще — берется из корневой папки фреймворка machine.config, мешается с лежашим там web.config, потоммешается с web.config из корневой папки сервера, потом мешается с web.config из текущей папки, откуда запрашивается серверный скрипт

Видел же, в секциях тег <remove ?="" Это="" ж="" как="" раз="" для="" того,="" чтобы="" ранее="" неявно="" объединенные="" конфигурации="" удалять.="">

p.s. какой забавный баг на форме поста

а самостоятельное, независимое приложение

оно не самостоятельное — просто тебе похожде мешают http модули, в частности не помню как называется — что-то с FormAuthentification. Убери в своем конфиге через тэг remove

Есть веб приложение asp.net в котором ряд пользователей хочет работать под одним логином. Их желание уже не обсуждается.

а автогенерируемые кукисы небось одинаковые хочешь? :)

это понятно. В рамках приложения, я надеялся. Но я сказал IIS что эта папка /test является самостоятельным приложением. Он согласился и она и работает как приложение. Но вышестоящее продолжает собирать все конфиги из нижестоящего как будто это просто вложенные папки одного приложения.

Самостоятельное — это типа на папке указал, что это — приложение? Через IIS manager правым кликом мыши? :)

ак будто это просто вложенные папки одного приложения.
а так оно и есть, разве по-другому? ApplicationPool общий на сайте и этом приложении?

Ну да, ерунда получается. Надо что то по IIS дочитать.

Естественно ерунда — на множество запросов от разных пользователей один HttpHostingEnvironment, контекст, один Session_ хэндлер в global.asax, срабатывающий только один раз ...

Вот, можешь почитать msdn.microsoft.com/...y/ms178473.aspx

Он согласился и она и работает как приложение
такое, по-моему делается, если только собираешься там хостить именно приложение — WCF под IISом

Я так и удаляю но это же геморой

а автогенерируемые кукисы небось одинаковые хочешь? :)

Я хочу, точнее хотел, про них вообще ничего не знать — других забот выше крыши, но видимо придётся и тут копать.

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

Я хочу, точнее хотел, про них вообще ничего не знать
зачем тебе вообще кукис сессии? для тебя это — прозрачно.
Насколько я понял работу сервера
ссылка выше даст тебе исчерпывающий ответ. Хочешь, можешь написать свой кастомный сешн провайдер — technet.microsoft.com/...2(v=ws.10).aspx
но че то мне кажется, ты сильно заморачиваешься

Ты хочешь спросить зачем мне InProc ? Кукис потому что InProc, а InProc потому что когда последний раз эксперементировал с SQLServer то визуально подтормаживало.

Какую вообще ты хочешь решить задачу — чтобы у всех всех всех пользователей была одна сессия? Или это все-таки как вариант той задачи, которую решаешь?

Если тормозит из-за объема кукисов чисто — это тоже решаемо (например, идет туева хуча запросов при заказчке картинок, скриптов и т.д. и миллион запросов дает около 20 гигабайт ненужного трафика — там кукисы естественно не нужны и есть готовый вариант для хай-лоад решения)

У каждого, юзера даже под одним и тем же логином, своя сессия. Вопрос состоял в том, что если у одного из них нет кукисов то приложение переключается в режим UseUri для всех и ещё и с одной сессией, хотя я категорически запретил UseUri. Пока думаю, что дело было в дефолтной настройке секции authentication в которой по умолчанию скрытый AutoDetect.

Попробуй
technet.microsoft.com/...4(v=ws.10).aspx
и убери из своего конфига соотв. изменения перед этим,

и только руками в конфиги фреймворка не лазь :)

Мне как раз не нужен Uri. Мне нужен UseCookies а если кукисов нет то «давай досвиданья». А скрытый AutoDetect ставил UseUri при отсутствии кукисов у клиента.

а если кукисов нет то «давай досвиданья»

Тебе всего — лишь давай досвиданья, если в браузере отключена поддержка кукисов? Так проще пареной репы: напиши HTTPModule, повесься на события BeginRequest и EndRequest: EndRequest выставляет кукис, BeginRequest проверяет, а есть ли кукис. Если кукис был выставлен (в EndRequest), а в браузере поддержка кукисов отключена (там значит в обработчике события сендера приводишь к HttpApplication, и из его HttpContexta смотришь Request.Cookies["blablabla«] — отключена поддержка — коллекция кукисов будет пустой, т.е. равна нулю, или же именно если твоего кукиса не будет) — давай досвиданья. И желательно смотреть и выставлять кукисы, чтобы было быстрее, только когда у тебя идет content-type «text/html» — ну нафиг тебе кукисы на «img/png», к примеру, лишняя нагрузка, верно?

Ну или может EndRequest — это для тебя если очень поздно — выбери любое подходящее по жизненному циклу запроса, ссылку я тебе бросал.

Ну это — мой способ, я использую для проверки капчи, которая сделана на уровне инфраструктуры сайта — я его упоминал в топике про серверную валидацию (давай досвиданья, а именно 403 «Forbidden» еще до входа в хэндлеры — я на бегин реквест читаю, а что мы запостили, и верно ли это, согласно глобальному значению капчи для всего апппула, если значение капчи введено неверно или не вводилось, а его контроллер как аргумент ожидает) А еще делают так — зашел на страницу — она вернула ответ с кукисом, а сразу в body первым делом — location.href перенаправляют браузер на страницу, которая читает кукисы. Если кукиса нет — давай досвиданья. А если еще и клиентские скрипты отключены — то у главного контейнера на странице style="display: none", а сразу после боди стоит разметка <noscript>Давайдосвиданья</noscript> — заодно и проверишь, а не отключены ли клиентские скрипты у клиента (нафиг вообще скрипты и кукисы отключают) Но мне кажется, вариант со скриптом геморный — это ж на каждую страницу как-то либо в мастерпейдже, либо еще как-нить чтоб не провтыкать скрипт нужно явно ставить, а потом еще и реферера читать, чтоб перенаправить обратно.

то визуально подтормаживало

а оттрассировать не пытался? там же время выполнения на каждом этапе тебе покажет. а может то просто аппдомен при первом запросе создавался :)

Не пытался, потому, что в книжке так и написано — самый медленный, но самый надёжный.

в книжке так и написано

книжки — это зло :) Вот в одной книжке рассматривался DI контейнер для фабрик контроллеров под MVC. Я целый день с этим продолбался — качал бинарники, исходники, смотрел почему работает не так, как в книжке... А блин кто помешал автору просто вместо контейнера сделать все описание в web.config? :) Выходило то же самое.

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

Лучше отдельным топиком исходники а то тут места уже нет. Может заодно какие монстры подтянутся.

Підписатись на коментарі