Я планирую использовать Laravel
в моем следующем веб-проекте, для backend
, Используя встроенную функциональность Laravel, я создам API
оказание услуг. Поэтому моя главная забота сейчас — это безопасность такого сервиса. Промежуточное программное обеспечение Laravel для API кажется простым в использовании, но оно не обладает той гибкостью, которая мне нужна. Или, по крайней мере, я не вижу, сможет ли он справиться с моим сценарием или нет.
Вот мои вопросы. Надеюсь, кто-то может ответить на них.
Можно ли применить другую логику регулирования в зависимости от того, вошел ли пользователь в систему или нет? (выполнить 2-3 проверки дроссельной заслонки) Или выполнить несколько разных проверок дроссельной заслонки в рамках одного запроса.
Где хранится история IP-адресов, которые вызывают API? Это в заголовках HTTP или в каком-то кеше / memcached / redis?
Если я хочу заблокировать IP-адрес, а затем выполнить проверку, если он заблокирован — есть ли хорошее руководство о том, как хранить такую информацию? Как интегрировать это с дросселированием? Примеры схем или что-нибудь? Совет был бы хорош 🙂
Вот краткий пример логики, которую я хочу реализовать в конце концов:
GET: /api/invoice/1
правила:
if IP throttling is enabled
then I don't want to check whether user is logged in or not
if (user is unauthorized) {
throttle by IP.
Throttle after 10 attempts within 1 minute
if (number of times throttled within last 5 minutes = 0) {
Retry-After: 1 minute
}
else if (number of times throttled within last 10 minutes > 1) {
Retry-After: 10 minutes
}
else if (number of times throttled within last 30 minutes > 3) {
Retry-After: 3 hours
}
else if (number of times throttled within last 8 hours minutes > 6) {
ban IP for 1 week!!!
}
}
else (user is authorised) {
if (has permission: get_invoices) {
throttle by JWT token.
Throttle after 100 attempts within 1 minute
if (number of times throttled within last 5 minutes = 0) {
Retry-After: 5 minutes
}
else if (number of times throttled within last 30 minutes > 1) {
ban user!!!
}
}
else (user is logged in but doesn't have necessary permission
{
throttle by JWT token.
Throttle after 50 attempts within 1 minute
// apply logic different from user who has permission
}
}
для маршрута № 2, 3, 4 это может быть другая логика.
Поэтому я не могу использовать только одно промежуточное ПО, как в этом примере, потому что оно основано на одном параметре (будь то IP, WTD, домен или другой) и не включает в себя логику запрета
Route::group(['prefix' => 'api', 'middleware' => 'throttle:2,5'], function () {
Route::get('invoice/{id}', function () {
return $some invoice;
});
});
Я хотел бы получить некоторые отзывы по этому вопросу. Я планирую выйти на мировой уровень 🙂
Вот мой ответ на ваши вопросы:
Можно ли применить другую логику регулирования в зависимости от того, вошел ли пользователь в систему или нет? (выполнить 2-3 проверки дроссельной заслонки) Или выполнить несколько разных проверок дроссельной заслонки в рамках одного запроса.
Да, вы можете сделать пользовательское промежуточное ПО а потом вызовите промежуточное программное обеспечение дроссельной заслонки из своего специального промежуточного основываясь на желаемой логике
Где хранится история IP-адресов, которые вызывают API? Это в заголовках HTTP или в каком-то кеше / memcached / redis?
Laravel не регистрирует IP-адреса из коробки. Опять же, вы можете сделать специальное промежуточное программное обеспечение для этого. Чтобы получить IP-адрес, вы можете использовать $request->ip()
Если я хочу заблокировать IP-адрес, а затем выполнить проверку, если он заблокирован — есть ли хорошее руководство о том, как хранить такую информацию? Как интегрировать это с дросселированием? Примеры схем или что-нибудь? Совет был бы хорош 🙂
Да, вы можете встроить эту логику в пользовательское промежуточное ПО, которое вы пишете для Q2. Для хранения / извлечения заблокированных IP-адресов вы можете использовать кеш или БД. Чтобы «интегрировать» с регулированием, вы можете просто использовать оба промежуточных программного обеспечения
Других решений пока нет …