Я использую серверную часть Laravel для обработки запросов как с веб-сайта, так и с приложения React Native.
Для локальных разработчиков я тестирую веб-сайт через тот же компьютер, на котором запущен сервер разработки. on, поэтому все запросы виртуального хоста по существу go через localhost. Для приложения React Native (далее RN) я использую Expo, и приложение работает на физическом устройстве в той же сети, что и сервер разработки, отправляя запросы на URL-адрес, который выглядит следующим образом:
http://192.168.x.xxx/project-name/public
Для локального разработчика все работает нормально и для веб-сайта, и для приложения RN.
Я также поставил тестовый сервер на экземпляр AWS EC2, к которому я могу получить доступ с любого компьютера ( т.е. тестовый сервер открыт для любого IP-адреса в мире) через IP-адрес машины следующим образом:
http://x.xx.xxx.xx
Все в тестовой среде загружается нормально, когда я обращаюсь к веб-сайту на тестовом сервере .
Затем я попытался указать канал выпуска Expo для тестирования на тестовый env, чтобы я мог поместить приложение в TestFlight и протестировать его. Однако, сделав это, я заметил, что ни один из запросов API не прошел.
Чтобы отладить проблему, я решил затем направить мою локальную среду разработки на тестовый сервер, чтобы посмотреть, что происходит. После этого я понял, что все запросы Ax ios от приложения RN возвращали следующую ошибку из блока catch
:
Request failed with status code 401
Это происходит даже для маршрутов API, которые я добавил в Laravel VerifyCsrfToken
список исключений, для которых не требуется токен CSRF.
В качестве примера я установил маршрут GET, который ведет к следующему:
/temp/api-test
Маршрут просто возвращает следующее:
return [
'a' => 123,
'b' => 456
];
Если я выберу этот маршрут из тестового env прямо из браузера или сделаю вызов Ax ios с веб-сайта в тестовом env, то он вернется правильно данные (даже если я не вошел в систему или не отправляю токен CSRF).
Однако, когда я делаю вызов Ax ios той же временной конечной точки из приложения RN, я продолжаю получать 401 . Маршрут также находится в файле маршрутов web.php
, а не в файле api.php
, поэтому я не думаю, что какое-либо промежуточное программное обеспечение мешает (хотя я могу ошибаться в этом).
Я видел Laravel статей, в которых говорится, что мне нужно отправить API токен через запрос, но верно ли это даже для маршрутов, которые находятся в файле веб-маршрутов и для которых не требуется токен CSRF? Кроме того, если это так, почему запросы в моем локальном dev env к компьютеру в той же сети go проходят, но блокируются Laravel при отправке запросов на тестовый URL-адрес env? Любая помощь / совет будут очень благодарны. Спасибо.
Edit # 1 : в качестве дополнительного комментария я попытался задействовать конечную точку тестового API, созданную в Postman, и она отлично работает для URL-адреса локальной сети, но когда я ввожу URL-адрес тестового сервера AWS, я получаю следующий ответ:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
<title>401 Unauthorized</title>
</head>
<body>
<h1>Unauthorized</h1>
<p>This server could not verify that you
are authorized to access the document
requested. Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
</body>
</html>
Если бы это был защищенный маршрут, я мог бы это понять, но зачем мне это получать для маршрута GET в web.php
, для которого не требуется токен CSRF и который должен быть доступен для незарегистрированных пользователей? И, кроме того, почему это нормально работает для веб-сайта и вызовов Ax ios с веб-сайта, а не из приложения RN? Спасибо.
Edit # 2 : Я нашел решение как таковое, но я не совсем уверен, как оно работает.
В основном , есть заголовок Authorization: Basic *token*
, который отправляется со всеми запросами на тестовый сервер, который не отправляется ни с какими запросами на сервер разработки.
Как только я взял токен, который я мог просмотреть из Вкладка Network в моем браузере и добавил заголовок Authorization
к запросам приложения RN, он начал работать.
Я не уверен, что это действительно решение, так как я до сих пор не понимаю, почему Заголовок Authorization
устанавливается только на тестовом сервере, а не на сервере разработки, или откуда вообще берется (на первый взгляд случайный) токен.
Если у кого-нибудь есть опыт в этом, и он может объяснить, откуда берется токен и как он генерируется, мы будем очень признательны. Спасибо.