Существует ли способ потребовать ключа API в URL / или некоторый другой способ передать сервис закрытый ключ для предоставления доступа к данным?
У меня есть это прямо сейчас...
using System;
using System.Data.Services;
using System.Data.Services.Common;
using System.Collections.Generic;
using System.Linq;
using System.ServiceModel.Web;
using Numina.Framework;
using System.Web;
using System.Configuration;
[System.ServiceModel.ServiceBehavior(IncludeExceptionDetailInFaults = true)]
public class odata : DataService {
public static void InitializeService(DataServiceConfiguration config) {
config.SetEntitySetAccessRule("*", EntitySetRights.AllRead);
//config.SetServiceOperationAccessRule("*", ServiceOperationRights.All);
config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
}
protected override void OnStartProcessingRequest(ProcessRequestArgs args) {
HttpRequest Request = HttpContext.Current.Request;
if(Request["apikey"] != ConfigurationManager.AppSettings["ApiKey"])
throw new DataServiceException("ApiKey needed");
base.OnStartProcessingRequest(args);
}
}
... Это работает, но это не прекрасно, потому что Вы не можете достигнуть метаданные и обнаружить сервис через Добавить Сервисный Ссылочный проводник. Я мог проверить, находится ли $metadata в URL, но он походит на взлом. Существует ли лучший путь?
Я бы предложил использовать заголовок авторизации для передачи apiKey вместо того, чтобы передавать его в строке запроса. Это то, для чего он существует, и это помогает сохранить apiKey в лог-файлах.
Я не думаю, что есть что-то неправильное в проверке наличия '$metadata' в url. Вы пишете код на стороне сервера, а сервер владеет пространством URI, поэтому принятие решений на основе текста в url запроса - это то, чем занимается сервер. Вы можете использовать что-то вроде:
if (requestUrl.Segments.Last().Replace('/','') != '$metadata')
вместо поиска по всей строке uri, если это поможет вам почувствовать себя менее неприятно!
Вы можете проверить тип запроса и позволить вызовам wsdl проходить без ключа api.
Я не уверен, каковы ваши цели api, но вы могли бы использовать сертификат клиента.