一个比较扯淡的跨域问题
2018-11-06更新:
如果在chrome浏览器中过期时间 expiration date显示的是1969。
答案
说明cookie是临时的,只保持在这个会话周期,当浏览器关闭时cookie会被清除。
Unix time was started at the beginning of 1970, that means that -1 is in 1969. And that is a commonly used value for "unknown" if the expected value is usually positive. And for cookies MaxAge with a negative value means that the cookie is not stored persistently and will be deleted when the Web browser exits.
2018-08-27更新:
使用cookie前强烈建议先看下MDN的这篇基础文章
创建cookie可以配置的选项 Expires,Secure,HttpOnly,Domain,Path,SameSite。
为避免跨域脚本 (XSS) 攻击,通过JavaScript的 Document.cookie API无法访问带有 HttpOnly 标记的Cookie,它们只应该发送给服务端。
最近在开发一个前后台分离的项目。
前台是 localhost:8080,基于vue,请求用的axios库,后台是地址 localhost:8111,使用的是NodeJS。
也就是前台发起的请求是跨域的。
现在流程是这样的: 前台向后台请求接口,后台会看到set-cookie,可是我发现前端JS 怎么也拿不到 cookie(后来发现是cookie被设置了HttpOnly)。axios的response里没有。但是在chrome里可以看到设置的cookie。
查了文档,当需要跨域请求,前台需要设置 withCredentials 为 true。 这样每次请求会自动带上 cookie,但是后台也需要设置 Access-Control-Allow-Credentials: true, 就不能用*来设置Origin了,即 Access-Control-Allow-Origin:*
, 而应该相应的改成Access-Control-Allow-Origin: localhost:8080
,
这样就比较尴尬了,到时候前台是对大众开放,需要允许所有来源,难道没有别的办法了?相信标准这么做也是为了安全。
查了也有解决办法。都还没有尝试。
比如
- 可以在nginx中设置,对于过来的请求,让 nginx 自动加上请求头。下面的方法没试,不是嫌麻烦,是部署的工作不是自己的人来做。
if ($http_origin ~* ( https?://.*\.example\.com(:[0-9]+)?$)) { add_header Access-Control-Allow-Origin: $http_origin; }
- 对于后端,比如express。每个请求都走一遍中间件, 取出 headers 里的域名, 写到 CORS 头部去:
app = express() app.all('/*', (req, res, next) => { if (req.headers.origin) { res.header("Access-Control-Allow-Origin", req.headers.origin) res.header("Access-Control-Allow-Credentials", true) res.header('Access-Control-Allow-Methods', 'PUT, GET, POST, DELETE, OPTIONS') # 下面一行意义不明确... res.header("Access-Control-Allow-Headers", "X-Requested-With, AUTHORIZATION") } next(); // pass control to the next handler }); next()
其实使用cookie做前后端分离真的没有 token 或 jwt 好用。机密的信息不要放到cookie中比较好。
====
更新
使用下面的方法在本地可行
if (process.env.NODE_ENV == 'local') { app.use(function(req, res, next) { res.header("Access-Control-Allow-Credentials", true); res.header("Access-Control-Allow-Origin", req.headers.origin); res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept"); next(); }); }else { app.use(cors()); }
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
中间件万里行?不远万里来相会?| 阿里中间件Aliware 开启全国赋能之旅
转不转型,这已经不是一个问题。问题是以什么样的姿势去转型。 自8月初,阿里中间件Aliware面向全国伙伴举办了“阿里中间件Aliware分销合作伙伴招募大会” - 链接 和 “阿里中间件Aliware基础业务销售培训回顾” - 链接 的线上直播活动后,收到来自全国合作伙伴以及各大战区电销同学们的积极反馈,企业数字化转型的强烈需求正催生着大量企业有兴趣、有决心、有规划的去拥抱企业级互联网架构。 8月14日,阿里中间件Aliware从线上直播走进线下,开启了全国范围的赋能之旅,首发上海站和北京站。 据阿里中间件生态合作专家紫泷介绍,由经验丰富的七袋、诗洋、邹昂、山猎等架构师专家团队进行全方位、多维度的培训,此次全国赋能之旅将从上海开始,逐步覆盖华东一、华北、华南、中西、西南、中小、华东二等7大战区,同步全国大连、成都、西安三大城市近千名电
- 下一篇
sqlserver 存储过程中使用临时表到底会不会导致重编译
原文: sqlserver 存储过程中使用临时表到底会不会导致重编译 曾经在网络上看到过一种说法,SqlServer的存储过程中使用临时表,会导致重编译,以至于执行计划无法重用,运行时候会导致重编译的这么一个说法,自己私底下去做测试的时候,根据profile的跟踪结果,存储过程中使用临时表,如果不是统计信息变更导致导致的重编译,并不会导致重编译,但是现实情况下,对于一些特殊的情况,即便是统计信息没有更新,又确实会出现每次运行都重编译的情况,存储过程中使用了临时表,什么情况下会重编译,什么情况下不用重编译?为了弄清楚这个问题,查阅了大量的资料,才把这个问题弄清楚,这里特意记录下来,希望武断地认为存储过程中使用了临时表就会导致重编译的这个观点得到纠正。 首先进行下面的测试,我们知道,导致临时表重编译的因素之一就是统计信息的变化,统计信息的变化依赖于往临时表中写入的数据量,首选我要控制插入临时表中的数据量不超过统计信息更新而导致重编译的阀值,先排除统计信息的变更导致重编译,看看仅仅是多次运行SP,是否因为存储过程中有了临时表而会产生重编译 --首选创建一个表,供存储过程中测试使用 crea...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS6,CentOS7官方镜像安装Oracle11G
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8编译安装MySQL8.0.19
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7,8上快速安装Gitea,搭建Git服务器