Asp установка локального идентификатора


Содержание

Установка и конфигурирование IIS

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

В этой и следующих статьях мы рассмотрим различные варианты развертывания. Однако во всех случаях основные предпосылки остаются неизменными. На рабочей станции имеется готовый веб-сайт, который нужно развернуть на сервере, чтобы он был доступен клиентам. Для ASP.NET таким сервером является , а его текущей версией — IIS 8. Когда он был впервые реализован, IIS представлял собой базовый веб-сервер. С годами IIS развился в сложный сервер приложений, предоставляющий широкое множество функциональных средств, наиболее важным из которых является поддержка хостинга приложений ASP.NET.

В этой статье основное внимание уделяется IIS 8. Хотя машина, на которой запущен IIS 8, здесь называется сервером, IIS можно запускать под управлением версий Windows как для рабочей станции, так и для сервера. На рабочих станциях доступны не все, но большинство функциональных возможностей, что позволяет размещать сложные веб-сайты. По возможности мы рекомендуем использовать Windows Server, однако недорогой альтернативой могут послужить Windows 7 или Windows 8.

В Microsoft привязывают выпуски IIS с выпусками Windows. В состав Windows Server 2008 и Windows Vista входит версия IIS 7.0, в состав Windows Server 2008 R2 и Windows 7 — версия IIS 7.5, а в состав Windows Server 2012 и Windows 8 — IIS 8. Версии — 7.0 и 7.5 — в Microsoft обобщенно называют IIS 7, что может вносить путаницу. Версию IIS, поддерживаемую операционной системой, изменить нельзя — Windows Server 2008 будет использовать только IIS 7.0. Например, модернизировать ее до версии IIS 7.5, используемой в Windows Server 2008 R2, не получится.

Установка IIS

Компонент IIS включен как часть установки Windows (как для сервера, так и для рабочих станций) и требует активизации и конфигурирования. Далее представлены три способа активации IIS для различных операционных систем.

Установка IIS на настольных версиях Windows (Windows Vista, Windows 7 и Windows 8)

Каждая версия операционной системы Windows предлагает свою версию IIS — IIS 8 (в Windows 8), IIS 7.5 (в Windows 7) или IIS 7 (в Windows Vista). Во всех этих версиях Windows, IIS включен, но изначально не установлен. Чтобы установить его, необходимо выполнить следующие действия:

Откройте панель управления.

Нажмите кнопку «Включение или отключение компонентов Windows». Теперь вам нужно подождать, пока Windows исследует вашу систему.

Найдите элемент Internet Information Services (Службы IIS) в верхней части списка и нажмите на галочку чтобы включить его:

Обратите внимание, что Windows позволяет включить множество компонентов IIS: поддержка FTP-сервера, дополнительные инструменты управления, службы обратной совместимости с IIS 6 и т.д.

Убедитесь, что вы выбрали поддержку ASP.NET. Для этого раскройте узел Службы Интернета Компоненты разработки приложений ASP.NET (Internet Information Services World Wide Web Services Application Development Features ASP.NET):

Если вы хотите использовать поддержку IIS в Visual Studio, которая позволяет вам создавать виртуальные каталоги IIS непосредственно в диалоговом окне New Web Site, вам нужно выбрать пункт «Совместимость управления IIS 6» в разделе «Средства управления веб-сайтом» (Web Management Tools IIS 6 Management Compatibility).

Как только вы выбрали нужные параметры IIS, нажмите кнопку OK для завершения установки.

Установка IIS в Windows Server 2008

Установка и настройка IIS одинакова для Windows Server 2008 и Windows Server 2008 R2. Необходимые шаги описаны ниже:

Запустите диспетчер сервера. Чтобы сделать это, нажмите кнопку Start и выберите All Programs Administrative Tools Server Manager.

Выберите узел Roles в дереве слева.

В правой части окна нажмите на ссылке Add Roles. Это открывает мастер, позволяющий добавить новую роль сервера.

Выполните необходимые действия в мастере. Вас вероятно попросят установить дополнительные необходимые роли — если это так, нужно просто принять операции и продолжить.

После установки вам будет предложено настроить веб-сервер. Как в настольных версиях Windows, вы можете выбрать специфические особенности IIS 7, которые должны быть включены.

Если вы работаете в ASP.NET с версией .NET Framework 4.5, то эту версию .NET Framework необходимо будет установить (центр разработчиков .NET Framework)

Установка IIS в Windows Server 2012

Процесс установки IIS в Windows Server 2012, по существу, такой же, как и в Windows Server 2008. Основное различие заключается в том, что пользовательский интерфейс несколько отличается. Подробное описание вы можете найти перейдя по ссылке Installing IIS 8 on Windows Server 2012.

Управление IIS

При установке IIS, он автоматически создает каталог с именем C:\inetpub\wwwroot, который представляет ваш веб-сайт. Все файлы в этом каталоге будет отображаться, как будто они находятся в корневом каталоге вашего веб-сервера.

Чтобы добавить дополнительные страницы на ваш веб-сервер, можно скопировать файлы HTML, ASP или ASP.NET напрямую в каталог C:\Inetpub\wwwroot. Например если добавить файл TestFile.html в этот каталог, вы можете запросить его в браузере через URL-адрес http://localhost/TestFile.html. Вы даже можете создавать вложенные папки для группирования связанных ресурсов. Например, вы можете получить доступ к C:\inetpub\wwwroot\MySite\MyFile.html через браузер, используя URL-адрес http://localhost/MySite/MyFile.html.

Каталог wwwroot удобен для запуска простых примеров и статичных страниц. Для правильного использования ASP.NET вы должны сделать свой собственный виртуальный каталог для каждого веб-приложения, которое вы создаете. Например, вы можете создать папку с любым именем на любом диске вашего компьютера и поместить ее в виртуальный каталог IIS как будто она расположена в каталоге C:\inetpub\wwwroot.

Прежде чем начать работу, вам нужно запустить диспетчер служб IIS. Его можно найти в меню Start (Пуск). Конкретное расположение может зависеть от используемой версии Windows (IIS Диспетчер служб IIS). Ярлык программы будет располагаться в разделе Programs (Программы) или Administrative Tools (Администрирование). Начальная страница IIS Manager показана на рисунке ниже:

Теперь нужно ознакомиться с рядом терминов, используемых в IIS. В левой части окна IIS Manager отображается запись с именем используемого сервера. Наш сервер имеет имя PROFESSORWEB, сгенерированное по умолчанию Windows 8, которое будет использоваться в большинстве примеров. В центральной области отображается представление сервера. Это представление отображает набор значков, которые позволяют конфигурировать параметры сервера. В правой части экрана расположен список доступных действий. Например, в этом представлении можно запускать, останавливать и перезапускать сервер.

Если развернуть элемент сервера в древовидном представлении в левой части экрана, отобразится элемент Sites (Сайты), содержащий единственную запись Default Web Site (Веб-сайт по умолчанию). Сайт — это коллекция файлов и каталогов, образующих веб-сайт. На одном сервере IIS может поддерживать несколько сайтов, как правило, на различных портах TCP/IP (по умолчанию используется порт 80). Сочетание имени сервера и порта сайта образует первую часть URL-адреса. Например, при использовании сервера mywebserver с сайтом, подключенным к порту 80, URL-адрес выглядит следующим образом:

Каждый сайт может содержать множество файлов и каталогов. Каждый из них образует часть URL-адреса. Так, URL-адрес статической страницы mypage.html, расположенной в каталоге myfiles, будет следующим:

В некоторых ситуациях имя, под которым сервер известен вам, и имя, которое клиенты используют для получения содержимого, будут различаться. Мы оставим этот нюанс без внимания, но администратор сервера или компания, предоставляющая услуги хостинга, предоставят необходимые сведения, если это важно для конкретного сервера.

Чтобы проверить работоспособность IIS выберите Default Web Site и в правой области диспетчера служб IIS выберите пункт «Запустить». После этого нажмите кнопку «Обзор *.80 (http)» чтобы открыть страницу сайта в браузере:

Как видите, в моем случае я поменял порт используемый по умолчанию (с 80 на 8080). Я сделал это, т.к. на 80-м у меня запущен локальный Apache-сервер. Если у вас возникает такая же проблема, то изменить порт можно щелкнув правой кнопкой мыши по сайту (Default Web Site) и выбрав в контекстном меню «Изменить привязки» (Bindings). После этого в диалоговом окне можно изменить порт, используемый по умолчанию.

Итак, каждый сервер может поддерживать множество сайтов, каждый из которых работает на другом порту или с другим IP-адресом. Каждый сайт может иметь множество файлов и каталогов, и сочетание этих элементов предоставляет информацию о URL-адресе. Мы вернемся к URL-адресам и использованию IIS Manager при рассмотрении каждого из подходов к развертыванию.

Asp установка локального идентификатора

Обновлен: Ноябрь 2007

При помощи Диспетчера IIS можно создавать локальный веб-узел, содержащий веб-приложение ASP.NET. В этом разделе объясняется, как можно создать локальный веб-узел и настроить его для запуска страницы ASP.NET. Дополнительные сведения по установке и настройке IIS или о том, как создать веб-узел, содержатся в справке IIS или в документации продукта IIS в режиме онлайн на веб-узле Microsoft TechNet.

В качестве альтернативы создания локального веб-узла можно также создать виртуальный каталог. Это позволяет размещать веб-узел на одном компьютере (его содержимое может размещаться на других компьютерах, в том числе удаленных). Это также удобный способ для настройки узла для локальной веб-разработки, поскольку она не требует уникального идентификатора веб-узла. Это значит, что для создания уникального веб-узла требуется меньше действий. Дополнительные сведения см. в разделе Практическое руководство. Создание и настройка виртуальных каталогов в IIS 5.0 и 6.0 .

Чтобы открыть IIS Manager, выполните одну из процедур, описанных в Практическое руководство. Открытие диспетчера IIS . Затем можно создавать сайт. В следующей процедуре описывается создание веб-узла в IIS версии 6.0.

Процедура создания локального веб-узла в ранних версиях IIS похожа на приведенные процедуры, однако отличается в деталях. Для получения информации относительно создания веб-узлов в других версиях см. Справку IIS или документацию по IIS на веб-узле Microsoft TechNet. (Локальная Справка IIS доступна в браузере: http://localhost/iisHelp/ .)

Для создания локального веб-узла в IIS 6.0

В меню Пуск выберите команду Выполнить .

В поле Открыть введите inetmgr и нажмите кнопку ОК .

В IIS Manager откройте локальный компьютер, щелкните правой кнопкой папку веб-узлы , выберите Создать , затем выберите Веб-узел .

Откроется диалоговое окно Мастер создания веб-узлов .

В Мастере создания веб-узлов нажмите Далее .

В поле Описание введите описательную метку узла (эта метка не вводится в адресной строке), затем нажмите Далее .

Введите или выберите IP-адрес (по умолчанию Все неназначенные ), TCP-порт и заголовок узла (например www.microsoft.contoso.com).

Примечание.

Чтобы гарантировать доставку пользовательских запросов к нужному веб-узлу, необходимо дать каждому веб-узлу на сервере по крайней мере один из трех уникальных идентификаторов: имя заголовка узла, IP-адрес или номер TCP-порта. Лучший метод идентификации нескольких веб-узлов на одном сервере состоит в использовании уникальных имен заголовков узлов. Для перехода на узел пользователь должен ввести пару из имени сайта и IP-адреса, которая соответствует узлу на DNS-сервере или указана в локальном файле HOSTS. Для получения дополнительной информации о выборе уникальных идентификаторов см. раздел Hosting Multiple Web Sites on a Single Server в документации по IIS 6.0.

В поле Путь введите или выберите каталог, содержащий информацию на сайте, и нажмите кнопку Далее .

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


По умолчанию флажки Чтение и Запуск сценариев установлены. Эти разрешения позволяют запустить страницы ASP.NET для многих распространенных сценариев.

После создания локального веб-узла можно настроить его для использования страниц ASP.NET, а также настроить параметры безопасности. В следующей таблице показаны параметры разрешений, которые доступны во всех версиях IIS, включая IIS 6.0:

Учетная запись или группа

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

Учетная запись, настроенная для доступа к системным ресурсам для контекста текущего пользователя ASP.NET, например учетная запись сетевой службы (IIS 6.0) или учетная запись ASPNET (IIS версии 5.0 и 5.1).

Просмотр содержимого папки

После завершения настройки узла можно добавлять веб-страницы ASP.NET в каталог узла.

Настройка безопасности и проверка подлинности локального веб-узла

В IIS Manager щелкните правой кнопкой мыши узел, который требуется настроить, и нажмите кнопку Свойства .

Нажмите вкладку Безопасность каталога , выберите в Управление проверкой подлинности и доступом и нажмите Изменить .

Установите флажок для метода проверки подлинности или методов, которые требуется использовать для узла, а затем нажмите OK . По умолчанию флажки Разрешить анонимный доступ и Встроенная проверка подлинности Windows уже установлены.

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

Во вкладке Безопасность измените конфигурации дополнительных учетных записей и разрешения, необходимые для работы веб-узла, затем нажмите кнопку OK . Некоторые учетные записи (Администраторы и Система) уже настроены по умолчанию.

Важное примечание.

Чтобы добавить новую группу или имя пользователя, нажмите кнопку Добавить и кнопку Размещение . Выберите из списка имя локального компьютера и нажмите кнопку OK . Затем введите имя учетной записи, которую требуется добавить в текстовое поле. После ввода имени нажмите Проверить имена для проверки имени учетной записи. Нажмите OK , чтобы добавить учетную запись.

Как прочитать данные с сетевого диска либо по локальному пути MVC

Пишу маленький проект с подключением файла с сетевого диска, при публикации на локальном ПК получаю исключение

System.IO.DirectoryNotFoundException: Не удалось найти часть пути

затем я решил в поле пути прописать явное подключение

и снова получаю исключение:

System.UnauthorizedAccessException: Отказано в доступе по пути \192.168.0.2\delete\test.dat

И как бы ясно что система требует логин пароль, я на MSDN нашел вот такой пример: в web.config добавляем :

И всеравно получаю ошибку, в которой сказано что такого пользователя и пароля не существует в системе, помогите пожалуйста решить проблему. Спасибо

Установка локального идентификатора репозитория при установке POM

Мне нужен локальный репозиторий для моего проекта для JAR-файла, недоступного через репозиторий Maven Central. Я устанавливаю свой JAR с помощью mvn install:install-file … в соответствии с http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html, используя -DlocalRepositoryPath , чтобы указать путь в моем репозитории Git и использование -DcreateChecksum для создания контрольных сумм.

Это устанавливает JAR, генерирует POM и генерирует контрольные суммы для всех файлов. Но интересно это также создает файл maven-metadata-local.xml в каталоге groupId. Из http://maven.apache.org/ref/3.2.5/maven-repository-metadata/ Я понимаю, что local — это идентификатор, который он предоставляет локальному репозиторию.

Но в моей POM ( mvn install:install-file не было возможности узнать) я использую идентификатор local-repo для моего репозитория:

Конечно, я может изменить мою POM, чтобы просто использовать local , чтобы соответствовать сгенерированным файлам, но я не люблю делать что-то, не понимая, почему я это делаю. Может быть, кто-то может сказать мне:

Торговый токен внешнего доступа для локального — Идентификатор ASP.Net

При использовании идентификатора ASP.Net и извлечения внешнего токена доступа от внешнего поставщика, как мне затем торговать/выдать токен локального доступа с помощью токена внешнего доступа ?

Я видел [HostAuthentication(DefaultAuthenticationTypes.ExternalBearer)] , но не смог заставить его работать над моим методом действий. Если я посылаю с заголовками

Это не заселить User.Identity

Создан 29 июн. 15 2015-06-29 16:11:26 parliament

Я вижу ошибку, которую вы делаете. Значок третьей стороны бесполезен для вас. Используйте идентификатор пользователя, который вы вернетесь. Создайте связь с пользователем приложения в вашем Identity в первый раз, когда пользователь зарегистрирует стороннюю сторону, а затем с использованием этого идентификатора пользователя для входа в систему локально и создания локального маркера-носителя. – Dave Alperovich 03 июл. 15 2015-07-03 17:00:10

Я не следую. Что делает [HostAuthentication (DefaultAuthenticationTypes.ExternalBearer)]? Посмотрите на этот метод: https://github.com/tjoudeh/AngularJSAuthentication/blob/master/AngularJSAuthentication.API/Controllers/AccountController.cs#L175 Он использует токен доступа, чтобы сделать api-вызов соответствующему провайдеру и получить идентификатор пользователя, а затем выдает токен локального доступа. Я ищу, чтобы заменить этот API-код, я думал, что для этого атрибута выше. – parliament 05 июл. 15 2015-07-05 16:36:55

Я могу получить доступ к UserId из OnAuthenticated callback, однако это отдельный вызов api. Я не использую файлы cookie, чтобы выдать идентификатор между вызовами api. На втором вызове у меня есть токен внешнего доступа, есть ли способ использовать платформу Identity для извлечения идентификатора пользователя без ручных вызовов api? – parliament 05 июл. 15 2015-07-05 16:45:33

Эта библиотека аутентифицирует пользователя на основе токена-носителя, созданного ** ASP.NET **.Но вы не можете автоматически «торговать маркером внешнего доступа для локального». Это как торговля австралийским долларом за доллар. Да, стандарт тот же, токен дает вашему приложению никакой информации о пользователе. Маркер G + или FB подходит только для звонков в их API. – Dave Alperovich 05 июл. 15 2015-07-05 16:45:54

Когда вы получаете подтверждение авторизации от третьей стороны, они обычно создают локальный файл cookie с претензиями. Вы анализируете эти претензии, чтобы найти идентификатор пользователя для стороннего приложения и их имя/адрес электронной почты. Затем проверьте, существует ли пользователь в вашем идентификационном БД. Если пользователь не существует, создайте новую запись. Если пользователь существует, верните в UI новый токен-носитель. – Dave Alperovich 05 июл. 15 2015-07-05 16:49:13

Правильно, я делаю большую часть этого, за исключением того, что я не возвращаю новый токен на предъявителя сразу. Вместо этого я возвращаю токен внешнего доступа и хотел бы сделать второй вызов api для получения локального токена доступа. Я думаю, что это невозможно сделать в отдельных вызовах api, не усложняя его внешними вызовами api. Обычно это будет работать с файлами cookie, поскольку cookie будет сохранен в браузере и отправлен при последующем вызове, но не без него. – parliament 05 июл. 15 2015-07-05 16:54:41

Хммм, похоже, впустую туда и обратно. Почему бы не вернуть оба: ваш новый токен доступа и сторонний токен вместе с именем поставщика? Если вам нужно следовать этому рабочему потоку, становится трудно. По умолчанию API не имеют сеансов. Таким образом, вам нужно будет хранить токен на предъявителя для будущих ссылок на сервере. Кажется чрезмерным. Я стараюсь пропустить шаг и выполнить стороннюю аутентификацию с помощью JS. Я сохраняю внешний токен AND cookie, а затем отправляю идентификатор пользователя в свой API учетной записи, чтобы вернуть токен-носитель. Это больше работает. – Dave Alperovich 05 июл. 15 2015-07-05 16:57:53

Ну, потому что это внешний URL-адрес перенаправления uri, поэтому вся эта информация возвращается в URL-адрес, я беспокоился о возврате обоих токенов доступа, а другая информация для «ассоциированного» представления (первые регистры времени) переполнила бы допустимые символы URL-адреса. Ленты доступа довольно длинны – parliament 05 июл. 15 2015-07-05 17:07:18

1 ответ

Рабочий процесс Owin Middleware Внешняя аутентификация включает

  • Перенаправление/запрос внешних OAuth Поставщик
  • Регистрация нового пользователя с ASP.NET идентичности с использованием внешнего Cookie и все претензии информация
  • Возвращение однонаправленного токен к Presentation Layer.

The [HostAuthentication(DefaultAuthenticationTypes.ExternalBearer)] не используется, чтобы Внешние Предъявительские токены для использования в месте местных органов власти Несущих токенов. Токены с внешним носителем используются только для аутентификации идентификатора пользователя.

Owin Middleware Authentication всегда должен заключить с Owin Middleware Bearer Токен возвращается пользователю. Независимо от того, выполняется ли аутентификация пользователя с помощью локального входа/пароля или с помощью файла cookie/токена внешней аутентификации, пользователь должен получить токен локального пользователя, чтобы использовать безопасные методы.

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

Создан 05 июл. 15 2015-07-05 21:17:50 Dave Alperovich

Здравствуйте, @ dave-alperovich, после получения externalLogin FromIdentity (External Cookie, установленного FB). Что делать, если вы обнаружили, что пользователь существует/не существует в базе данных идентификатора (действие GetExternalLogin в web-api). Не могли бы вы назвать какой-то код. – Himalaya Garg 23 май. 17 2020-05-23 16:00:46

Как получить токен-носитель от web-api к клиенту, если web-api аутентифицирован с помощью внешнего входа? – Himalaya Garg 29 май. 17 2020-05-29 17:26:04

Может ли IE/ASP.NET прочитать идентификатор локальной сети пользователя

Мы делаем фазу анализа системы колл-центра. Чтобы обойти потенциальную хитрую проблему аутентификации, нам может потребоваться прочитать идентификатор локальной сети агента и использовать его в качестве идентификатора пользователя в системе.

Можно ли прочитать идентификатор локальной сети из ASP.NET или даже из Javascript?

3 ответа

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

Если вы включите встроенную проверку подлинности Windows для веб-сайта (и отключите анонимный доступ), то пользователь будет проходить проверку подлинности по своей учетной записи домена при каждом доступе к веб-сайту. Вы можете получить их имя пользователя в коде, используя


Я делал это успешно в нескольких приложениях интранета в прошлом.

Я не уверен, что именно идентификатор локальной сети. Я просто предположу, что вы имеете в виду MAC-адрес?

Если это так, я не верю, что это возможно получить через ASP.NET без элемента управления ActiveX или чего-либо, установленного на стороне клиента.

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

Отладка приложения ASP.NET, размещенного на IIS: прикрепление процесса и выяснение, какой процесс прикрепить

Written on 03 Июля 2013 . Posted in ASP.NET

ОГЛАВЛЕНИЕ

Данная статья описывает способ отладки приложения, размещенного на IIS. Здесь также описан способ выбора конкретного процесса для прикрепления к вашему приложению, когда выполняются несколько рабочих процессов

Оглавление

  • Обзор
  • Отладка ASP . NET по сравнению с отладкой IIS
  • Что такое рабочий процесс?
  • Пул приложений
    • Что такое пул приложений?
    • Стандартный пул приложений
    • Создание собственного пула приложений
    • Назначение сайта пулу приложений
  • Как начать?
  • Какой процесс прикрепить?
  • Как прикрепить конкретный рабочий процесс, когда выполняется несколько процессов.
    • Получение списка выполняющихся рабочих процессов
    • Прикрепление нужного процесса
  • Вывод

Обзор

Обычно веб-приложение Asp.Net отлаживается из Visual Studio. Visual Studio имеет собственный механизм ASP.Net, способный запускать и отлаживать веб-сайты внутри visual studio. Но если ваш сайт размещен на IIS, и вы хотите отладить этот сайт, как вы будете его отлаживать? При размещении сайтов на IIS worker process(w3wp.exe) используется для запуска веб-приложения. Надо прикрепить конкретный процесс в Visual Studio, чтобы отлаживать приложение. Данная статья описывает общую идею отладки приложения с помощью прикрепленного процесса. Она также рассматривает рабочий процесс, пул приложений и выбор конкретного процесса, если на IIS выполняется несколько рабочих процессов, с помощью iisapp.vbs. Надеемся, вам понравится эта статья, и вы дадите ценные советы и отзывы.

Отладка ASP.NET по сравнению с отладкой IIS

Visual studio имеет встроенный механизм отладки, отлаживающий код при запуске приложения из Visual Studio. Если при разработке сайтов надо отладить код, ставятся точки останова и производится отладка. [Примечание: В этой статье не описан способ установки режима отладки]. При запуске приложения выполнение кода останавливается, когда приходит определенная точка останова. Это очень просто, поскольку, когда приложение ASP.NET запускается из Visual studio, его контролирует механизм Asp.Net, встроенный в Visual Studio. Если вы хотите проверить, какой процесс запускается для отладки, запустите веб-приложение из Visual Studio и получите такое всплывающее уведомление, как ниже:

Рисунок. Отображение всплывающего уведомления при запуске отладки из Visual Studio

Уведомление показывает, что процесс запускается для выполнения приложения ASP.NET. Дважды щелкните по иконке. Появится всплывающее окно и покажет характеристики.

Рисунок. Характеристики процесса сервера разработки

За выполняющимся процессом находится «WebDev.WebServer.Exe». При нажатии F5 для запуска этот процесс начинает выполнять приложение Asp.Net. Если вы хотите запустить приложение из командной строки, выполните следующие шаги.

Шаги:
1. Открыть командную строку Visual Studio
2. Запустить Webdev.WebServer

Появится следующий экран. Смотрите раздел примеров.

Теперь вернемся к отладке в IIS. IIS появляется при развертывании или размещении сайта на сервере. После развертывания сайтов на IIS, если надо отлаживать сайт из него, нельзя делать это непосредственно в Visual studio. IIS имеет свой собственный рабочий процесс, следящий за выполнением и поддержкой развернутого веб-приложения. Характеристики рабочего процесса описаны в следующем разделе. Поэтому, если мы имеем выполняющийся процесс на IIS, и нам надо отладить приложение, прежде всего надо прикрепить правильный процесс в Visual Studio. Перед разбором способа прикрепления процесса рассмотрим рабочий процесс и пул приложений.

Что такое рабочий процесс?

Рабочий процесс (w3wp.exe) запускает приложение ASP.Net в IIS. Вся функциональность ASP.Net выполняется внутри рабочего процесса. Когда на сервер приходит запрос от клиента, рабочий процесс отвечает за генерацию запроса и ответа. Он также хранит данные сессии InProc. При перезапуске рабочего процесса теряется состояние рабочего процесса. Дополнительную информацию сморите в статье Низкоуровневое рассмотрение архитектуры ASP.NET

Пул приложений

Это одна из самых важных вещей, которую вы должны создать для вашего собственного приложения в среде Производства. Пулы приложений служат для выделения групп рабочих процессов IIS, имеющих одинаковую конфигурацию. Пулы приложений позволяют изолировать веб-приложение ради лучшей защиты, надежности и работоспособности. Рабочий процесс служит в качестве границы процессов, отделяющей каждый пул приложений, чтобы сбой или перезапуск одного рабочего процесса или приложения не влиял на другие приложения или рабочие процессы.

Стандартный пул приложений

Имя стандартного приложения IIS 6.0 — «DefaultAppPool». После размещения сайта на IIS при проверке свойств Виртуальной директории вы сможете увидеть, что:
1. Start(пуск) – Run(выполнить) — Inetmgr
2. Развернуть «DefaultWebSites» или Другие веб-сайты, где вы создали Виртуальную директорию
3. Щелкнуть правой кнопкой мыши по Виртуальная директория
4. Щелкнуть по Свойства

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

Чтобы проверить список всех пулов приложений в IIS, разверните Узел пула приложений на сервере IIS.

Рисунок. Стандартный пул приложений

Теперь все до единого пулы приложений должны иметь минимум один рабочий процесс, следящий за работой сайта, связанного с пулом приложений. Щелкните правой кнопкой мыши по пулу приложений – перейдите во вкладку производительности, проверьте нижнюю часть вкладки, там есть раздел сетевого сада, и по умолчанию рабочий процесс равен 1. Пул приложений, содержащий более одного рабочего процесса, называется Web Garden(сетевой сад).

Создание и назначение пула приложений

Откройте консоль IIS, щелкните правой кнопкой мыши по папке пула приложений > Создать New(новый)

Введите Идентификатор пула приложений и нажмите Ok.

Теперь щелкните правой кнопкой мыши по Виртуальной директории и назначьте только что созданное приложение этой Виртуальной директории.

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

Как начать?

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

Был создан один веб-сайт под именем sampleWebSite и размещен на локальном IIS. Ниже показан вывод страницы по умолчанию.

Рисунок. Пример веб-сайта

Какой процесс прикрепить?

Как уже было сказано, имя процесса — w3wp.exe, следовательно, можно проверить его из менеджера задач, выполняется рабочий процесс или нет

Рисунок. Менеджер задач показывает выполняющийся процесс

Теперь прикрепим процесс. Перейдите в Отладка > Прикрепиться к процессу

Рисунок. Открыть окно прикрепления процесса

После нажатия на Прикрепиться к процессу появится следующий экран,


Рисунок. Выполняется один рабочий процесс

Теперь видно, что выполняется тот же самый рабочий процесс. Надо прикрепить этот процесс. Выберите «Процесс» и нажмите кнопку «Прикрепить». После проверки двух рисунков ниже

Рисунок: 1) Процесс успешно прикреплен 2) Процесс не прикреплен

Заметили ли вы знак точки останова? Если рабочий процесс прикрепился успешно, знак точки останова выполнения кода должен быть четким, в противном случае он должен иметь предупреждающую иконку. Для одного рабочего процесса сценарий не свойствен. Но если на IIS выполняется несколько рабочих процессов, возникает беспорядок. Это рассмотрено в следующем разделе.

Теперь при нажатии на кнопку отладки веб-страницы выполнение кода остановится в точке останова.

Теперь рассмотрим случай, когда выполняется несколько рабочих процессов

Как прикрепить конкретный рабочий процесс, когда выполняется несколько процессов?

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

Мы имеем 3 пула приложений в IIS:
• Стандартный пул приложений
• Обобщенный пул приложений
• Пул приложений сервера состояний

Сейчас SampleWebSite связан с defaultAppPool, и мы хотим прикрепить процесс для отладки SampleWebSite. Выполните такой же шаг для открытия окон прикрепления процесса

Рисунок. Список рабочих процессов

Посмотрите, рабочий процесс сейчас выполняется, и вам надо прикрепить один из них, но вы не знаете, какой рабочий процесс предназначен для стандартного пула приложений. Вы выбрали любой процесс из них, допустим, >

Рисунок. Процесс не прикрепился правильно

Получение списка выполняющихся рабочих процессов

Ниже даны советы по решению указанной проблемы.
• Пуск > Выполнить > Cmd
• Перейти в Windows > System32
• Выполнить cscript iisapp.vbs и ждать вывода.

Вы получите список выполняющихся рабочих процессов, PID(идентификаторов процессов) и имя пула приложений.

Рисунок. Список выполняющихся рабочих процессов с PID и именем пула приложений

Прикрепление правильного процесса

Отсюда вы можете легко определить имя пула приложений и идентификатор процесса. Снова вернемся в VS > Прикрепить процесс. Теперь вы знаете, что идентификатор процесса для стандартного пула приложений равен 1772, следовательно, Прикрепить процесс.

Рисунок. Прикрепить процесс для отладки

Теперь наслаждайтесь отладкой.

Рисунок. Точка останова готова

Вывод

Иногда приходится отлаживать приложение, размещенное на IIS. Для этого надо прикрепить выполняющийся рабочий процесс к коду Visual Studio. Если на сервере IIS выполняется несколько рабочих процессов, мы можем определить правильный рабочий процесс с помощью команды cscript iisapp.vbs. Надеемся, статья поможет новичкам, испытывающим затруднения с отладкой приложения, размещенного на IIS.

При копировании материалов наличие активной индексируемой ссылки на сайт обязательно.

Asp установка локального идентификатора

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

Традиционно веб-сервер IIS (Internet Information Services) применялся для развертывания веб-приложений. Для хостирования веб-приложений ASP.NET Core также может применяться IIS, только в отличие от предыдущих версий ASP.NET теперь его роль будет сводиться к прокси-серверу. Хостирование приложений ASP.NET Core на IIS происходит с помощью нативного модуля AspNetCoreModule , который сконфигурирован таким образом, чтобы перенаправлять запросы на веб-сервер Kestrel. Этот модуль управляет запуском внешнего процесса dotnet.exe, в рамках которого хостируется приложение, и перенаправляет все запросы от IIS к этому хостирующему процессу.

При разработке в Visual Studio публиковать приложения очень легко — среда разработки имеет для этого весь необходимый инструментарий. Так, возьмем какой-нибудь проект и в Visual Studio нажмем на него правой кнопкой мыши и в появившемся контекстном меню выберем пункт Publish :

И перед нами откроется окно публикации приложения:

Здесь нам доступно несколько вариантов публикации:

Microsoft Azure App Service : публикация в облаке Azure

IIS, FTP, etc : публикация через FTP

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

Import Profile : импорт профиля, который содержит настройки публикации

Microsoft Azure Virtual Machines : публикация в облаке Azure, по сравнению с первой опцией обладает большими возможностями по управлению инфраструктурой развертывания

В данном случае выберем опцию Folder для создания пакета для публикации в файловой системе. И также укажем путь, по которому будет находиться пакет. В моем случае это каталог «C:\CoreApp». И в конце нажмем на кнопку Publish.

Далее откроется окно, где будут оображаться выбранные настройки конфигурации, и для продолжения публикации нажмем в нем кнопку Publish:

И после окончания публикации по указанному пути (в моем случае это каталог C:\CoreApp) появятся опубликованные файлы.

Настройка IIS

Прежде всего нам надо включить функциональность Web Server (IIS) и настроить роли сервера. Для этого перейдем по пути Панель управления -> Программы и компоненты -> Включение или отключение компонентов Windows . В списке компонентов найдем Службы IIS (Internet Information Services) и отметим ее:

Здесь также надо отметить подпункт «Службы Интернета» (World Wide Web Services) и все его подпункты, а также подпункт «Консоль управления IIS» (IIS Management Console).

Нажмем на ОК, и весь необходимый функционал будет добавлен в операционную систему.

Затем нам необходимо установить специальный пакет .NET Core Windows Server Hosting . Его можно найти, перейдя на страницу https://www.microsoft.com/net/download/all. Далее на этой странице надо выбрать нужную версию .NET Core Runtime ( .NET Core Runtime > .NET Core Runtime x.y.z . Далее на странице выбранной версии .NET Core Runtime перейти к подразделу Windows и выбрать Server Hosting Installer . После этого загрузится нужный пакет. Этот пакет устанавливает .NET Core Runtime, .NET Core Library и модуль ASP.NET Core Module. Данный модуль, как говорилось выше, как раз и создает проксирование между IIS и сервером Kestrel.

После установки этого пакета выполним в командной строке команду iisreset или вручную перезапустим IIS, чтобы сервер применил изменения.

Конфигурация сервера

Для конфигурации IIS перейдем к консоли управления веб-сервером. Для этого перейдем по пути Панель управления -> Администрирование -> Диспетчер служб IIS :

Нажмем правой кнопкой на узел «сайты» и в контекстном меню выберем пункт «Добавить веб-сайт. «. После этого нам откроется окно для добавления нового сайта:

В поле «Физический путь» здесь укажем каталог, в котором опубликовано приложение. А в качестве имени узла определим «localhost». Нажмем на OK, и приложение будет запущено.

Теперь перейдем к пункту Пулы приложений . Выберем пул нашего приложения и справа нажмем на ссылку Основные настройки :

В открывшемся окне для параметра Версия среды CLR .NET установим значение Без управляемого кода :

После этого пул будет перезапущен, и мы сможем обращаться к нашему приложению по адресу localhost.

Для системного администратора

Разворачивание цепочки центров сертификации на основе Microsoft CA

В данной статье деться пошаговая инструкция по установке и настройке центров сертификации (Certification authority) на основе служб сертификатов (Certificate services) Microsoft входящей в Windows 2003.

Схема, которую будем реализовывать:

Корневой центр сертификации будем устанавливать на компьютер с именем RootCA.


Для развёртывания корневого центра сертификации необходим компьютер под управлением ОС Windows Server с установленным IIS версии 6.0 или выше. Необходимо проверить наличие ASP на сервере IIS. Компьютер не должен входить в домен. Подключать данный компьютер к сети так же не обязательно, однако, сетевая карта на компьютере должна присутствовать.

Установка центра сертификации проходит по умолчанию. То есть во время установки никакие настройки менять не надо. Убеждаемся, что выбрана установка Stand-alone root CA

Единственная вещь, которую необходимо указать – это имя нашего корневого центра сертификации (назовём его ROOT CA).

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

    Заходим с свойства корневого центра сертификации.

Переходим на вкладку Extensions

  • На этой вкладке в выпадающем списке выбираем значение CRL Distribution Point.
  • Затем в поле ниже удаляем две записи начинающиеся на http:// и file://
  • Далее в этом же поле добавляем две записи вида:
    • http://SubCA.domain.local/CertEnroll/ .crl
    • file://\\SubCA.domain.local\CertEnroll\ .crl
    • для каждой добавленной записи устанавливаем галочки:
      1. Include in CRLs. Clients use this to find Delta CRL locations.
      2. Include in the CDP extension of issued certificates.
  • Затем на вкладке в выпадающем списке выбираем значение Authority Information Access.
  • В поле ниже удаляем две записи начинающиеся на http:// и file://
  • Далее в этом же поле добавляем две записи вида:
    • http://SubCA.domain.local/CertEnroll/ .crl
    • file://\\SubCA.domain.local\CertEnroll\ .crl
    • для каждой добавленной записи устанавливаем галочку:
      1. Include in the AIA extension of issued certificates.

      Обратите внимание, что указывается полное (FQDN) доменное имя компьютера.
      Данными действиями мы указали хранилище, в котором будет лежать файл, содержащий список отозванных сертификатов корневого сервера.

    Затем необходимо настроить срок годности списка отозванных сертификатов (по умолчанию неделя), иначе придётся каждую неделю публиковать новый список отозванных сертификатов, и выкладывать его в сеть (так как наш корневой центр сертификации не подключён к сети). Для этого, правой кнопкой мыши нажимаем на Revoked Certificates и в контекстном меню выбираем пункт Свойства.

    Затем в появившемся окне меняем значение CRL Publication Interval на необходимое, например, на 1 год. (Это означает, что список отозванных сертификатов, будет действителен в течении года).

    После этих действий, список отозванных сертификатов может перестать публиковаться в виде файла (наверное, это фича, а не бага), и его придётся экспортировать из реестра (как это сделать будет описано ниже).

    После всех действий рекомендуется перегрузить центр сертификации.

    На этом настройка корневого центра сертификации закончена. Но он нам ещё понадобиться для выписки сертификата.

    Теперь займёмся установкой подчинённого центра сертификации. Для развёртывания подчинённого центра сертификации необходим компьютер под управлением ОС Windows Server 2003 Enterprise с установленным IIS версии 6.0 или выше. Необходимо проверить наличие ASP на сервере IIS. Компьютер должен быть членом домена (может быть контроллером домена).

    При установке центра сертификации необходимо указать, что наш сервер является Enterprise Subordinate CA

    И задать ему имя (например, SUB CA).

    После установки, подчинённый центр сертификации попросит указать корневой центр сертификации или сохранить запрос на сертификат в файл. Так как корневой центр сертификации не доступен по сети, то мы сохраняем запрос в файл.

    Затем переносим этот файл запроса на корневой центр (ROOT CA) сертификации, импортируем запрос в центр сертификации:

    и затем, на основе импортированного запроса выдаём сертификат:

    Затем данный сертификат экспортируется в файл.

    Далее публикуем список отозванных сертификатов (даже если у нас нет отозванных сертификатов, данную операцию всё равно необходимо выполнить).

    Затем нам необходимо 3 файла перенести с машины, где установлен корневой центр сертификации на машину с подчинённым центром сертификации:

    • Файл, содержащий открытый ключ корневого центра сертификации, в нашем случае RootCA_ROOT CA.cer находиться в папке %system root%\system32\certsrv\certenroll – это должен быть единственный файл сертификата, в имени которого содержится имя компьютера и имя центра сертификации.
    • Файл, содержащий сертификат, выданный подчинённому центру сертификации на основании запроса. В нашем случае это SubCA.domian.local_SUB CA.cer. Местоположение данного файла указывается при экспортировании данного сертификата в файл (как было описано выше).
    • И последний файл, это файл, содержащий список отозванных сертификатов. Этот файл находиться в папке %system root%\system32\certsrv\certenroll и имеет расширение .crl. В нашем случае это ROOT CA.crl (файл содержащий в конце имени файла знак «+», содержит дельту списка отозванных сертификатов). Однако, как было описано выше, файла, содержащего список отозванных сертификатов, может не быть в этой папке, тогда этот файл необходимо экспортировать из реестра. Для этого открываем консоль управления сертификатами локального компьютера, и экспортируем необходимый список отозванных сертификатов в файл:

    Как было сказано выше, эти три файла мы переносим с корневого центра сертификации на подчинённый. Сертификат корневого центра сертификации импортируем на компьютер с установленным подчинённым центром сертификации (для этого достаточно просто открыть файл сертификата и нажать кнопку «установить сертификат»). Файл, содержащий список отозванных сертификатов необходимо положить в папку %system root%\system32\certsrv\certenroll (это тот путь, который мы указывали, когда меняли свойства корневого центра сертификации). А так же необходимо импортировать в реестр, с помощью остнастки – сертификаты. Файл, содержащий сертификат подчинённого центра сертификации необходимо импортировать в подчинённый центр сертификации:

    Теперь запускаем подчинённый центр сертификации.

    После того, как подчинённый центр сертификации стартовал, корневой центр сертификации можно выключать и убирать в сейф. Он нам потом может понадобиться в двух случаях:

    • Мы заходим поднять ещё один подчинённый центр сертификации второго уровня;
    • Нам понадобиться перевыписать сертификат подчинённого центра сертификации;

    Теперь необходимо настроить подчинённый центр сертификации.

    В список доступных к выдачи шаблонов сертификатов необходимо добавить два шаблона Enrollment Agent (Computer) и Enrollment Agent, для этого нажимаем правой кнопкой мыши на Certificate Templates, из контекстного меню выбираем New и затем Certificate Template to Issue.

    В появившемся окне выбираем два шаблона сертификатов Enrollment Agent и Enrollment Agent (Computer) и нажимаем «Ok».

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

    Далее, для сотрудника, отвечающего за выдачу сертификатов, необходимо выписать сертификат Enrollment Agent. Это можно сделать через Web-интерфейс. Для этого идём на адрес http://имя_компьютера_подчинённого_ЦС/certsrv (в нашем случае http://SubCA/certsrv). На странице выбираем пункт: Request a certificate:

    Далее выбираем Advanced certificate request:

    Затем Create and submit a request to this CA:

    Затем из выпадающего списка выбираем шаблон Enrollment Agent и нажимаем Submit. После этого устанавливаем полученный сертификат на компьютер.

    Для того, чтобы выписывать сертификаты другим пользователям необходимо или иметь сертификат Enrollment Agent установленный в профиле пользователя, который будет выдавать сертификаты, или Enrollment Agent (Computer), установленный на компьютере, на котором будет осуществляться выдача сертификатов.

    Для того, чтобы запросить сертификат Enrollment Agent или Enrollment Agent (Computer) необходимо входить в группу Администраторов Домена.

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

    Для проверки возможности авторизации в домене на основе сертификата необходимо проверить, что с компьютера, с которого осуществляется вход, доступна сетевая папка \\имя_сервера_подчинённого_ЦС\certenroll (в нашем случае \\SubCA\certenroll) и все файлы, имеющие расширение .crl доступны для чтения.
    Оригинал тут

    Этот пост June 3, 2008 at 11:03 am опубликовал molse в категории Документация. Желающие могут оформить RSS подписку на комменты. Both comments and trackbacks are currently closed.

    2 комментов оставлено (Add 1 more)

    Читатели, обратите внимание… в статье есть несколько критических ошибок, по невнимательности из за которых приходится теперь все перенастраивать. В частности, как уже отмечено выше в путях публикации CDP и AIA ошибка, DeldaCRLAllowed вместо DeltaCRLAllowed…. а так же ошибка с расширением файлов, для CDP должно быть crl а для AIA crt

    Возможно имелось ввиду не DeldaCRLAllowed, а DeltaCRLAllowed

    Установка локального идентификатора репозитория при установке POM

    Мне нужен локальный репозиторий для моего проекта для JAR-файла, недоступного через репозиторий Maven Central. Я устанавливаю свой JAR с помощью mvn install:install-file … в соответствии с http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html, используя -DlocalRepositoryPath , чтобы указать путь в моем репозитории Git и использование -DcreateChecksum для создания контрольных сумм.

    Это устанавливает JAR, генерирует POM и генерирует контрольные суммы для всех файлов. Но интересно это также создает файл maven-metadata-local.xml в каталоге groupId. Из http://maven.apache.org/ref/3.2.5/maven-repository-metadata/ Я понимаю, что local — это идентификатор, который он предоставляет локальному репозиторию.

    Но в моей POM ( mvn install:install-file не было возможности узнать) я использую идентификатор local-repo для моего репозитория:

    Конечно, я может изменить мою POM, чтобы просто использовать local , чтобы соответствовать сгенерированным файлам, но я не люблю делать что-то, не понимая, почему я это делаю. Может быть, кто-то может сказать мне:

    Илон Маск рекомендует:  Header field definitions rfc 2068
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL
  • Примечание.