Кто вызывает мой WebService?

Question

У меня есть веб-служба, которая находится на внутреннем сервере. Его можно вызвать с любого веб-сайта в нашей сети.

Все больше и больше разработчиков начинают его использовать. Вероятно, 20+ страниц используют эту услугу, и число растет быстро. Через год я вижу, кто-то спрашивает, какие страницы используют эту услугу и какие методы.

Я хотел был бы зарегистрировать URL-адрес страниц, которые используют мой веб-сервис по мере поступления запроса. Было бы также полезно знать метод, который они вызывают. Мне нужно что-то сделать таким образом, чтобы это не влияет на клиентские веб-сайты. Сначала я подумал, что могу написать код в global.asax.

Я добавил некоторый код в Application_BeginRequest, чтобы регистрировать детали объекта запроса, но, похоже, ничего не содержится в запрашивающем URL-адресе.

Что мне не хватает? Должен ли я смотреть на другой объект?

Спасибо.

Answer 1

@David Stratton

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

Я должен был упомянуть, что я создавал веб-прокси, которые большинство моих пользователей использовали для совершения вызовов против моего веб-сервиса. Мой клиент вообще НЕ использует прокси-сервер, создаваемый Visual Studio.

Вот что сделал:

Я снова генерироваться мой веб-прокси клиента, и добавил вызовы регистрировать HttpContext клиента перед каждым вызовом. Поскольку прокси-сервер работает на клиенте, у него есть доступ ко всему, что мне нужно. Это позволило мне записать все о клиенте и конкретном вызове, который они делали. Я понимаю, что это не будет работать в большинстве случаев. Но все мои клиенты - это внутренние веб-сайты.

Это также имело то преимущество, что клиентам не пришлось изменять свой код вообще. Я просто дал им новую DLL. Задача решена. Я получаю все данные отслеживания, которые я хочу, и им не нужно было изменять их код.

Я застрял, пытаясь решить проблему с точки зрения веб-службы.

Я понимаю, что в этой реализации все еще есть целое, потому что кому-то не нужно использовать мой клиентский прокси для вызова моего сервиса. Наверное, я могу заставить это в какой-то момент в будущем. На данный момент они могут позволить Visual Studio генерировать веб-прокси для моего сервиса. Однако, если они это сделают, я думаю, мне все равно. Это не рекомендуемый способ позвонить мне. Я думаю, что единственный, кто делает это, - это веб-сайт ASP.NET 1.1. Когда они будут обновлены, они, вероятно, перейдут на мой сгенерированный прокси.

Answer 2

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

Я уверен, что вы уже знаете это, но весь смысл веб-службы заключается не в том, чтобы знать и не заботиться о том, кто его вызывает.

Answer 3

Единственное, что вы, вероятно, можете получить от потребителя, это IP-адрес без изменения интерфейса.

Если вы можете изменить это, вы можете сделать это, например. добавив аутентификацию и протоколирование, кто звонит, или с помощью простого принципа «токена».

Однако оба метода требуют, чтобы вы изменили интерфейс и, следовательно, отменили обратную совместимость - чего вы никогда не должны делать.

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

Answer 4

Не нарушая существующих пользователей, это будет сложно. HttpContect.Current.RequestUrl просто вернет URL-адрес, используемый для вызова вашего веб-сервиса, а не с веб-страницы.

Самый близкий, который вы можете сделать, не нарушая существующие приложения и не заставляя разработчиков изменять их, - это захватить HttpContext.Current.Request.UserHostAddress, чтобы вы могли хотя бы получить IP-адрес машины, вызывающей вашу службу.

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

Edit - добавил

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

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

Answer 5

Я успешно использовал ...

Dim strReferrer As String = HttpContext.Current.Request.UrlReferrer.AbsoluteUri

получить страницу вызова, призывающую мой WEB API 2 Web Service.