Поставщик членства ASP.NET - единственный вход в систему

Я рассматриваю использование Поставщика Членства ASP.NET для нескольких различных веб-приложений/инструментов с единственным подходом входа в систему.

ТРЕБОВАНИЯ

Пользователь входит в систему my.domain.com и видит список приложений/инструментов, которые у них есть разрешение использовать. Пользователь выбирает инструмент, который они хотели бы использовать и нажимают на ссылку. Когда инструмент открывается, он может определить, что они в настоящее время зарегистрированы и кто они должны определить любые уникальные полномочия к приложению.

Я знаю, что каждое приложение могло просто указать на того же Поставщика Членства в бэкэнде на DB, однако каждое приложение потребует входа в систему, или это сможет определить, зарегистрирован ли пользователь уже?

7
задан RSolberg 10 February 2010 в 20:48
поделиться

3 ответа

Каждое приложение может использовать один и тот же логин, если ApplicationName одинаково и они указывают на одну и ту же базу данных.

См. Ответ здесь: http://forums.asp.net/t/1322863.aspx для получения дополнительных сведений.

Изменить - добавлено

Это также описано здесь:

http://msdn.microsoft.com/en-us/library/ms998347.aspx

4
ответ дан 7 December 2019 в 12:19
поделиться

Для согласованного поведения в нескольких операционных системах. Это портативность.

В некоторых других unix-средах, отличных от Linux, или если ваша программа скомпилирована в Windows, некоторые из этих функций могут не существовать или вести себя иначе в целевой операционной системе.

Использование версий glib обеспечивает непротиворечивое поведение.

-121--1390121-

Ответ на утверждение носкло (см. другие комментарии к этому вопросу), что это невозможно сделать без close _ fds = True :

close _ fds = True , необходим только в том случае, если вы оставили другой файл дескрипторы открыты. При открытии нескольких дочерних процессов всегда полезно сохранять трек открытых файлов, которые могут наследоваться, и явно закрывать любые которые не нужны:

from subprocess import Popen, PIPE

p1 = Popen(["grep", "-v", "not"], stdin=PIPE, stdout=PIPE)
p1.stdin.write('Hello World\n')
p1.stdin.close()
p2 = Popen(["cut", "-c", "1-10"], stdin=p1.stdout, stdout=PIPE)
result = p2.stdout.read() 
assert result == "Hello Worl\n"

close _ fds по умолчанию имеет значение False , поскольку подпроцесс предпочитает доверять вызывающей программе знать, что она делает с открытым файлом дескрипторы и просто предоставить вызывающему возможность закрыть их все если это то, что он хочет сделать.

Но реальная проблема заключается в том, что буферы труб будут кусать вас для всех, кроме игрушечных примеров. Как я уже сказал в своих других ответах на этот вопрос, правило большого пальца не открывать устройство чтения и устройство записи в одном процессе/потоке. Любой кто хочет использовать подпроцессный модуль для двусторонней связи, будет хорошо служил для изучения os.pipe и os.fork, сначала. На самом деле они не так трудно использовать, если есть хороший пример для просмотра.

-121--1307713-

Если средства находятся в одном домене/поддомене, проблем не возникнет. Это ограничение файлов cookie, используемых для хранения маркера зарегистрированного пользователя. Если требуется междоменное унифицированное имя входа, можно просмотреть Windows Identity Foundation .

0
ответ дан 7 December 2019 в 12:19
поделиться
  1. Вам нужно создать общий раздел machineKey , который будет использоваться всеми сайтами.

  2. Убедитесь, что имена приложений идентичны.

  3. Убедитесь, что строки подключения идентичны.

  4. Убедитесь, что включен элемент allowCrossAppRedirects в формах.

1
ответ дан 7 December 2019 в 12:19
поделиться
Другие вопросы по тегам:

Похожие вопросы: