Содержание

Aspnet пользователь что это

Как получить текущего пользователя в ASP.NET в MVC

в модели форм я использовал, чтобы получить текущего вошедшего пользователя:

Как мне получить текущего пользователя внутри класса контроллера в ASP.NET MVC?

19 ответов:

Если вам нужно получить пользователя из контроллера, используйте User свойства контроллера. Если вам это нужно с точки зрения, я бы заполнить то, что вам конкретно нужно в ViewData , или вы можете просто позвонить пользователю, как я думаю, что это свойство ViewPage .

Я нашел это User строительство, то есть User.Identity.Name или User.IsInRole(«Administrator») .

Public Shared Property Current () As Система.Сеть.HttpContext
члены системы.Сеть.HttpContext

резюме:
Возвращает или задает систему.Сеть.Объект HttpContext для текущего HTTP-запроса.

Возвращаемые Значения:
система.Сеть.HttpContext для текущего HTTP-запрос

вы можете получить имя пользователя в ASP.NET MVC4 вот так:

Я понимаю, что это действительно старый, но я только начинаю с ASP.NET MVC, поэтому я подумал, что засуну свои два цента в:

Request.IsAuthenticated говорит вам, если пользователь аутентифицирован.
Page.User.Identity дает вам идентификатор пользователя, вошедшего в систему.

Я не уверен, что это будет работать в ASP.NET MVC, но это стоит попробовать:)

вход в систему имя пользователя: System.Web.HttpContext.Current.User.Identity.Name

чтобы ссылаться на идентификатор пользователя, созданный с помощью простой аутентификации, встроенной в ASP.NET MVC 4 в контроллере для целей фильтрации (что полезно, если вы используете database first и Entity Framework 5 для создания Привязок Code-first, а ваши таблицы структурированы так, что используется внешний ключ к идентификатору пользователя), вы можете использовать

после добавления оператора using

но если вам нужно получить только идентификатор, вы можете использовать:

таким образом, вы можете получить непосредственно идентификатор пользователя:

вам просто нужно User.Identity.Name .

это приведет к текущему вошедшему в систему пользователю Windows.

для чего это стоит, в ASP.NET MVC 3 Вы можете просто использовать User, который возвращает пользователя для текущего запроса.

Если вы находитесь внутри своей страницы входа, например, в событии LoginUser_LoggedIn, Current.User.Identity.Name возвращает пустое значение, поэтому вы должны использовать yourLoginControlName.Имя пользователя свойство.

если вы работаете в Active Directory в интрасети, вот несколько советов:

(Windows Server 2012)

запуск всего, что говорит с AD на веб-сервере требует кучу изменений и терпения. Поскольку при запуске на веб-сервере против локального IIS / IIS Express он работает в удостоверении AppPool, поэтому вам нужно настроить его для олицетворения того, кто попадает на сайт.

как получить текущего вошедшего пользователя в active directory, когда ваш ASP.NET Приложение MVC работает на веб-сервере внутри сети:

вы должны обернуть любые вызовы, имеющие отношение к «контексту active directory» в следующем, чтобы он действовал как среда размещения для получения информации AD:

вы должны иметь impersonate значение true в файле web.config:

вы должны иметь проверку подлинности Windows в интернете.config:

Новое в ASP.NET 2. Профили пользователей

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

Однако это задачка не из легких. Представьте, что вы — продавец большого магазина, в котором ежедневно бывает не одна сотня покупателей, а что если вы — сайт, который ежедневно просматривают десятки тысяч посетителей? Нужно ведь не просто запомнить каждого, но еще и сохранить все это, пока он не соизволит зайти к вам еще раз, чтобы вы смогли продемонстрировать ему свою феноменальную память. А что если за это время его вкусы изменились и придется все запоминать заново, проблемы растут как снежный ком. Чтобы автоматизировать задачу потребуется не одна таблица в базе данных, множество запросов к ним, да еще и куча кода, чтобы связать все воедино. Ну и тестирование, тестирование, тестирование. Задумаешься, а стоит ли овчинка выделки? Однако не все так плохо, с выходом ASP.NET 2.0 все проблемы отходят на второй план, потому что теперь он содержит новую встроенную возможность — профиль (Profile) пользователя.

Профиль пользователя

Сервис персонализации (personalization) – это новая возможность в ASP.NET, которая применялась еще в продукте Site Server. Данный сервис предоставляет готовое решение для хранения персональных данных, непосредственно характеризующих пользователя сайта, так называемого профиля пользователя (Profile). Вот несколько примеров подобных данных – это имя, фамилия, адрес электронной почты пользователя, его временная зона, а также “корзина покупателя» для пользователя сайта электронной коммерции или информация о принадлежности посетителя сайта тем или иным группам пользователей. Сейчас такие параметры обычно хранят в сессии (Session), в файлах cookie, базах данных и так далее. Независимо от места их хранения, ASP.NET 1.x мало помогает в этом случае. Приходится своими силами разрабатывать и настраивать всю инфраструктуру под соответствующее хранилище. Также самостоятельно необходимо получать эти данные и сохранять их. Коллекция Session облегчает жизнь, но она ненадежна, а хранение ее в отдельном процессе или в базе данных приводило к высоким затратам ресурсов сервера и увеличению времени отклика приложения. В сущности, сервис персонализации — это коллекция, очень похожая на сессию по своей сути. Так же, как и сессия, профиль пользователя относится к одному конкретному посетителю сайта и обеспечивает хранение информации, относящейся непосредственно к нему. Однако есть и значительные отличия, выгодно характеризующие новый сервис, среди них:

* Строго типизированный доступ к элементам коллекции: в отличие от коллекций типа Application, Session, Context, Cache, да и всех остальных коллекций, перешедших по наследству от ASP.NET 1.x, которые осуществляли доступ к значениям своих элементов по ключу, профиль пользователя – класс HttpProfile – использует строго типизированные именованные свойства, работать с которыми гораздо удобнее. Запоминать названия и типы свойств больше не нужно, теперь это удел Intellisense, который справляется с этим гораздо лучше. Другой полезный эффект — проверка типов на этапе компиляции. Например, следующий фрагмент кода демонстрирует два варианта получения даты последней активности пользователя:
o старый, с использованием сессии:
DateTime LastLogin = (DateTime)Session[“LastLogin»];
o новый, с привлечением сервиса персонализации:
DateTime LastLogin = Profile.LastLogin;
Заметьте, что во втором случае приведение типов не потребовалось, поскольку дата уже хранится как дата, а не упаковывается в object.
* Выборка данных из хранилища производится только при необходимости. В отличие от класса Session данные извлекаются не при каждом запросе страницы, занимая ресурсы сервера, а только тогда, когда в них действительно есть потребность.
* Время хранения данных не ограничено. В отличие от всех остальных коллекций, время жизни сохраненных данных в профиле бесконечно и никак не зависит ни от приложения, ни от текущей сессии. Фактически данные будут храниться вечно, если хранилище достаточно надежно и Вы сами не решите их однажды удалить оттуда.
* Данные могут храниться как для известных (зарегистрированных и прошедших аутентификацию в системе), так и для неизвестных (анонимных, то есть еще не зарегистрированных или просто не вошедших в систему) посетителей сайта.
* Доступ к атрибутам профиля осуществляется так же просто, как и при работе с коллекцией Session. Это возможно благодаря новому свойству Profile, доступному во всех производных от System.Web.UI.Control классах приложения. Либо во всех классах приложения через контекст веб-приложения, используя следующий синтаксис: System.Web.HttpContext.Current.Profile или ((ProfileCommon)System.Web.HttpContext.Current.Profile).MessagesPosted если нужен доступ к собственным свойствам профиля. ProfileCommon — это специальный класс, автоматически создаваемый компилятором при включенном профиле и содержащий все пользовательские свойства, добавленные через web.config.
* Хранилище для данных расширяемо и может быть любым. По-умолчанию в поставку ASP.NET 2.0 входит один провайдер для профиля пользователя – провайдер для Microsoft SQL Server. Но возможно и создание своего собственного провайдера данных. Для этого предлагается новая модель реализации провайдеров. Она подразумевает выделение из программного интерфейса хранилища уровня работы с данными. Так достигается возможность прозрачного доступа к любым данным, независимо от типа физического хранилища – это может быть база данных и файл на жестком диске или даже выделенный сервер данных. Подобная архитектура провайдера данных используется и в других сервисах ASP.NET 2.0. Позже мы рассмотрим пример создания собственного провайдера данных и увидим, насколько это просто. Провайдер данных может быть задан статически в файле конфигурации приложения или динамически назначен в режиме выполнения.

Давайте рассмотрим, как можно начать использовать профиль. Итак, профиль сохраняет данные о конкретном пользователе вашего сайта и позволяет затем эти получать. По умолчанию все эти данные будут сохраняться в таблицах базы данных SQL Server Express. Строка соединения по умолчанию называется «LocalSqlServer» и задана она в глобальном файле настроек machine.config. Вот как она выглядит:

то есть база данных будет работать в режиме User Instance, название файла базы данных ASPNETDB.MDF и при первой попытке сохранения профиля база данных будет автоматически создана в подпапке App_Data корневой директории сайта.

Отлично, оказывается все уже настроено, все что нам остается сделать — это описать нужные нам поля профиля в файле конфигурации приложения web.config. Настроим профиль на хранение имени и фамилии пользователя, а также счетчика его посещений нашего сайта:

По умолчанию тип параметра профиля — это System.String, поэтому, для того, чтобы хранить количество посещений сайта как число, нам необходимо явно задать его тип. Также параметр может иметь значение по умолчанию (в нашем случае это 1). Если провайдер данных не обнаружит значения параметра в хранилище данных, то будет возвращено значение параметра по умолчанию.

После того как профиль настроен, использовать его очень просто. Приведенный ниже код отображает данные из профиля текущего пользователя и обновляет их при нажатии на кнопку. Заметьте, никакого дополнительного кода для сохранения этих сведений где-либо в базе данных или получения их оттуда писать не нужно, об этом позаботится инфраструктура ASP.NET.

Расширение профиля пользователя

Профиль содержит следующие базовые параметры:

Как убрать учетную запись APS.User?

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

Дабы сразу успокоить ваши нервы от внезапной и непонятной учетной записи, уведомляем, что APS.User не представляет абсолютно никакой угрозы для вашей системы, т.е. вас никто не взламывал и не менял на вашем компьютере настройки.

Учетная запись APS.User была создана вашей системой автоматически после установки самой новой версии .NET Framework. Ее предназначение заключается в работе с определенными системными службами в вашем компьютере. Данная учетная запись имеет системный класс, что только подтверждает предыдущее высказывание.

На самом деле, некоторое время назад уже происходила похожая ситуация. Во времена Windows 7 пользователи тоже начали жаловаться на внезапно создавшуюся учетную запись, которая имела имя ASP.NET Machine Account и в придачу была еще защищена паролем. Установка .NET Framework также являлась причиной ее появления.

Нужна ли учетная запись ASP.User на вашем компьютере и будет ли у вас какие-то преимущества от этого? Не то чтобы. Ее наличие в системе никак ни на что не влияет, так же как и ее отсутствие. Однако, если она вам мешает, то ее можно запросто удалить.

Как удалить учетную запись ASP.User?

Вернемся к настоящему времени и рассмотрим следующий вопрос — как убрать ASP.User? Мы уже выяснили, что данная учетная запись не является чем-то важный для вас или системы, так что ее удаление чисто опциональный выбор.

Если у вас в системе появился пользователь ASP.User и вы хотите его удалить, то сделайте следующее:

Нажмите ПКМ на Пуск.
Выберите контекстном меню пункт «Панель управления».
Перейдите через панель управления в пункт «Учетный записи пользователей».
Далее нажмите на пункт «Управление другой учетной записью».
Затем кликаем на учетную запись ASP.User и нажимаем на опцию «Удалить».

Вот, собственно, и все, что вам требовалось сделать, что удаления внезапно появившейся учетной записи. Однако, может возникнуть сценарий, в котором вы не сможете удалить ASP.User по той или иной причине.

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

Аутентификация в ASP.NET

Written on 24 Сентября 2006 . Posted in ASP.NET

ASP.NET исполняет web-приложения под учетной записью ASPNET. Это означает, что при выполнении задачи, не предусмотренной привилегиями пользователя (например, запись файла на диск), приложение получает отказ в доступе.
Идентификация пользователей применяется в тех случаях, когда нужно предоставить доступ к разделам web -приложения только для определенных пользователей. Это может быть Internet -магазины, форумы, закрытые разделы в корпоративных Intranet -сайтах и так далее.
Безопасность в приложениях ASP.NET основана на трех операциях:

Аутентификация — процесс идентификации пользователя для предоставления доступа к какому-то ресурсу приложения (разделу сайта, странице, базе данных, :). Аутентификация основана на проверке сведений о пользователе (например, имени и пароля);
Авторизация — процесс предоставления доступа пользователю на основе данных аутентификации;
Олицитворение (impersonalisation) — предоставление серверному процессу ASP.NET прав доступа клиента.

Существует три способа аутентификации пользователей в приложениях ASP.NET:

аутентификацияWindows — применяется для идентификации и авторизации пользователей в зависимости от привилегий учетной записи пользователя. Работает аналогично обычным механизмам сетевой безопасности Windows и выполняется контроллером домена;
аутентификацияForms — пользователь вводит логин и пароль в Web -форме, после чего авторизация происходит по списку пользователей, хранящемуся, например, в базе данных. Применяется на большинстве Internet-сайтов при регистрации в Inernet -магазинах, форумах, пр;
аутентификацияPassport — все пользователи имеют единое имя и пароль, используемые для сайтов, использующих данный тип авторизации. Пользователи регистрируются в службе Microsoft Passport.

Важно отметить, что аутентификация ASP.NET применяются только для web -форм (.aspx -файлы), контролов (.ascx -файды) и прочих ресурсов ASP.NET. HTML-файлы не входят в этот список. Для авторизации доступа к HTML -файлам нужно их зарегистрировать вручную!
Тип аутентификации указывается в конфигурационном файле Web.config :

По умолчанию применяется тип аутентификации Windows. Значение None имеет смысл устанавливать если используется собственная схема аутентификации или анонимный доступ (для повышения производительности).

Аутентификация Windows

Существует 4 типа аутентификации Windows : обычная ( basic ), краткая ( digest ), встроенная ( integated ) и на основе клиентских сертификатов SSL. Обычную и краткую аутентификацию применяют для идентификации имени пользователя и пароля, указываемом в диалоговом окне. Они хорошо работают в Internet , так как данные передаются по HTTP. Базовая аутентификация передает пароль и имя пользователя в кодировке Base 64, которую легко раскодировать. Для повышения безопасности можно использовать базовую аутентификацию совместно с SSL. Базовую аутентификация поддерживают большинство браузеров.
Краткая аутентификация является более безопасной, так как пароль шифруется по алгоритму MD 5. Она поддерживается браузерами Internet Explorer 5.0 и выше, либо на клиентской машине должен быть установлен. NET Framework. Кроме этого, учетные записи пользователей должны храниться в Active Directory.
Встроенная аутентификация применяется для идентификации учетных записей Windows и не может применяться в Internet , так как клиент и сервер должны пройти проверку контроллером домена. При этом пароли по сети не передаются, что увеличивает безопасность приложения. Этот тип аутентификации блокируется файрволами и работает только с Internet Explorer. Встроенная аутентификации немного медленнее, чем базовая или краткая.
Применение сертификатов SSL так же обычно применяется в Intranet , т.к. требует раздачи цифровых сертификатов. При этом типе аутентификации пользователям не нужно регистрироваться. Сертификаты можно сопоставить учетным записям пользователей в домене или Active Directory.

Для указания способа аутентификации нужно выполнить следующие действия:
1. Запустить диспетчер IIS
2. Щелкнуть правой кнопкой мыши по приложению и выбрать в контекстном меню Свойства.
3. В появившимся диалоге перейти на вкладку Безопасность каталога и нажать кнопку Изменить в разделе Анонимный доступ и проверка подлинности.

4. В диалоге Методы проверки подлинности указать тип аутентификации.

5. Указать права доступа к папке или отдельным файлам в папке Web -приложения. Обязательно нужно разрешить доступ для пользователя ASPNET.

Для поддержки URL-авторизации при Windows-аутентификации для защиты содержимого папок применяются Web.config файлы, находящиеся в этих папках. Структура файла такова (cимвол означает всех пользователей):

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

Если мы хотим защитить он неаутентифицированных пользователей папку полностью (например, папку, содержащую формы для администрирования сайта), то нужно разместить в ней файл Web.config с таким содержанием (cимвол означает анонимных неавторизированных пользователей):

Если же мы хотим защитить только один файл (например, для подтверждения заказа в Internet -магазине), то в Web.config из корневой папки нужно добавить такие строки:

Приложение извлекает данные пользователей с помощью свойства Identity класса User. Это свойство возвращает объект, содержащий имя пользователя и роль.

bool authenticated = User.Identity.IsAuthenticated ;
string name = User.Identity.Name;
bool admin = User.IsInRole(«Admins»);

Forms-аутентификация

При использовании Forms-аутентификации запрос параметров регистрации (например, логина и пароля) происходит в web-форме. Регистрационная страница указывается в файле Web.config. При первом обращении к защищаемым страницам ASP.NET перенаправляет пользователя на страницу для ввода пароля. При успешной регистрации аутентификационные данные сохраняются в виде cookie и при повторном обращении к защищенным страницам регистрация не требуется.
Для того, чтобы использовать Forms-аутентификацию в файле Web.config в корневой папке приложения нужно указать страницу для ввода пароля:

При попытке просмотра защищенной страницы ASP.NET проверяет, есть ли аутентификационных cookie в запросе. Если cookie нет, то запрос перенаправляется на страницу для регистрации, если есть — ASP.NET дешифрует cookie и извлекает из него регистрационную информацию.

На форме находятся поля для ввода логина и пароля и флажок для сохраняемой регистрации. При нажатии кнопки «Войти» происходит поиск пользователя с таким логином и паролем. Если такой пользователь найден, вызывается функция FormsAuthentication.RedirectFromLoginPage (), в которой указывается идентификатор пользователя и флаг для сохраняемой регистрации. Если же нет — выводится сообщение об ошибке.

protected void btnLogin_Click(object sender, System.EventArgs e)
<
if (!IsValid) // проверяем правильность введенных данных
return;

OleDbConnection connection = GetDbConnection();

OleDbCommand command = new OleDbCommand(string.Format(«SELECT id FROM Customers WHERE login=’<0>‘ AND password=’<1>‘», login, password), connection);

OleDbDataReader reader = command.ExecuteReader();
if (!reader.Read()) // пароль или логин неверны
<
lblError.Text = «Неверный пароль — попробуйте еще раз»;
return ;
>

string id = return reader.GetInt32(0).ToString();

FormsAuthentication.RedirectFromLoginPage(id, chkbRememberLogin.Checked);
>
catch (OleDbException ex)
<
lblError.Text = «Ошибка базы данных»;
>
finally
<
connection.Close();
>
>

Аутентификации на основе ролей

Для аутентификации на основе ролей применяется атрибут roles тега allow. Например, если мы хотим запретить доступ всем, кроме пользователей из группы Admin , мы должны вставить такие строки в файл Web.config.

Затем при каждом запросе нужно связывать учетные записи пользователей и роли. Обычно это делается в обработчике события AuthenticateRequest в файле Global.asax.

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
<
HttpApplication appl = (HttpApplication)sender;

DataTable tblUsers = (DataTable)Application[«UsersTable»];
appl.Context.User = new GenericPrincipal(identity,
new string[] <(string)(tblUsers.Rows.Find(identity.Name)["Role"]) >);
>
>

В коде проверяется тип аутентификации пользователя и то, что он уже зарегистрирован. Имя пользователя извлекается из cookie свойством Name. Таблица с именами пользователей и их ролями для повышения быстродействия была сохранена в объекте Application. Из этой таблицы и находим роль пользователя, которую сохраняем в объекте GenericPrincipal.

Параметры аутентификации

Если второй параметр функции RedirectFromLoginPage () равен false , то время жизни сеансового cookie , генерируемого ASP.NET , равно по умолчанию 30 минутам. Для изменения этого интервала служит параметр timeout тега forms в файле Web.config. Установим время действия аутентификации в 3 часа.

Когда сеансовый cookie возвращается в следующих после регистрации запросах, он автоматически обновляется, если время жизни истекло больше чем на половину. Время же жизни сохраняемых cookie равно 50 годам.
Можно указать имя аутентификационных cookie , поместив его в атрибут name (имя по умолчанию — ASPXAUTH ):

По умолчанию аутентификацонные cookie шифруются и проверяются. Уровень защиты можно указать через атрибут protection , значение по умолчанию которого All. Значение Validation предписывает только проверку cookie , а значение Encript — только шифрование. Полностью отключить защиту можно указав значение None. Отключать защиту имеет смысл если данные передаются по протоколу HTTPS.

Сброс forms-аутентификации

Сброс регистрации можно увидеть на многих сайтах. Для сброса аутентификации применяется метод FormsAuthentication.SignOut (). Он устанавливает дату окончания действия cookie на прошедшее время и cookie автоматически уничтожается.

Аутентификация Passport

Для использования Passport аутентификации в web -приложении нужно установить Passport SDK. Passport SDK предоставляется бесплатно для тестирования, но для коммерческого использования на сайте необходимо приобретать лицензию.
При обращении к приложению с Passport аутентификацией проверяется наличие cookie с данные Passport. Если такого файла нет, пользователь перенаправляется на страницу для регистрации Passport.
Для включения данного режима аутентификации в файле Web. config нужно указать следующее:

Для обязательной регистрации всех посетителей сайта в разделе autorization нужно запретить доступ неавторизированным пользователем:

Пользователь ASP.NET работает под

Я немного смущен тем, как ASP.NET, с каким пользователем он работает? На iis 7.5 и 6.0

Несколько учетных записей пользователей, которые я не понимаю,

Любые разъяснения для разных пользователей будут оценены и соображения безопасности/и т.д.

IIS 5.1 (Windows XP) — это локальная учетная запись ASPNET
IIS 6 — по умолчанию пулы приложений запускаются под учетной записью Network Service , которая является членом группы IIS_WPG
IIS 7.0 — все еще Network Service
IIS 7 SP2/7.5 — работает под эфемерной вещью под названием ApplicationPoolIdentity , которая сопоставляется с учетной записью IIS APPPOOLApplicationPool (например, IIS APPPOOLDefaultAppPool). Эта учетная запись является членом группы пользователей IIS_IUSRS
Сервер веб-разработки ASP.NET(Cassini) — это, очевидно, ваша собственная учетная запись

И это хорошая практика для создания пользовательской учетной записи с низким уровнем привилегий для запуска вашего приложения, особенно в среде PROD, или когда вам нужно получить доступ к сети из приложения.