подстановочный знак * маршрут, отвечающий на все запросы - PullRequest
0 голосов
/ 11 ноября 2018

У меня есть работающее приложение Node.js, созданное с помощью инфраструктуры Express.js. Все маршруты в приложении являются почтовыми маршрутами, т.е.

app.post('/login', function(req, res){
//do login validation
});

app.post('/AppHomepage', function(req, res){
//send user app dashboard
});
etc.

У меня возникла проблема, если пользователь ввел неопределенный маршрут, например. appdomain.com/thisroutedoesnotexist, им будет возвращено сообщение «Cannot GET / thisroutedoesnotexist»

Поэтому я последовал совету в этом ответе: https://stackoverflow.com/a/25216843 и добавил

app.get('*', function(req, res) {
res.redirect('/');
});

как самый последний маршрут. Это прекрасно работает для перенаправления неопределенных запросов на страницу индекса и решает проблему.

Однако я обнаружил, что это перенаправление подстановки также вызывается при выполнении запросов LEGITIMATE. то есть. если пользователь запрашивает / AppHomepage, оба

app.post('/AppHomepage', function(req, res){
//send user app dashboard
});

И

app.get('*', function(req, res) {
res.redirect('/');
});

ловит и отвечает на запрос. Пользователь действительно получает правильный res.render домашней страницы, однако console.log внутри индексного маршрута также печатает, что означает, что маршрутный символ, перехватывающий запрос / AppHomepage даже после того, как маршрут app.post ('/ AppHomepage') имеет взял и обслужил запрос.

Может кто-нибудь понять, почему это происходит?

EDIT:

Теперь я знаю, что даже запросы POST от браузера будут GET, и именно поэтому подстановочный знак GET обнаруживает перенаправления.

У меня сейчас вопрос, есть ли способ перенаправить только неопределенные запросы вместо всех запросов GET?

Ответы [ 2 ]

0 голосов
/ 11 ноября 2018

[РЕШИТЬ]

Итак, некоторые браузеры обнаружили, что проблема заключается в мошеннических вторичных запросах favicon. Первоначально определенные запросы действительно обрабатывались соответствующим обработчиком маршрута, однако некоторые браузеры, такие как Google Chrome, имеют тенденцию отправлять вторичные запросы избранного, отдельно от инициированного пользователем запроса и сообщая ему об этом.

Это был запрос, который не был определен и получен последним подстановочным маршрутизатором. Браузеры, которые не демонстрируют такого мошеннического поведения, включают Apple Safari на macOS и объясняют, почему эта проблема не воспроизводится на 100%.

Решение состоит в том, чтобы создать пустой маршрутизатор favicon для обработки таких запросов, если запрос выполняется из браузера, который демонстрирует такое поведение, не инициированное пользователем, как Google Chrome.

0 голосов
/ 11 ноября 2018

Если вы тестируете в браузере, то все запросы по умолчанию будут «GET» и, как вы сказали, все ваши запросы «POST», попробуйте почтальон или другой аналогичный инструмент для тестирования API

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...