Изоляция в многопользовательском приложении ASP.NET

Я создаю многопользовательское приложение ASP.NET. Учитывая, что каждый арендатор может динамически настраивать свое приложение (которое может включать динамические пользовательские сборки, загружаемые в память), мне нужен способ изолировать каждого арендатора.

Я бы предпочел не создавать новое веб-приложение для каждого арендатора по причинам обслуживания.

Я рассматривал возможность использования AppDomainManager для создания AppDomain для каждого приложения, но, похоже, это не предназначено для использования в приложениях ASP.NET.

Есть ли у кого-нибудь предложения по этому вопросу?

Спасибо.

ОТВЕТЫ

Ответ 1

Я предполагаю, что вопрос: если вы не создаете веб-приложение, то какой тип изоляции действительно вам подходит?

Если вам действительно нужна гарантия уровня ОС, что сборки не будут работать друг с другом, я бы предоставил каждому свое веб-приложение. Это особенно актуально, если вы разрешаете людям загружать сторонние сборки и, что особенно важно, если эти сторонние сборки могут найти способы создания неуправляемого кода.

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

Ответ 2

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

Один... Таким образом, корневой URL-адрес останется прежним. Два... Создание VDir или экземпляр приложения. Какой из них должен быть динамичным? Три... У меня нет опыта.

Если бы мне пришлось делиться страницами, [на основе приложений, размещенных в разных VDir], я бы пошел на создание нового VDir для всех моих общих страниц. И используйте специальный код для отображения связанных с приложением данных.

Ответ 3

Я написал многопользовательское веб-приложение в MVC2. Добавление/удаление учетной записи так же сложно, как добавление/удаление строки в таблице, поскольку я выбрал общий доступ к базе данных, общий подход схемы.

Это очень хорошая статья о дизайне базы данных с несколькими арендаторами из MSDN: Архитектура данных с несколькими арендаторами

Все, что мне нужно было сделать в MVC, - это правильно настроить маршрутизацию, поэтому первая часть пути - это имя учетной записи:

  • www.yourdomain.com/Account1/...
  • www.yourdomain.com/Account2/...
  • www.yourdomain.com/Account3/...

и у меня есть пользовательский MvcHandler для поиска учетной записи для каждого запроса:

public class AccountMvcHandler : MvcHandler
{
    public AccountModel Account { get; set; }

    public AccountMvcHandler(RequestContext requestContext)
        : base(requestContext)
    {
    }

    protected override IAsyncResult BeginProcessRequest(HttpContextBase httpContext, AsyncCallback callback, object state)
    {
        string accountName = this.RequestContext.RouteData.GetRequiredString("account");
        Account = ServiceFactory.GetService<IAccountService>().GetAccount(accountName);

        // URL doesn't contain valid account name - redirect to login page with Account Name textbox
        if (Account == null)
            httpContext.Response.Redirect(FormsAuthentication.LoginUrl);

        return base.BeginProcessRequest(httpContext, callback, state);
    }
}

Как было сказано Андреасом Паулссоном, ключевая фраза - "пользовательские сборки". Зачем вам нужны "настраиваемые сборки" для настройки? Вы используете CodeEmit? Будут ли пользователи загружать их? Я бы предпочел использовать Windows Workflow Foundation для любой клиентской бизнес-логики.