Каморка

Я тут топик про ArcGIS недавно открыл. Это по той же теме, но вопрос поставлю по другому.

Есть веб сервер, который исполняет REST запросы клиентов. Запросы требуют аутентификации. Назовем условно это сервер WEB_REST.
Есть другой сервер, с которого который запускается Silverlight приложение. Назовем его WEB_Silverlight. Это приложение и шлет REST запросы к WEB_REST.
Задача - не исполнять REST запросы, которые пришли не от WEB_Silverlight, например, пользователь ручками набрал запрос в браузере. Что и как нужно сконфигурировать?

Спасибо.

Димас писал(а):Я тут топик про ArcGIS недавно открыл. Это по той же теме, но вопрос поставлю по другому.

Есть веб сервер, который исполняет REST запросы клиентов. Запросы требуют аутентификации. Назовем условно это сервер WEB_REST.
Есть другой сервер, с которого который запускается Silverlight приложение. Назовем его WEB_Silverlight. Это приложение и шлет REST запросы к WEB_REST.
Задача - не исполнять REST запросы, которые пришли не от WEB_Silverlight, например, пользователь ручками набрал запрос в браузере. Что и как нужно сконфигурировать?

Спасибо.

Наверняка WEB_Silverlight добавляет в свой HTTP request какие-то свои headers. Можно сконфигурировать WEB_REST, чтобы он пропускал запросы только с этими headers.

Victor Okunev писал(а):Наверняка WEB_Silverlight добавляет в свой HTTP request какие-то свои headers. Можно сконфигурировать WEB_REST, чтобы он пропускал запросы только с этими headers.

Ok, how to configure WEB_REST?

Димас писал(а):

Victor Okunev писал(а):Наверняка WEB_Silverlight добавляет в свой HTTP request какие-то свои headers. Можно сконфигурировать WEB_REST, чтобы он пропускал запросы только с этими headers.

Ok, how to configure WEB_REST?

Это зависит от конкретного HTTP сервера. Пример для IIS: http://www.iis.net/ConfigReference/syst ... canHeaders

Сделай все REST методы POST вместо GET - уже в браузере не понабираешь.

Ну, или добавляй к query string какой-нибудь коротко живущий токен, который на web_rest будет проверяться перед исполнением запросов.

Можно еще файервол рулс прописать для web_rest, чтобы он работал только с web_silverlight. Но это уже к админам.

Gadi писал(а):Можно еще файервол рулс прописать для web_rest, чтобы он работал только с web_silverlight. Но это уже к админам.

А если там кучка виртуальных веб сайтов?

Gadi писал(а):Сделай все REST методы POST вместо GET - уже в браузере не понабираешь.

Хи

Gadi писал(а): Ну, или добавляй к query string какой-нибудь коротко живущий токен, который на web_rest будет проверяться перед исполнением запросов.

Про Винды и веб сервис не знаю, но Альфреско и Зимбра сначала аутентифицируют пользователя, генерируют токен, а потом к каждому запросу пристегивается этот токен. После сеанса токен инвалидируется.
Для веб сервиса наверное придется предусмотреть периодическое обновление токена.

Stanislav писал(а):

Gadi писал(а):Сделай все REST методы POST вместо GET - уже в браузере не понабираешь.

Хи

ну да, защита от непродвинутых детей Я же не знаю всех цеелй - может этого достаточно

Stanislav писал(а):

Gadi писал(а): Ну, или добавляй к query string какой-нибудь коротко живущий токен, который на web_rest будет проверяться перед исполнением запросов.

Про Винды и веб сервис не знаю, но Альфреско и Зимбра сначала аутентифицируют пользователя, генерируют токен, а потом к каждому запросу пристегивается этот токен. После сеанса токен инвалидируется.
Для веб сервиса наверное придется предусмотреть периодическое обновление токена.

похоже, веб сервисы сделаны для "внутреннего" потребления. Ну так и ПЕРЕД запросом генерить токен, записывать его в бд, присоединять к запросу. Веб сервис проверяет токен на валидность в бд, (если все впорядке) выполняет запрос, удаляет токен.

Веб сервисы не мои, это некий ESRI ArcGIS Server. Токены там поддерживаются, все так и работает, как описывалось в предыдущем посте. Проблема в том, что ESRI клиентские программы тоже понимают токены, т.е. клиент только введет своё имя/пароль и клиент получит токен от сервера. Пользователь даже не узнает, что там токены передаются.

Похоже фильтрация headers решит проблемму. Точнее, я собираюсь использовать REFERER. Если REFERER не соответствует URL с которого запускается Silverlight или REFERER вообще пустой, то запрос будет прерван. Это называется URL Rewrite Module для IIS.
http://learn.iis.net/page.aspx/461/crea ... te-module/

Вроде должно работать.

Димас писал(а):Веб сервисы не мои, это некий ESRI ArcGIS Server. Токены там поддерживаются, все так и работает, как описывалось в предыдущем посте. Проблема в том, что ESRI клиентские программы тоже понимают токены, т.е. клиент только введет своё имя/пароль и клиент получит токен от сервера. Пользователь даже не узнает, что там токены передаются.
Похоже фильтрация headers решит проблемму. Точнее, я собираюсь использовать REFERER. Если REFERER не соответствует URL с которого запускается Silverlight или REFERER вообще пустой, то запрос будет прерван. Это называется URL Rewrite Module для IIS.
http://learn.iis.net/page.aspx/461/crea ... te-module/
Вроде должно работать.

Уууууу, флаг в руки, скейт в ноги и икарус навстречу.... Мы исследовали (пару-тройку лет назад) referer на предмет его заполнябельности различными браузерами - далеко не все и не всегда заполняют это поле... Так что намучаетесь с клиентами... Хотя может сейчас это поле уже стало обязательным?

Stanislav писал(а):Уууууу, флаг в руки, скейт в ноги и икарус навстречу.... Мы исследовали (пару-тройку лет назад) referer на предмет его заполнябельности различными браузерами - далеко не все и не всегда заполняют это поле... Так что намучаетесь с клиентами... Хотя может сейчас это поле уже стало обязательным?

All users will use IE 8 or FireFox only. Did you have the issue with that browsers?

Димас писал(а):

Stanislav писал(а):Уууууу, флаг в руки, скейт в ноги и икарус навстречу.... Мы исследовали (пару-тройку лет назад) referer на предмет его заполнябельности различными браузерами - далеко не все и не всегда заполняют это поле... Так что намучаетесь с клиентами... Хотя может сейчас это поле уже стало обязательным?

All users will use IE 8 or FireFox only. Did you have the issue with that browsers?

В то время не было ни ИЕ8 ни ФайрФокса8... Попробуйте...

Теоретически, для подобной фильтрации существует HTTP header User-Agent. Проблема в том, что в него (как и в любой другой header) можно записать все, что угодно.

Из вопроса не совсем понятно, что именно нужно, вообще не давать доступ, если клиент не тот, что нужен? Тогда -- HTTPS + client certificate (если нужна 100% гарантия) или же реализовывать handshake между клиентом и сервером самостоятельно: и клиент, и сервер знают некий salt, который используют для генерации токена. Второй вариант более уязвим, так как всегда можно попытаться декомпилировать исходный код клиента и узнать, как именно handshake реализован.

В качестве третьего варианта (если silverlight client запускается с web page) можно посмотреть crossdomainpolicy.xml: http://msdn.microsoft.com/en-us/library ... s.95).aspx

MaskedRhyme писал(а):Теоретически, для подобной фильтрации существует HTTP header User-Agent. Проблема в том, что в него (как и в любой другой header) можно записать все, что угодно.
...всегда можно попытаться декомпилировать исходный код клиента и узнать, как именно handshake реализован.

В моём случае необходимо сделать "защиту от дурака", т.е. полагаем, что никто декомпиляцией заниматься не будет.

MaskedRhyme писал(а):Из вопроса не совсем понятно, что именно нужно, вообще не давать доступ, если клиент не тот, что нужен?[/url]

Пользователь имеет все права, чтобы обратиться к веб сервису. Но нельзя давать ему это делать напрямую через URL в браузере или типа того. Только Silverlight приложение должно получать доступ к веб сервису(используя тем не менее привилегии пользователя).