Вероятно имеется ввиду аутентификация пользователя а не авторизация. Если используемые провайдеры для хранения используют куки (и они совместимы), тогда можно сделать для поддоменов и домена (например forum.app.com и app.com), при этом куки в обоих приложениях сохраняем для app.com и MachineKey (требуется для расшифровки куков) у приложений должен быть одинаковым. К сожалению пример могу показать только для Microsoft.AspNet.Identity.
Денис Кутовский: Какая версия Microsoft.AspNet.Identity ? Должно быть public partial class ApplicationDbContext : IdentityDbContext. partial нужно руками добавить.
heartdevil: Надо знать где и как храниться сессия, может менеджер при каждом запросе сериализует коллекцию элементов, тогда последний запрос затрет все изменения, которых не было на момент десериализации. И уточни какой List ? System.Collections.Generic.List not thread safe т.е. работать с ним из разных потоков не стоит.
heartdevil: 1. Да, берется свободный поток если есть, иначе запрос "ждет" в очереди.
2. AddItem/RemoveItem должны работать с потокобезопасным контейнером из System.Collections.Concurrent или нужно их синхронизировать.
3. Я не знаю, что отправляется на сервер - элемент или коллекция, если 1 элемент то нормально, но если коллекция то плохо.
4. Порядок обработки запросов никто не гарантирует т.е. если даже с клиента пришли add/remove/add/remove/add/remove то могут выполняться remove/remove/remove/add/add/add о последствиях не трудно догадаться.
5. В каком порядке с сервера придут ответы тоже не надо закладываться может в таком add/add/add/emove/remove/remove.
ЗЫ так что лучше синхронизировать запросы на клиенте - не отправлять следующий ajax запрос пока не получен ответ от предыдущего.
heartdevil: ASP.NET использует несколько потоков для обработки запросов. Если запрос пришёл раньше чем обработан предыдущий (например: клиент/браузер не ждет окончания ajax-запроса с сервера и вполне может послать еще один ajax-запрос при клике на следующей галочке, если не понятно то читаем про асинхронность js) то он будет обработан в другом потоке. Допустим при этом в менеджере коллекция сериализуется из сессии тогда методы AddItem и RemoveItem по сути работают с разными экземплярами коллекции, т.е. с той версией, которая была отправлена с клиента в момент запроса, но до получения предыдущего результата. Что делать смотри выше.
Вадим Ш.: Согласен должно помочь. Еще как вариант можно попробовать в менеджере использовать статические потокобезопасные коллекции (System.Collections.Concurrent).
Поясни зачем тебе "статический класс менеджер" - обычно ASP приложения stateless.
"множество подряд идущих аякс запросов" обрабатываются параллельно, это учтено в логике менеджера ?
Зачем хранить выделенные записи, когда всегда можно получить список выделенных записей на клиенте и отправить не сервер ?
TimeCoder: Я бы не стал отправлять письма с использованием WebAPI, а просто завел WebJob, который запускается по расписанию, получает из базы список адресов и отправляет по ним письма никакой аутентификации и авторизации получателя не нужно, для отправки письма тебе нужен просто логин и пароль на почтовом сервисе хоть на gmail (1000 писем в сутки можно отправить).
