Сделать фоновый сервер в ASP NET проекте - не очень хорошая идея.
Sergey В., это в ASP.NET Core до 3.0, пока приложение использовало Web Host, могло быть не очень хорошей идеей (и то, справлялись, и у MS даже было документировано, как это сделать). После же перехода на Generic Host в 3.0 фоновые процессы стали штатной частью приложения (собственно, само веб-приложение именно так устроено). И автор вопроса эту, совершенно штатную, возможность как раз использует, с помощью ппредназначенного кдля этого класса BackgroundService.
Про какой веб-сервер вы гоорите - непонятно: по умолчанию приложение ASP.NET Core - сам себе веб-сервер (по умолчанию используется Kestrel). А если кто-то вдруг захочет убить ваш процесс (оркестратор?) - настройте этого "кого-то", чтобы не своевольничал. Кстати, оснований считать такой процесс зависшим нет: на всякие пробы здоровья по HTTP ему отвечать ничто не помешает.
На стр. 54 внимания не обращайте, это всего лишь часть стека вызовов, который привел к ошибке. Сосредоточьтесь на последнем вызове из вашего кода, приведшем к ошибке - стр.143 и выясняте, почему так получилось.
, ну если удалю update и сделаю новую на основе main.
Dyikot, а изменений в update вам не жалко? Если жалко - просто сделайте git rebase: он вам и update на основе main создаст, и изменения сохранит. Ну, а если не жалко - можно и так сделать.
"Эту" - это какую? Которая "на всякий случай" - удалить. Эти ваши commit отмены и отмены отмены будут удалены при следуюшей сборке мусора в репозитории. А с update делайте то, что вы обычно делаете, она тут не при делах.
PS А вообще, ветка - это указатель на голову цепочки commit'ов и ничего более.
PPS Если чего-то опасаетесь - сделайте копию папки .git, в случае чего - вернете обратно.
Ничего не понял: что за HttpSession и причем оно тут? В C# вы работаете с сессией с интерфейсом ISession - вот и пишите про него.
Ответьте на вопросы, которые я задал раньше. Значение c ключом Id в сессии - оно откуда у вас должно взяться? Вы посмотрели, там, где вы его устанавливаете, что свойство Id интерфейса ISession совпадает там и в вашем фильтре авторизации? Если совпадает, то на куку сессии в браузере вообще можете не смотреть: там все работает.
PS Про вызов метода CommitAsync: можете не заморачиваться. Я посмотрел исходник: обработчик в конвейере middleware, который устанавливает сессию, вызывает его сам.
Nik Faraday, прежде всего, посмотрите в новом обработчике тот самый ISession.Id (context.Session.Id) и сравните со значением из старого запроса. Если не совпадают, то у вас что-то с кукой сессии. Жмите F12 в браузере и смотрите - получает ли он куку, отсылает ли.
Во-вторых, где вы в сессию значениt записываете? Если в обработчике предыдущего запроса - то вызвали ли вы там ISession.CommitAsync и выполнился ли он нормально?
Nik Faraday, а чо бы вам не разобраться-то?
Сессия - это просто: это - словарь пар "ключ(строка)-значение(массив байтов)", хранящийся в распределеннном кэше. Доступ к сесссии из кода обработчика на сервере - через свойство HttpContext.Session, это работает, как именно - можете даже не заморачиваться.
Значения обычно устанавливаются и излекаются методами расширения для ISession, которые сериализуют/десереализуют значения в соответствии с их типом. Какая именно сессия используется - определяется значением куки с определенным именем (задается в настройках): в этом значении содержится зашифрованный Id сессии. Тут, похоже, я попутал - вы хотите работать не с Id сессии, а со значением под ключом "Id". Так?
Однако, при настройках по умолчанию (и при ваших - тоже) никакой код JS (и React, в частности) к этой куки доступ не имеет: она - HttpOnly. И, в любом случае, к значениям, хранщимся в сессии, код JS доступ иметь не может в принципе: они на клиент не передаются. На клиенте (причем, обычно - в виде, недоступном для JS) есть только идентификатор сессии, чтобы можно было найти ее (и ее данные) в обработчике на сервере. Разве что, вы на клиенте через API (т.е. специальный обработчик) доступ к этим данным сделаете.
PS Дальше обсуждать не хочу, потому что не понимаю, что вообще вы пытаетесь там сделать. Вижу только, что вы хотите странного.
Баюшки пора, поэтому подробно посмотрю и наводящие вопросы задам завтра. Мне вот на первый взгляд непонятно, какую куку вы получить хотите - которую механизм сессий устанавливает, или какую-то другую?
А пока что - простой вопрос: а что это вы так сложно, я бы сказал - трансректально (надеюсь, не обидел, если что - извиняйте) извлекаете Id сессии? Ведь в HttpContext есть свойство Session содержащее ссылку на объект сессии. Просто читайте context.HttpContext.Session.Id (вопросительные знаки добавить по вкусу) - и вот он, ISession.Id перед вами.
PS Технически реализация HttpContext извлекает ссылку на ISession из коллекции функций (Features), куда ее помещает соответсвующий обработчик в конвейере (middleware). Так что все эти манипуляции с сервисом - они совершенно не требуются. К сожалению, механизм функций (Features) HttpContext в его общем виде описан в документации плохо (а в учебниках - обычно, никак), а жаль: очень полезная вещь для тех, кто делает компоненты для конвейера.
Outgoing claim type: как нашёл в интернете, установил Authentication method.
Kornev888, у меня есть серьезное подозрение, что нашли вы что-то не то: обычно этот тип утверждений используется по-другому. Но искать самому откровенно лень. Может, вам стоит искать не в интернетах, а в документации NEXTCLOUD, какие именно типы утверждений оно ожидает, а потом настроить нужные правила в ADFS? Тип утверждения - это URI, так что при необходимости типы можно сопоставить точно, а не по сходству названий.
В общеупотребительной терминологии ("грамотно") никаких таких "параметров" у домена нет - а есть там в домене записи разных типов и с разными именами (в т.ч. - совпадающими с именем домена). Поэтому, не владея телепатией, мы тут вам в вашей беде помочь не сможем - просто потому, что не понимаем, что вам нужно.
Так что у вас есть два выхода: либо сформулировать вопрос грамотно, либо ждать телепатов.
Есть, правда, ещё один вариант - вы честно и откровенно рассказываете, откуда вы взяли такие дивные формулировки (ссылки, явки, пароли ;-) ), а мы (может быть) поможем вам изложить вашу беду грамотно.
sertaliano, так быть не должно. Проверяйте, откуда пользователь получает разрешение. На вкладке Безопасность в свойств в окне, выхываемом по кнопке Дополнительно есть вкладка Действующие разрешения, где это проверить удобно.
Process Monitor.
А ещё ядро Windows может писать все происходящие в нем события в лог трассировки ETW, и если вы научитесь с ним работать, то можно использовать его.
OwDafuq, ну, дык, я рад, что мои предположения не оправдались. Т.е. слой логики приложения у вас не завязан однозначно на EF (ну, разве что, вы свой IUnitOfWork определили так, что иначе, как через EF, его не реализуешь).
Если так, то у вас вообще всё шоколадно и беспокоиться в этом вопросе не о чем: EF сейчас даст вам эти самые Repository и UoW, а если потом от EF придется уйти, то вы их реализуете самостоятельно, не трогая логику приложения.
Формат даты может содержать неоднозначность в порядке указания месяца и числа.
Поэтому рекомендую для начала указать начало и конец периода на одну дату с разными числом и номером месяца, причем число должно быть меньше 12, а потом посмотреть (в EMS или в Outlook), на какой день пришелся период.
Смотрите другие события с источником MSExchangeTransport: всякие падения и перезапуски служб транспорта в этих событиях отображаются. Ну, и смотрите, движется ли очередь.
Если вы решили писать для современного ASP.NET Core, то имейте в виду, что старомодные HTML helpers (как у вас) вышли из моды, вместо них стильно, модно и молодёжно использовать tag halpers (в шаблоне Razor они выглядят как обычный HTML). По их написанию документация здесь.
Роман Безруков, все так. А из того, что надо не забыть, если исходный КД был в инфраструктуре не единственным: после восстановления надо удалить из AD все остальные КД и захватить отсутствующие на восстановленном КД роли FSMO. Ну и восстанавливать КД (точнее, DFS на нем) надо в полномочном режиме (не знаю, как в Veeam, а в Windows Server backup для этого есть галочка): иначе он может себя не объявлять КД.
Вася Пупкин, если резервная копия достаточно свежая (моложе 30 дней - это с гарантией) и если восстанавливать ее поддерживаемым способом (т.е. не просто накатыванием образа Acronis на железный КД), и даже - неподдерживаемым, но на виртуалку на современном, поддерживающим идентификацию VM гипервизоре, то проблем не будет. Если резервная копися старше (но восстановлена поддерживаемым способом), то проблемы возможны, но они решаемы.
Однако поднять новый КД взамен отказавшего действительно проще, и, есди есть возможность делать так - нужно так и делать.
Впрочем, одиночный КД можно восстанавливать как угодно и из чего угодно: ему реплицироваться ни с чем не надо. Так что вы ответили тут не на тот вопрос, который был задан.
Sergey В., это в ASP.NET Core до 3.0, пока приложение использовало Web Host, могло быть не очень хорошей идеей (и то, справлялись, и у MS даже было документировано, как это сделать). После же перехода на Generic Host в 3.0 фоновые процессы стали штатной частью приложения (собственно, само веб-приложение именно так устроено). И автор вопроса эту, совершенно штатную, возможность как раз использует, с помощью ппредназначенного кдля этого класса BackgroundService.
Про какой веб-сервер вы гоорите - непонятно: по умолчанию приложение ASP.NET Core - сам себе веб-сервер (по умолчанию используется Kestrel). А если кто-то вдруг захочет убить ваш процесс (оркестратор?) - настройте этого "кого-то", чтобы не своевольничал. Кстати, оснований считать такой процесс зависшим нет: на всякие пробы здоровья по HTTP ему отвечать ничто не помешает.