Веб-приложение. Контроль доступа к определенным файлам. Контроль доступа к определенным каталогам
Хочется собрать все известные на сегодняшний день «простые» методы авторизации/регистрации на веб-ресурсах и их особенности в одном месте. (простые - в смысле не требующие специальных устройств, например смарт карт, устройств для сканирования отпечатков пальцев, сетчатки глаз и т.д.) Что ж, попробуем…
На данный момент мне известны такие способы:
1. Простая авторизация на сайте
Встречается повсеместно, естесственно возможна только после регистрации на конечном ресурсе, а для осуществления обычно требуется пара логин-пароль, предоставляемая пользователем.
Плюсы:
простота реализации, надежность.
Минусы:
для разных сайтов разные учетные данные, которые нужно запоминать, и не всегда это удается.
2. Авторизация по OpenID
Довольно интересный метод авторизации, для осуществления которого необходима регистрация у т.н. «провайдера идентификации» и «зависимая сторона» - конечный ресурс (сайт), который пытается идентифицировать пользователя. Особенность данного метода заключается в том, что регистрация на самом сайте не требуется, а провайдер идентификации может быть один для многих сайтов.
Подробнее можно узнать например тут: http://ru.wikipedia.org/wiki/OpenID
Плюсы:
один общий логин и пароль для одного провайдера, а значит и для всех ресурсов, удобство (не нужно запомниать множество учетных записей для разных сайтов), скорость использования, безопасность (пароль от учетной записи провайдера не передается конечному ресурсу (исключая случаи фишинга), а также исключен перехват)
Минусы:
пока еще малая распространенность метода, сайты, необходимые большинству пользователей и поддерживающие OpenID можно пересчитать по пальцам, да и централизованность это тоже не всегда хорошо.
Примеры сайтов, использующих метод: ЖЖ , Мой круг
Пример провайдера идентификации: MyOpenID.com
Вариации метода: «цифровой паспорт.NET» - проприетарная разработка Майкрософт, однако получившая некоторое распространение.
Ну это из более-менее популярных. Теперь рассмотрим «экзотику»:
3. Enum - авторизация
Суть метода: привязка «аккаунта» мобильному телефону, номеру. При регистрации на сайте такого провайдера пользователю выдается ссылка, по которой он устанавливает java-приложение себе в телефон. Для авторизации, на сайтах поддерживающих этот метод пользователь вводит свой адрес электорнной почты, сайт в ответ показывает пользователю число, которое необходимо ввести в ранее установленное приложение. После ввода контрольного числа на экране мобильного телефона отображается число-результат, которое затем необходимо ввести обратно на сайт, на котором происходит авторизация.
Чем-то напоминает OpenID, поэтому и наследует некоторые его особенности:
Плюсы
решения: простота реализации и пользования, безопасность (метод исключает перехват учетных данных, пригодных для повторной авторизации)
Минусы:
малое распространение метода, привязка к телефону, который может быть украден или потерян, или просто может не находиться рядом в нужный момент. Пример enum-провайдера
4.
Я даже затрудняюсь как-либо назвать этот метод. Универсальный аккаунт чтоли. Впервые я увидел его на сайте Российского Jabber-сообщества Суть метода в том, что чтобы писать комментарии на этом сайте нужен зарегистрированный аккаунт, но не объязательно на самом jabber.ru, а вообще на любом
jabber-сервере! Удобно на самом деле.
(на момент написания опуса метод не работает, происходит ошибка подключения к удаленному серверу и движок считает введенный пароль не верным, пробовал на аккаунте gmail.com, раньше вот работало...)
Ну с плюсами и минусами вроде очевидно: Jabber сейчас у многих, аккаунты есть - удобно. Но тут сразу возникает вопрос доверия сайту, ведь зайдя под своей учеткой один раз - недобропорядочный администратор может сделать это еще раз - это минус. Также все-таки сайт можно считать «тематическим» и подобный метод на другом сайте будет просто неоправдан, по причине различной аудитории.
6. «Разовая» авторизация по ссылке
Сразу пример: после обычной регистрации на каком-нибудь форуме, на указанный электронный адрес высылаестя письмо со ссылкой - подтверждением адреса. Ссылка работает только один раз, цель у нее тоже одна - подтвердить что именно хозяин этого адреса зарегистрировался на том форуме, но при этом иногда при переходе по такой ссылке пользователь попадает сразу в свой аккаунт, не вводя логин и пароль, что тоже удобно. Подобный метод используется также для сброса пароля. В общем тоже метод авторизации.
Выводы:
Некоторые из этих методов чем-то похожи друг на друга, но обладают различным набором достоинств и недостатков. При этом 2 - 6 метод никак не обходятся без первоначальной «простой» регистрации и авторизации.
А это я все к чему? А к тому, что создавая очередной проект, вопрос авторизации/регистрации пользователей нужно хорошо продумывать.
ЗЫ Жду конструктивной критики.
До сих пор было показано только, как проверять, что пользователи являются действительно теми, за кого себя выдают, и как извлекать информацию об аутентифицированных идентичностях. Это предоставляет приложениям базовую возможность различать пользователей, но это лишь начальная точка. Чтобы создать действительно безопасное веб-приложение, понадобится выполнять их авторизацию в различных местах приложения.
Авторизация - это процесс определения того, имеет ли аутентифицированный пользователь достаточные привилегии на выполнение того или иного действия. Таким действием может быть запрос веб-страницы, доступ к ресурсу, управляемому операционной системой (такому как файл или база данных), либо выполнение специфичных для приложения задач (наподобие размещения заказа в системе управления заказами или назначения проекта в приложении управления проектами вроде Microsoft Project Server).
Некоторые из этих проверок Windows осуществляет автоматически, а другие можно кодировать декларативно, используя файл web.config. Но некоторые проверки придется выполнять непосредственно в коде с использованием объекта IPrincipal.
Авторизация URL
Самый простой способ установки прав доступа предусматривает их установку на индивидуальных веб-страницах, веб-службах и подкаталогах. В идеале платформа веб-приложений должна поддерживать специфичную к ресурсам авторизацию без необходимости изменения кода и перекомпиляции приложения. ASP.NET поддерживает это требование с помощью декларативных правил авторизации, которые можно определять в файле web.config.
Определяемые вами правила действуют через специальный модуль HTTP по имени UrlAuthorizationModule . Модуль просматривает эти правила и проверяет каждый запрос, гарантируя, что пользователю не будут доступны ресурсы, доступ к которым ограничен специальным образом.
Авторизация такого типа называется авторизацией URL, потому что принимает во внимание только две детали - контекст безопасности пользователя и URL ресурса, к которому пользователь пытается обратиться. Если доступ к странице запрещен и применяется аутентификация с помощью форм, то пользователь будет перенаправлен на страницу регистрации.
Правила авторизации
Другими словами, существуют два типа правил: разрешить (allow) и запретить (deny). Тех и других можно добавлять столько угодно. Каждое правило идентифицирует одного или более пользователей либо ролей (групп пользователей). Вдобавок можно использовать атрибут verbs, чтобы создавать правила, применимые только к специфичным типам HTTP-запросов (GET, POST, HEAD ИЛИ DEBUG).
В предыдущих статьях уже приводился простейший пример. Чтобы запретить доступ всем анонимным пользователям, можно определить правило
В данном случае вопросительный знак (?) - это шаблонный символ, представляющий всех пользователей с неизвестной идентичностью. Это правило почти всегда используется в сценариях аутентификации. Это связано с невозможностью запрета доступа другим, известным пользователям, если только сначала не заставить всех аутентифицировать себя.
Можно использовать дополнительный шаблонный символ - звездочку (*), которая представляет всех пользователей. Например, следующий раздел
Такое правило требуется редко, потому что оно уже присутствует в файле machine.config. После того как среда ASP.NET применит все правила из файла web.config, она применяет правила из machine.config. В результате любому пользователю, кому явно закрыт доступ, автоматически его получает.
Теперь посмотрим, что произойдет, если в раздел
При оценке правил среда ASP.NET сканирует список сверху вниз. Как только она обнаружит применимое правило, поиск прекращается. Поэтому в предыдущем случае она определит, что правило
Когда правила авторизации добавляются в файл web.config корневого каталога веб-приложения, они автоматически применяются ко всем веб-ресурсам, которые являются частью приложения. Если вход анонимным пользователям запрещен, ASP.NET проверит метод аутентификации. Если выбрана аутентификация с помощью форм, ASP.NET перенаправит пользователя на страницу регистрации.
В следующих разделах вы научитесь более тонкой настройке правил авторизации, чтобы точнее определять для них область действия.
Конфигурирование доступа для определенных пользователей
Правила
Например, следующее правило авторизации специально ограничивает доступ для трех пользователей. Эти пользователи не смогут обратиться к страницам, которые находятся в каталоге с файлом web.config, содержащим эти вхождения. Все остальные аутентифицированные пользователи обращаться к этим страницам смогут:
Можно также определить список имен, разделенный запятыми, и запретить доступ сразу нескольким пользователям. Ниже показана версия, эквивалентная предыдущему примеру, в которой используются только два правила аутентификации:
Обратите внимание, что в обоих случаях порядок следования этих трех пользователей в списке не важен. Однако важно, чтобы запрет на доступ этим пользователям предшествовал правилу
Создавая безопасные приложения, часто лучше явно разрешить доступ определенным пользователям и группам, а затем запретить всем остальным (вместо запрета доступа определенным пользователям, как в предыдущих примерах). Ниже приведен пример правил авторизации, которые явно открывают доступ двум пользователям. Запросы всех прочих пользователей не будут удовлетворены, даже несмотря на то, что они аутентифицированы:
Следует обратить внимание на одну деталь. Формат имен пользователей в этих примерах предполагает аутентификацию с помощью форм. При такой аутентификации имя пользователя назначается при вызове метода RedirectFromLoginPage(). В этой точке UrlAuthorizationModule также использует это имя и проверит его по списку правил авторизации.
Контроль доступа к определенным каталогам
Общепринятое проектное решение для приложения предусматривает размещение файлов, которые требуют аутентификации, в отдельном каталоге. Благодаря конфигурационным файлам ASP.NET, этот подход реализуется просто. Оставьте элемент Вспомните, что когда вы добавляете файл web.config в подкаталог, он не должен содержать никаких других специфичных для приложения настроек. Фактически он должен содержать только информацию авторизации, как показано ниже: Настройки дескриптора При использовании правил авторизации в подкаталоге среда ASP.NET все равно читает правила авторизации из родительского каталога. Отличие в том, что правила из подкаталога применяются первыми. Это важно, потому что ASP.NET останавливается, как только находит соответствие правила авторизации. Рассмотрим пример, в котором корневой виртуальный каталог содержит одно правило: а подкаталог - другое правило: В этом случае пользователь dan сможет получить доступ к любому ресурсу корневого каталога, но не получит никакого доступа к ресурсам из подкаталога. Если же вы поменяете местами эти два правила, то dan получит доступ только к ресурсам подкаталога, но не получит доступа к ресурсам корневого каталога. Более интересно то, что ASP.NET допускает неограниченную иерархию подкаталогов и правил авторизации. Например, вполне возможно иметь виртуальный каталог с правилами авторизации, подкаталог, определяющий дополнительные права, и еще один подкаталог внутри этого подкаталога, в котором определен свой набор правил. Проще всего понять процесс авторизации в этом случае - представить все правила в виде единого списка, начинающегося с каталога, в котором находится запрошенная страница. Если все эти правила обработаны и соответствие не найдено, ASP.NET начинает читать правила авторизации из родительского каталога, затем из каталога, родительского по отношению к этому, и т.д. - до тех пор, пока соответствие не будет найдено. Если никаких подходящих правил не найдено, ASP.NET в конечном итоге применяет правило Обычно установка прав доступа к файлам на уровне каталога - самый ясный и легкий подход. Однако существует возможность ограничить доступ к определенным файлам за счет добавления дескрипторов Дескрипторы location размещаются вне главного дескриптора В этом примере открывается доступ ко всем файлам приложения за исключением SecuredPage.aspx и AnotherSecuredPage.aspx, которые имеют правило авторизации, запрещающее анонимный доступ к ним. Для облегчения понимания и сопровождения системы безопасности веб-сайта пользователей часто объединяют в категории, называемые ролями. Если нужно управлять приложением масштаба предприятия, которое поддерживает тысячи пользователей, понять значение ролей несложно. Если бы пришлось определять права доступа для каждого индивидуального пользователя, это было бы утомительно, изменять это было бы трудно, а не совершить при этом ошибок - практически невозможно. Сама по себе аутентификация с помощью форм роли не поддерживает, но наряду с Membership API в ASP.NET доступен интерфейс API Roles
, который представляет собой готовую к использованию реализацию поддержки и управления ролями для приложений. Кроме того, если вы не хотите использовать эту инфраструктуру, достаточно легко создать собственную, которая разделит пользователей на соответствующие группы на основе их удостоверений. После определения для ролей можно создавать правила авторизации. Фактически эти правила выглядят точно так же, как показанные ранее правила, специфичные для пользователей. Например, следующие правила авторизации запрещают доступ анонимным пользователям, разрешая его двум конкретным пользователям (dan и alex) и двум группам (Manager и Supervisor). Доступ всем прочим пользователям запрещен: Например, рассмотрим, что произойдет, если вы разрешите доступ группе, которая содержит определенного пользователя, а затем явно закроете доступ этому пользователю. Или наоборот - разрешив доступ пользователю по имени, вы закроете доступ группе, в которую он входит. В этих сценариях можно ожидать, что более тонко детализированные правила (касающиеся пользователя) получат приоритет по отношению к более общим правилам (касающимся групп). Или же вы можете ожидать, что более ограничивающие правила всегда будет иметь более высокий приоритет, как это принято в Windows. Однако ни один из этих подходов не используется ASP.NET. Вместо этого ASP.NET просто применяет первое подходящее правило. В результате решающее значение имеет порядок определения правил
. Рассмотрим пример: Ниже описано, как ASP.NET разбирает эти правила: В этом примере доступ пользователю alex будет разрешен независимо от групп, к которым он принадлежит. Всем пользователям из роли Guest доступ будет закрыт. Если alex входит в Guest, доступ ему остается открытым, потому что специфичное для пользователя правило найдено первым. Далее всем пользователям из группы Manager доступ открыт. Единственным исключением будут те, что входят и в группу Manager и в Guest. Правило Guest определено раньше в списке, поэтому данным пользователям вход уже закрыт. Затем доступ закрывается пользователю dan. Но если dan входит в группу Manager, доступ для него остается открытым. Любым пользователям, относящимся к группе Supervisor, кроме тех, доступ для которых был открыт или закрыт предыдущими правилами, доступ открывается. И, наконец, для всех прочих пользователей доступ закрыт. Имейте в виду, что все эти перекрывающиеся правила могут также охватывать множество каталогов. Например, подкаталог может быть закрыт для пользователя, в то время как родительский каталог может быть открыт для пользователя в его группе. В этом примере при доступе к файлам подкаталога первым применяется правило, специфичное для пользователя. Авторизация на основе URL - один из краеугольных камней авторизации ASP.NET. Однако в ASP.NET также используется другой тип авторизации, который часто пропускается или игнорируется многими разработчиками. Это авторизация на основе файлов, реализуемая модулем FileAuthorizationModule
. Авторизация на основе файлов работает, только в случае применения Windows-аутентификации. Если же используется специальная аутентификация или аутентификация с помощью форм, файловая авторизация не применяется. Чтобы понять суть файловой авторизации, необходимо разобраться, как операционная система Windows обеспечивает безопасность файловой системы. В случае файловой системы NTFS можно установить списки ACL (access control list - список контроля доступа)
, указывающие идентичность пользователей и ролей, которым открыт или запрещен доступ к индивидуальным файлам. Модуль FileAuthorizationModule просто проверяет права доступа к запрошенному файлу, определенные Windows. Например, если запрашивается веб-страница, FileAuthorizationModule проверяет, имеет ли текущий аутентифицированный IIS пользователь права доступа к соответствующему файлу.aspx. Если не имеет, то код страницы не выполняется и пользователь получает сообщение о запрете доступа. Новые пользователи ASP.NET часто удивляются, почему файловая авторизация должна быть реализована отдельным модулем, и почему бы ни положиться в этом на операционную систему? Чтобы понять необходимость в модуле FileAuthorizationModule, необходимо вспомнить, как ASP.NET выполняет код. Если не включено заимствование прав, ASP.NET выполняется от имени фиксированного пользовательской учетной записи, такой как ASPNET. Операционная система Windows будет проверять, имеет ли учетная запись ASPNET права, необходимые для доступа к файлу.aspx, но она не выполнит ту же проверку для пользователя, аутентифицированного IIS. Модуль FileAuthorizationModule заполняет этот пробел. Он осуществляет проверку авторизации с учетом контекста безопасности текущего пользователя. В результате системный администратор может устанавливать права доступа к файлам или папкам и контролировать доступ к частям приложения ASPNET. Обычно проще и удобнее использовать правила авторизации в файле web.config. Однако если необходимо воспользоваться преимуществами существующих привилегий Windows в локальной или корпоративной сети, то это можно сделать. 6
ответов
Протокол HTTP не имеет аналогов по дизайну, каждый запрос выполняется отдельно и выполняется в отдельном контексте. Идея управления сеансом заключается в том, чтобы отправлять запросы от одного и того же клиента в том же контексте. Это делается путем выдачи идентификатора сервером и отправки его клиенту, тогда клиент сохранит этот идентификатор и повторно отправит его в последующих запросах, чтобы сервер мог его идентифицировать. В типичном случае браузера-сервера; браузер управляет списком пар ключ/значение, известный как файлы cookie, для каждого домена: Веб-ориентированные языки программирования/фреймворки предоставляют функции для обработки файлов cookie на более высоком уровне, например, PHP предоставляет setcookie / $_COOKIE , чтобы писать/читать файлы cookie. Назад к сеансам. В типичном случае браузера-сервера (снова) серверное управление сеансом использует преимущества управления файлами cookie на стороне клиента. Управление сеансом PHP устанавливает cookie идентификатора сеанса и использует его для идентификации последующих запросов. Теперь вернемся к вашему вопросу; так как вы будете ответственны за проектирование API и документируете его, реализация будет вашим решением. Вы в основном должны Конечно, вы можете опираться на существующую инфраструктуру, вы можете использовать управление сеансами PHP (которое позаботится о 1..2 и части аутентификации 4.) в вашем приложении и потребовать, чтобы на стороне клиента выполнялись файлы cookie (что будет заботиться о 3.), а затем вы оставите всю свою логику приложения. (*) У каждого подхода есть минусы и профи, например, использование параметра запроса GET проще реализовать, но может иметь последствия для безопасности, поскольку запросы GET регистрируются. Вы должны использовать https для критических (все?) Приложений. Управление сеансом является ответственностью сервера. Когда сеанс создается, маркер сеанса генерируется и отправляется клиенту (и сохраняется в файле cookie). После этого в следующих запросах между клиентом и сервером клиент отправляет токен (обычно) в качестве файла cookie HTTP. Все данные сеанса хранятся на сервере, клиент сохраняет только токен. Например, чтобы начать сеанс в PHP, вам просто нужно: Session_start(); // Will create a cookie named PHPSESSID with the session token
// If username and password match, you can just save the user id on the session
$_SESSION["userID"] = 123;
Теперь вы можете проверить, аутентифицирован ли пользователь или нет: If ($_SESSION["userID"])
echo "user is authenticated";
else
echo "user isn"t authenticated";
Если вы хотите, вы можете создать сеанс только для аутентифицированного пользователя: If (verifyAccountInformation($user,$pass)){ // Check user credentials
// Will create a cookie named PHPSESSID with the session token
session_start();
$_SESSION["userID"] = 123;
} Существует множество способов для аутентичных пользователей, как для веб-приложений, так и для API. Существует несколько стандартов, или вы можете написать свою собственную авторизацию/и/или аутентификацию. Я хотел бы указать разницу между авторизацией и аутентификацией. Во-первых, приложение должно аутентифицировать пользователя (или клиента api), из которого поступает запрос. Как только пользователь прошел аутентификацию, на основе приложения идентификации пользователя необходимо определить, какой аутентифицированный пользователь имеет разрешение на выполнение определенного приложения (авторизации). Для большинства традиционных веб-приложений нет четкой детализации в модели безопасности, поэтому, как только пользователь аутентифицируется, он в большинстве случаев также и уполномочен выполнять определенные действия. Однако эти две концепции (аутентификация и авторизация) должны быть как две различные логические операции. Кроме того, в классических веб-приложениях после аутентификации и авторизации пользователя
(в основном путем поиска пары имени пользователя и пароля в базе данных), информация авторизации и идентификации записывается в хранилище сеансов. Хранилище сеансов не обязательно должно быть на стороне сервера, так как большинство приведенных выше ответов предлагает, оно также может быть сохранено в cookie на стороне клиента, зашифрованном в большинстве случаев. Например, инфраструктура PHP CodeIgniter делает это по умолчанию. Существует ряд механизмов защиты сеанса на стороне клиента, и я не вижу, чтобы этот способ хранения данных сеанса был менее безопасным, чем хранение sessionId, который затем просматривается в хранилище сеансов на стороне сервера. Кроме того, хранение клиентской стороны сеанса довольно удобно в распределенной среде, поскольку устраняет необходимость в разработке решения (или с использованием уже существующего) для управления центральным сеансом на стороне сервера. Кроме того, аутентификация с помощью простой пары "пароль пользователя" не обязательно должна выполняться в любом случае через специальный код, который ищет соответствующую запись пользователя в базе данных. Например, базовый протокол аутентификации или дайджест аутентификации , На проприетарном программном обеспечении, таком как платформа Windows, существуют также способы аутентификации пользовательского корыта, например, ActiveDirectory В конкретном случае использования при разработке веб-службы, использующей протокол SOAP в качестве протокола, существует также WS-Security расширение для протокола SOAP. Со всеми этими словами я бы сказал, что ответы на следующий вопрос вводят процедуру принятия решения о выборе механизма авторизации/аутентификации для WebApi: 1) Какая целевая аудитория, общедоступная ли она или только для зарегистрированных (платных) участников? И многое другое. Надеюсь, что это очистит бит, так как в уравнении есть много переменных. 16.01.2017 Ромчик Доброго времени суток. В данной статье мы остановимся на таком понятии как http
basic
authentication
или http авторизация
. Для чего нужна http basic authentication и как настроить http авторизацию. И в качестве примера мы сделаем HTTP авторизацию для админки WordPress. Ну что поехали. Первое, что мы сделаем – это разберемся с понятием http авторизации. HTTP authentication – это протокол, описанный в стандартах HTTP 1.0/1.1. Работает следующим образом: Главное отличие – это уровень безопасности. Мы остановимся на basic – это самая небезопасная схема. Но при использовании HTTPS, является относительно безопасным. Схема Basic является наиболее простой схемой, при которой логин и пароль передаются в заголовке «Authorization» в незашифрованном виде. Если вы используете SSL на своем сайте, то вы можете дополнительно настроить http basic authentication для админки WordPress. А это дополнительная защита. Небольшое отступление: у меня ОС Windows 10 и OpenServer, который расположен по адресу e:\OpenServer\ Первое, что нам необходимо сделать – это создать файл.htpasswd Затем перейти на один из сервисов генерации пароля (или воспользоваться утилитой htpasswd у кого Linux), например https://truemisha.ru/tools/htpasswd-generator И сгенерировать пароль Скопируем строку и вставим в только что созданный файл.htpasswd Admin:$apr1$grwacq2z$g1Z5bNYkD0vJKF2HllrRw/
Отлично. Теперь необходимо настроить apache с помощью файла.htaccess. Переходим в каталог с админкой, по умолчанию это wp-admin и в нем создаем файл.htaccess. И в него помещаем следующий код: AuthType Basic
AuthName "Input username and password"
AuthUserFile e:\OpenServer\.htpasswd
Require valid-user
Где в AuthName указываем текст сообщения, в AuthUserFile указываем путь к файлу.htpasswd. Сохраняем и проверяем. При попытке перейти к админке WordPress сервер запросит http авторизацию. Если мы не введем логин и пароль, то сервер вернет ошибку «Authentication required» Вводим логин и пароль (Логин: Admin, а пароль: admin) И видео к данной статье: Мы с вами дополнительно защитили админку WordPress http авторизацией. Но помните, что мы использовали http basic authentication, а данный тип передает логин и пароль в незашифрованном виде. Используйте https. А в следующей статье мы рассмотрим как организовать http авторизацию с помощью плагина для WordPress (когда у нас нет доступа к настройкам apache). Так, что не пропускайте выхода новых статей подписавшись. Механизм Web-сервисов позволяет использовать 1С:Предприятие 8 как набор сервисов в сложных распределенных и гетерогенных системах, а также позволяет интегрировать 1С:Предприятие 8 с другими промышленными системами использованием сервисно-ориентированной архитектуры. Публикация веб-сервисов выполняется через конфигуратор, для этого нужно открыть окно Публикация на веб-сервере
, нажав Администрирование -> Публикация на веб-сервере...
Процесс публикации описывать не буду, для каждого случая он свой, но обычно достаточно выбрать веб-сервер, указать каталог публикации и нажать на кнопку Опубликовать
. Послу публикации в указанном каталоге создастся файл default.vrd. Его содержимое будет примерно таким:
Тег ws
содержит описание публикации веб-сервисов. Если мы обратимся к веб-сервису с помощью браузера, введя его адрес, например, http://192.168.0.85/DemoSSL/ws/exchange.1cws
, то увидим окно авторизации, которое попросит ввести логи и пароль пользователя 1С: Создадим пользователя 1С с логином User
и паролем 123456
, от имени которого в дальнейшем будет происходить автоматическая авторизация.
Контроль доступа к определенным файлам
Конфигурирование доступа для определенных ролей
Файловая авторизация
Cookies
Сессия
API веб-приложений?
2) Выполняется ли это или * NIX или платформа MS
3) Какое количество пользователей ожидается
4) Насколько чувствителен API данных с данными (более сильные и слабые механизмы аутентификации)
5) Существует ли какая-либо служба единого входа, которую вы могли бы использовать HTTP authentication
HTTP авторизация для админки WordPress
Заключение
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/DemoSSL"
ib="File="C:\1с\БиблиотекаСтандартныхПодсистем\DemoSSL";">
enable="true"/>
enable="true"/>
enable="true"/>
enable="true"/>
enable="true"/>
enable="true"/>
enable="true"/>
Обратите внимание, адрес к веб-сервису строится по следующему шаблону:
2. Окно авторизации веб-сервиса
[СетевойАдресКомпьютера]/[ИмяПубликации]/ws/[АдресВебСервиса]
Замечено, окно авторизации корректно работает с логином, написанным на латинице, иначе может появится ошибка:
а?б?б?аЕаНб?аИб?аИаКаАб?аИб? аПаОаЛб?аЗаОаВаАб?аЕаЛб? аНаЕ аВб?аПаОаЛаНаЕаНаА.
An error occurred processing this request.
Допустим, необходимо, что бы веб-сервис exchange.1cws
не требовал авторизацию. Для этого из файла default.vrd удаляем информацию о данном веб-сервисе, то есть удаляем строчки:
Создаем рядом с файлом default.vrd файл с именем exchange и расширением 1cws (exchange.1cws). Откроем файл текстовым редактором, укажем кодировку UTF-8 без BOM и запишем следующие строчки:
name="Exchange"
connectString="File="C:\1с\БиблиотекаСтандартныхПодсистем\DemoSSL";usr="User";pwd="123456""/>
Значения атрибутов тэга service берем из следующих мест:
- namespace - указываем пространство имен веб-сервиса (см. рисунок 3);
- name - указываем имя сервиса (см. рисунок 1);
- connectString - указывается расположение информационной базы (см. рисунок 4) + логин и пароль пользователя, от имени которого будет производиться авторизация. Для файлового варианта и клиент-серверного значение данного атрибута будет отличаться. Пример для клиент-серверного варианта: Srvr="localhost";Ref="DemoSSL";usr="User";pwd="123456"
 |
| 3. Пространство имен веб-сервиса |
UPD 15.03.2016:
Если стоит апач(а может и не только) — то по дефолту 1С пытается авторизовать пользователя системы вида: \\\HOSTNAME$, если в базе создать такого пользователя с авторизацией системы — то плясать с бубном не нужно, а дальше рулите ролями.
UPD 12.04.2017:
Создать в операционной системе пользователя, под ним настроить запуск Apache. В 1С завести пользователя, установить галку Аутентификация операционной системы
и выбрать пользователя Apache. Правда при такой настройке не получится выборочной аутентификации - будут доступны все сервисы, связанные с WEB.