Блог

У меня есть WCF служба, вызываемая $.ajax({ url: 'service.svc?a=1', dataType: "JSONP", ...}) на одной из страниц mysite.com (100% клиентский стек). Я хочу ограничить использование службы mysite.com только для пользователей, возможно ли это сделать, и если да, то как?

Единственная идея, которая у меня есть на данный момент, — это ввести параметр ‘via’, который поможет мне понять, через какой www был получен доступ к моей службе.

PS Я действительно изо всех сил пытаюсь придумать хорошее название, пожалуйста, заполните его, чтобы изменить его!

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

1) мы создали разные, но необходимые файлы обработчиков в том же проекте

2) Этот файл-обработчик вызывает нашу службу WCF

3) Поскольку наш инструмент основан на Сети, поэтому мы проверяем идентификатор сеанса при вызове обработчика

4) Если идентификатор сеанса совпадает, мы передаем данные, иначе мы показываем сообщение об истечении срока действия сеанса

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

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

Чтобы иметь возможность ограничить использование определенной группой пользователей (в вашем случае посетителей mysite.com ), пользователи должны отправить что-то (ключ, пароль, токен) в ваш сервис, чтобы идентифицировать себя. Если вы сохраните этот токен в своем клиентском приложении (например, javascript), люди могут просто извлечь токен и использовать его любым удобным для них способом. Так что это невозможно. Вы также не можете доверять никаким данным, отправляемым браузером (например, через param), потому что их всегда можно подделать с помощью простых инструментов. Это практически все варианты, которые у вас есть.

Реальный вопрос в том, зачем вам защищать этот контент, если он уже общедоступен через сам веб-сайт? Можно было бы легко создать простой скребок для получения вашего контента, если бы захотели.

Если вы размещаете свое приложение в IIS, вы можете просто добавить к себе web.config:

 <system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Access-Control-Allow-Origin" value="*" />
      <add name="Access-Control-Allow-Methods" value="GET, POST" />
    </customHeaders>
  </httpProtocol>
</system.webServer>
  

Для Access-Control-Allow-Origin вы можете задать свой адрес приложения: Access-Control-Allow-Origin: http://domain1.com , http://domain2.com

 <system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Access-Control-Allow-Origin" value="http://domain1.com" />
      <add name="Access-Control-Allow-Methods" value="GET, POST" />
    </customHeaders>
  </httpProtocol>
</system.webServer>
  

Вы также можете достичь цели, написав поведение, которое добавляет определенный заголовок к каждому сообщению. Вот руководство: http://blogs.msdn.com/b/carlosfigueira/archive/2012/05/15/implementing-cors-support-in-wcf.aspx

Существует постоянная CorsConstants .Вместо Origin вы можете установить свой домен.

Чтобы проверить, имеет ли ответ требуемый заголовок, вы можете использовать fiddler.

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

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

Мой сервер реализует ETag заголовки и 304 Not Modified заголовки для определенных файлов, которых в противном случае было бы достаточно с временным кэшем. Это делается для экономии пропускной способности и по-прежнему позволяет видеть, к чему был получен доступ. Затем маршрут пользователя к цели отслеживается на стороне сервера. Если этапы выполнены, пользователю предоставляется credit доступ к дорогостоящему ресурсу. Кредиты могут добавляться, так что одновременный доступ будет работать. Помимо этого, я также устанавливаю файлы cookie в браузере пользователя во время маршрута и тестирую их позже. Поддельные клиенты, как известно, плохо разбираются в файлах cookie, если они вообще их знают.

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