Извините опять те же старые вещи. . . Пожалуйста, принесите резюме, чтобы убить меня. . . Ants Gold Service - Credit Seaname Recuctions Friends Front End P6 / 7,Опубликовать ссылку JD, количество мест ограничено, приходите быстрее. . .
Я написал несколько постов об основных принципах и распространенных заблуждениях, связанных с междоменными решениями, после проектов по разделению внешнего и внутреннего интерфейса, в основном включая обратный прокси-сервер CORS и Nginx. Обе эти схемы используются, и у каждой есть свои преимущества и недостатки.Что касается того, какую схему использовать, мнения у всех не совсем одинаковы.Эта статья в основном расширяет это, от фронтенда, бэкенда и сервера конфигурация, безопасность и гибкость миграции, масштабируемость и т. д., подробно сравните преимущества и недостатки двух схем, чтобы помочь вам в выборе схемы на более позднем этапе.
1. Конфигурация внешнего интерфейса
CORS-решение: при междоменном использовании некоторые браузеры по умолчанию не передают файлы cookie, поэтому для переноса файлов cookie необходимо установить атрибут withCrendetails запроса xmlhttprequest.При использовании vue-resouce настройки следующие.
Vue.http.options.credentials = true
При использовании axios в перехватчике можно установить следующее
axios.interceptors.request.use((config) => {
config.withCredentials = true
return config
}, (error) => {
return Promise.reject(error)
})
При использовании собственного объекта XMLHttpRequest следующим образом:
var xhr = new XMLHttpRequest();
xhr.withCredentials = true;
Если вам не нужно передавать файлы cookie, лучше установить для него значение false, чтобы избежать ситуации, когда файлы cookie по умолчанию разрешены для переноса в разных браузерах.
Обратный прокси Nginx: в настоящее время внешний интерфейс эквивалентен не междоменному, что согласуется с обычными запросами, и дополнительная настройка не требуется.
Во-вторых, внутренняя конфигурация
CORS-решение: Для простого запроса вам нужно упаковать заголовок серии ACA,
'Access-Control-Allow-Origin' '*';
'Access-Control-Allow-Credentials' "true";
'Access-Control-Allow-Headers' 'X-Requested-With';
Для сложных междоменных запросов также требуется одноэтапный процесс предварительной проверки.
Обратный прокси Nginx: в настоящее время серверная часть не является междоменной, соответствует обычным запросам, и дополнительная настройка не требуется.
3. Конфигурация сервера
CORS-решение: без.Обратный прокси Nginx: Программа работы сосредоточилась на перекрестном домене Nginx Server, настроен следующим образом
...
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Real-Port $remote_port;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
...
location /api {
proxy_pass https://b.test.com; # 设置代理服务器的协议和地址
proxy_cookie_domain b.test.com a.test.com; # 修改cookie，针对request和response互相写入cookie
}
...
Принцип можно увидеть в предыдущих двух статьях
4. Безопасность
CORS-решение: Поскольку в это время браузер добавит атрибут origin по умолчанию, сервер может напрямую найти источник запроса, что удобно для контроля источника и блокировки ссылки из черного списка. В то же время доменное имя и порт сервера будут раскрыты.Обратный прокси Nginx: нет заголовка источника по умолчанию, который можно использовать в решении обратного прокси-сервера, но IP-адрес клиента и прокси-сервера на всех уровнях можно просмотреть через заголовок X-Forward-For, а также может быть определена определенная степень обратного отслеживания и экранирования черного списка. достигнуто. В обратном прокси-сервере адрес интрасети может использоваться для доступа к интерфейсному серверу, что может в определенной степени защитить интерфейсный сервер от раскрытия.
5. Гибкость и масштабируемость трансплантации
CORS-решение: Вам нужно только настроить черный и белый список в центре кода или конфигурации, что удобно для портирования и расширения.Обратный прокси Nginx: доменное имя службы разных окружений может не совпадать, поэтому конфигурация nginx тоже отличается, что не удобно для портирования. Для масштабируемости, когда есть новый проект, которому требуется доступ к интерфейсному серверу, необходимо сначала получить доступ к доменному имени, указанному сервером в nginx, а затем обратно проксировать доменное имя сервера на интерфейсный сервер, например
server {
listen 8443;
server_name a.test.com;
client_max_body_size 100m;
ssl ...
location /micro{
proxy_pass https://b.test.com; #反向代理
proxy_cookie_domain b.test.com a.test.com; #修改cookie
add_header 'Access-Control-Allow-Origin' 'htps://c.test.com';
add_header 'Access-Control-Allow-Credentials' "true";
add_header Access-Control-Allow-Headers X-Requested-With;
}
}
В настоящее время междоменная модель изменилась с простого обратного прокси-сервера с a.test.com на b.test.com на обратный прокси-сервер с a.test.com на b.test.com и c.test. .comCORS Обратный прокси-сервер на a.test.com, а затем на b.test.comd. Это немного сбивает с толку, но вы поймете, если хорошенько об этом подумаете. Это, несомненно, увеличивает стоимость обслуживания в более поздний период.
Всестороннее сравнение
Исходя из вышеизложенного, мы можем получить примерно следующее
| Item | CORS | Обратный прокси Nginx |
|---|---|---|
| Конфигурация кода -- внешний интерфейс | credentials=true | без |
| Конфигурация кода -- фон | setHeader: ACA-Origin, ACA-Method, ACA-Credentials и т. д. | без |
| конфигурация сервера | без | Конфигурация Nginx |
| Гибкость миграции | Высокая, дополнительная настройка не требуется | Низкий, каждая конфигурация среды может отличаться |
| безопасность | Управляемая источником, прямая прослеживаемость | X-Forwarded-For трассирует многоуровневые источники |
| новое расширение проекта | Управление черным и белым списком | Обновите конфигурацию, междоменная модель изменится |
Контрастный вывод
Подводя итог, для общедоступных базовых служб, поскольку в стыковке может участвовать больше интерфейсных проектов, а также больше сред разработки, тестирования и развертывания, в целом я более склонен рекомендовать вам использовать решение CORS. Для некоторых небольших проектов с сильной оппозицией использование nginx может снизить затраты на разработку, а также ускорить разработку и запуск. Разумеется, конкретное использование следует совмещать с реальной работой и использовать по мере необходимости. Кроме того, при использовании обратного прокси-сервера Nginx рекомендуется использовать внутреннее доменное имя/ip в качестве входа на интерфейсный сервер и стараться не выставлять его наружу, чтобы избежать ненужных проблем с безопасностью.
EMMM, мы все еще рекрутируем людей недавно, Ant Financial - Seaname Credit - набор в конечном итоге P6 / 7! Редкая возможность! Ну давай же! ты сможешь! , Дачанг, как вы знаете, бонус будет разделен на половину вас. Если вы заинтересованы, приходите и попробуйте. Если вы заинтересованы в WeChat Chat, добавьте меня Heiohiio. Вы также можете бросить свое резюме прямо к моему почтовому ящику ~ Heioray @ sina.com.
~Конец этой статьи~Добро пожаловать для совместного обсуждения~