Django React Communication Api
У меня есть путаница, и она убивает изнутри. Когда мы работаем с сайтом, который использует react во фронтенде и Django в бекенде, то мы создаем APIs в django, а затем вызываем конечные точки API в нашем react app для получения данных. Затем заполняет наш фронтенд данными из ответа.
Но мой вопрос в том, что api может использовать любой человек, если он просмотрит исходный код с помощью dev tool. Потому что, API доступны нашему react приложению без какой-либо аутентификации. И так и должно быть. Потому что, когда кто-то впервые заходит на наш сайт без каких-либо учетных данных аутентификации, нам нужно отобразить нашу первую веб-страницу (домашнюю страницу), и API также должен быть доступен на ней.
Но точно так же хакер может сделать много запросов к этой конечной точке сервера и таким образом повлиять на наш сервер, может заставить его упасть.
Первая страница нашего сайта не требует аутентификации. Домашняя страница. Домашняя страница, по сути, не требует авторизации. Поэтому новые люди пытаются получить к ней доступ. Это нормально. Ненормально то, что если кто-то пытается получить доступ к этой конечной точке вне браузера. Мы должны убедиться, что запрос поступает из браузера клиента.
Пожалуйста, помогите мне разобраться в моих путах.
Я пробовал читать много статей. Они рассказывают о jwt. Но речь идет об аутентификации. И первый запрос выдает токен, только на основе имени пользователя и пароля!!!
Это обширная тема, и проблема, которую вы изложили, очень распространена, каждый публичный сервер должен учитывать это, я дам очень краткое резюме того, что, по моему мнению, является хорошим способом решения этой проблемы.
Вы можете проверить user agent, чтобы узнать, пришел ли запрос от браузера или нет, но это, скорее всего, пустая трата времени, user agent устанавливается клиентом и может быть установлен так, как он хочет. Я не очень рекомендую это делать, все, что вы делаете с user agent, должно рассматриваться как необязательное и, вероятно, в попытке сделать пользовательский опыт лучше, в сотрудничестве, так сказать, с пользователем. Тот, кто пытается спамить сервис, скорее всего, изменит свой user agent, если захочет. Так что отдача от потраченного времени, вероятно, довольно низкая. Но если вы хотите взглянуть, вот список пользовательских агентов https://gist.github.com/pzb/b4b6f57144aea7827ae4.
Скорее всего, вы хотите настроить ограничение скорости. Cloudflare - популярный выбор, я не так много знаю о различных сервисах, но, кажется, людям часто нравится https://www.cloudflare.com/learning/bots/what-is-rate-limiting/.
Важно то, что не имеет значения, поступает ли запрос из браузера или нет, в большинстве случаев ограничение скорости работает по ip-адресу, поэтому оно хорошо справляется с блокировкой чрезмерных запросов с одного ip. Затем, конечно, тот, кто стремится эксплуатировать сервис, может получить доступ к нескольким ip и обойти базовое ограничение скорости, и тогда начинается обычная гонка вооружений между стратегиями эксплуатации сервисов и стратегиями защиты, у вас есть распределенный отказ в обслуживании и защита от него https://www.cloudflare.com/ddos/.
Так что это сложная область, вам не нужно углубляться в нее, просто делайте все, что нужно для вашей ситуации, я думаю, это самое важное, всегда полезно знать немного больше, чтобы, если вам когда-нибудь понадобится принять более важные меры предосторожности, вы знали, что делать, поэтому можете почитать об ограничении скорости. Есть и другие стратегии, но ограничение скорости кажется хорошим началом, вы должны легко найти информацию о защите сервера от различных вещей, которые вы не хотите вот еще одна ссылка от cloudflare https://www.cloudflare.com/learning/ddos/how-to-prevent-ddos-attacks/#:~:text=DDoS%20prevention%20methods&text=Several%20methods%20for%20reducing%20this,ports%2C%20protocols%2C%20and%20applications. И вообще, вы можете поискать информацию о защите публичных веб-сервисов.
Что касается того, следует ли вам внедрять какую-либо форму защиты и что именно вы будете внедрять, то это полностью зависит от ситуации. Я бы обратил внимание на то, будет ли ваш сервис специально атакован, в этом случае стоит рассмотреть ограничение скорости и т. д. Может быть, просто несколько ботов будут делать запросы случайно, когда найдут сервис, может быть, несколько запросов, это не имеет значения.
Затем важно рассмотреть последствия любого события, какой сервис вы запускаете, какое влияние и на кого, личный ли это сервис, который вы можете перезапустить, как хобби, стартап, компания с большим количеством пользователей и, в конечном счете, контрактным временем работы... и т.д. Также хостинг, если он размещается самостоятельно на фиксированных ресурсах, то вам может потребоваться перезапуск. Размещен ли он на каком-то сервисе, фиксирована ли цена, могут ли у вас быть неожиданные счета на огромные суммы, потому что ваш сервис так часто вызывают.
Если последствия спама/атаки на сервис важны, то следует принять больше мер предосторожности. Что касается ограничения скорости, оставляющей сервис доступным, то да, но вам нужен доступ к сервису, вы ограничиваете возможность злоупотребления. Другой вариант - капча, если вы хотите, чтобы запросы чаще поступали от простых пользователей.