Как я защитил бы API от злоупотребления?
Я начал рыть меня, и я нашел одно потенциальное преимущество использования setUp(). Если какие-либо исключения будут выданы во время выполнения setUp(), то JUnit распечатает очень полезное отслеживание стека. С другой стороны, если исключение выдается во время объектной конструкции, в сообщении об ошибке просто говорится, что JUnit не мог инстанцировать тестового сценария, и Вы не видите номера строки, где отказ произошел, вероятно, потому что JUnit использует отражение для инстанцирования тестовых классов.
Ни одно из этого не относится к примеру создания пустого набора, так как это никогда не будет бросать, но это - преимущество setUp() метод.
5 ответов
Если вы не хотите внедрять учетные записи пользователей, как насчет того, чтобы те, кто хочет использовать API, подписались на ключ / секрет API, который вы можете использовать для ограничения скорости.
В одной компании, в которой я работал, мы реализовали регулирование для всех клиентов-неплательщиков, с ограничением определенного количества запросов в день, теоретически настраивается для каждой конечной точки API. Если вам нужно было указывать уникальный идентификатор в качестве ключа приложения в каждом запросе, в QueryString для облегченных API или в XML-запросе POST для более сложных API. Для конечных пользователей, не использующих общедоступный API, вы можете вместо этого передать токен аутентификации.
Если вы предоставляете общедоступный API, не требуя какой-либо аутентификации или авторизации, вам придется прибегнуть к регулированию на основе IP-адреса. Но нетрудно создать облегченную веб-страницу инициализации, которая позволяет людям подписываться на доступ к API.
Логика вашего приложения может регулироваться в зависимости от количества запросов, как это сделали мы,
Требовать токен для загрузки и ограничить токен с помощью CAPTCHA. Используемый код будет примерно таким:
// 1st request
var uploadToken = api.RequestToken(sessionIdFromUser);
if (uploadToken.RequireChallenge) {
// requires challenge due to per IP limiting
// uploadToken.Captcha could be a URL
DisplayView(uploadToken.Captcha, uploadToken.SessionId);
return;
}
api.Upload(uploadToken, captchaFromUser, byte[]);
Как уже упоминалось в этой ветке, ключи API часто являются выходом в таких ситуациях. Тот факт, что на вашем сайте нет учетных записей пользователей, не имеет значения: ключ API идентифицирует приложение , а не пользователя . (Фактически, если у вашего сайта есть пользователи, вам понадобятся отдельные механизмы для идентификации приложения и пользователя в вызове API - здесь OAuth очень полезен.)
Если вы не хотите создавать собственного разработчика процесса регистрации, процесса выдачи ключей API, кода регулирования и т. д. Я бы посоветовал вам взглянуть на мою компанию WebServius (www.webservius.com), которая предоставляет уровень управления размещенным API поверх предоставляемого вами API.