当前位置:Gxlcms > JavaScript > nodejs中http代理库http-proxy中常见的问题分析

nodejs中http代理库http-proxy中常见的问题分析

时间:2021-07-01 10:21:17 帮助过:12人阅读

本篇文章给大家带来的内容是关于nodejs中http代理库http-proxy中常见的问题分析,有一定的参考价值,有需要的朋友可以参考一下,希望对你有所帮助。

http-proxy

http-proxy是一个nodejs的http代理库,已经被webpack-dev-server集成进来,做代理使用。原因是在前后端分离大行其道的今天,我们如果需要在本地调后端api接口,不配置hostname的话,必然是一个跨域的请求。因为浏览器的跨域安全限制,调取是不通的,所以本地代理就成了一个本地开发环境的必选项。

'/saasapi/*': {
    target: 'http://ebk.17u.cn',
},

意思呢大概就是把saasapi开头的ajax请求重定向到http://ebk.17u.cn

本地开发没有问题,线上如果也是用nodejs的服务器,如果恰巧也配置了代理,部署到线上出现了意想不到的问题~

后端nginx配置了反向代理

一个网站主域名是17u.cn,后端如果部署了多个api服务,那这样子他的api服务可能是这样子

主域名二级域名1二级域名2二级域名3
17u.cnebk.17u.cnebk2.17u.cnebk3.17u.cn

前端同样部署了3个nodejs服务,也同样配置了3个代理。部署到线上却发现,请求总是指向第一个二级域名,其他的二级域名访问不到。

百思不得姐!

后来仔细查看http的信息,发现几个服务的ajax请求发到服务器上之后,hostname都是浏览器的域名,而nginx的反向代理配置都是根据hostname来做转发的。因为我们的hostname对于nginx来说都是陌生的,所以就默认转发到默认的第一个服务上去了。

查了http-proxy配置,哈哈,果然有这种修改的配置,只要稍微改一下就好了。

'/saasapi/*': {
    target: 'http://ebk.17u.cn',
    changeOrigin: true
},

changeOrigin: true意思就是把hostname改为和target一致就可以了。这样后端nginx就可以正常转发了。

后端配置了cookie Path

后端api,不仅仅配置了二级域名,还配置了二级目录,前端部署的服务也一样需要二级目录。

api地址就变成这个样子:

ebk.17u.cn/saasapi

前端地址:

trans.17u.cn/saas

代理配置做对应调整

'/saas/saasapi/*': {
    target: 'http://ebk.17u.cn',
    changeOrigin: true,
    rewrite: path => path.replace(/^\/saas\/saasapi\/cxy/, '/saasapi')
},

这样子看起来很正常吧,但是问题出在哪呢?后端把登录之后设置的cookie也设置了path:Path='/saasapi'

这样子问题就来了,trans.17u.cn/saas当前域名下读取不到/saasapi下面的cookie,导致前端登录每次都通过,但就是不能正常调api,每次调取都提示没有登录。

有问题还是先查文档。

还是发现了解决方案

cookiePathRewrite: { '/saasapi': '/saas/saasapi' }

重写cookie路径就好了,同理如果后端接口指定了cookie的domain,一样有方案解决

cookieDomainRewrite

还有一些其他rewrite,应该都比较好用的。

ps:在解决过程中,发现改了也总是不能成功,一度怀疑是库的bug。后来发现需要清除掉chrome的cookie。

直接点Application -> Cookie:删除下面的cookie是不行的。清理不掉全部的cookie,需要到Application -> clear storage中,clear site data才可以。最终成功

相关推荐:

Js中前端模块化的详细分析及其区别对比

jQuery中的方法有哪些?jQuery中常用的方法(附代码)

jQuery对象与原生DOM对象之间的区别及转换

以上就是nodejs中http代理库http-proxy中常见的问题分析的详细内容,更多请关注Gxl网其它相关文章!

人气教程排行