前后端分离实践跨域问题

随着前端越来越火,越来越多的人推崇前后端分离,后端只提供API,前端只负责消费API。这样我们就能更加专注自己的事情了,比如前端可以使用任何想要的工具(Webpack、Gulp等等),后端也不用因为集成前端的代码而苦逼加班了。这里不讨论前后端分离的必要性,更多可参考

这里主要分享前后端分离后,如何解决跨域问题

服务端

Rails

作为一个Rails程序员,首先分享一下在Rails里面的解决方案, 大家可以使用一个rack-cors 中间件,并作以下配置:

#config/application.rb
    config.middleware.insert_before 0, "Rack::Cors", :debug => true, :logger => (-> { Rails.logger }) do
      allow do
        origins ['http://localhost:3000']
        resource '*',
          :headers => :any,
          :methods => [:get, :post, :delete, :put, :options, :head],
          :max_age => 0
      end
    end
更多配置请参考 rack-cors

Node

当然,如果后端是NodeJs,我们也可以找到同样的中间件 cors 请看以下配置

var express = require('express')
  , cors = require('cors')
  , app = express();

// 同样的,只支持开发环境跨域
if(process.env.NODE_ENV == 'development'){
    app.use(cors());
}
Nginx

这时候,后端程序员可能会说,为了保持跟生产环境配置一直,请直接用 Nginx 来配置吧,这样能减少差异。啪啦啪啦...
直接看配置吧

server {
    listen       80;
    # 配置可访问域名,注意需要添加相应host配置
    server_name xxx.dev;
    #charset koi8-r;
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   html;
    }

    location /istore/v1 {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Real-IP $remote_addr;
        # API Server
        proxy_pass http://localhost:4000;
        proxy_next_upstream error;
    }
    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Real-IP $remote_addr;
        # Frontend Server
        proxy_pass http://localhost:3000;
        proxy_next_upstream error;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}
http-proxy-middleware

这时候前端也不服了,说,我们自己能搞定
PS: 其实这里用了Nginx配置之后,webpack的hot reload会存在比较大的延迟,具体原因还没研究

# 安装插件
cnpm install --save-dev http-proxy-middleware

# 添加配置
import proxy from 'http-proxy-middleware';

const apiProxy = proxy('/api/v1', {
    target: 'http://localhost:4000',
    changeOrigin: true,
    ws: true
});
browserSync({
  server: {
    baseDir: 'src',

    middleware: [
      apiProxy,
      ...
    ]
  }
})

时间: 2024-10-12 22:18:10

前后端分离实践跨域问题的相关文章

前后端分离架构下CSRF防御机制

背景 1.什么是CSRF攻击? 这里不再介绍CSRF,已经了解CSRF原理的同学可以直接跳到:"3.前后端分离下有何不同?". 不太了解的同学可以看这两篇对CSRF介绍比较详细的参考文章: CSRF 攻击的应对之道 浅谈CSRF攻击方式 如果来不及了解CSRF的原理,可以这么理解:有一个人发给你一个搞(mei)笑(nv)图片链接,你打开这个链接之后,便立刻收到了短信:你的银行里的钱已经转移到这个人的帐户了. 2.有哪些防御方案? 上面这个例子当然有点危言耸听,当然可以确定的是确实会有这

Gracejs : 全新的基于koa2的前后端分离框架

Gracejs(又称:koa-grace v2) 是全新的基于koa v2.x的MVC+RESTful架构的前后端分离框架. 一.简介 Gracejs是koa-grace的升级版,也可以叫koa-grace v2. github地址: https://github.com/xiongwilee/koa-grace. 主要特性包括: 支持MVC架构,可以更便捷地生成服务端路由; 标准的RESTful架构,支持后端接口异步并发,页面性能更优; 一套Node环境经服务服务多个站点应用,部署更简单; 优

基于NodeJS的前后端分离的思考与实践(二)模版探索_node.js

前言 在做前后端分离时,第一个关注到的问题就是 渲染,也就是 View 这个层面的工作. 在传统的开发模式中,浏览器端与服务器端是由不同的前后端两个团队开发,但是模版却又在这两者中间的模糊地带.因此模版上面总不可避免的越来越多复杂逻辑,最终难以维护. 而我们选择了NodeJS,作为一个前后端的中间层.试图藉由NodeJS,来疏理 View 层面的工作. 使得前后端分工更明确,让专案更好维护,达成更好的用户体验. 本文 渲染这块工作,对于前端开发者的日常工作来说,佔了非常大的比例,也是最容易与后端

基于NodeJS的前后端分离的思考与实践(六)Nginx + Node.js + Java 的软件栈部署实践_node.js

淘宝网线上应用的传统软件栈结构为 Nginx + Velocity + Java,即: 在这个体系中,Nginx 将请求转发给 Java 应用,后者处理完事务,再将数据用 Velocity 模板渲染成最终的页面. 引入 Node.js 之后,我们势必要面临以下几个问题: 技术栈的拓扑结构该如何设计,部署方式该如何选择,才算是科学合理?项目完成后,该如何切分流量,对运维来说才算是方便快捷?遇到线上的问题,如何最快地解除险情,避免更大的损失?如何确保应用的健康情况,在负载均衡调度的层面加以管理?承系

基于NodeJS的前后端分离的思考与实践(四)安全问题解决方案_node.js

前言 在前后端分离的开发模式中,从开发的角色和职能上来讲,一个最明显的变化就是:以往传统中,只负责浏览器环境中开发的前端同学,需要涉猎到服务端层面,编写服务端代码.而摆在面前的一个基础性问题就是如何保障Web安全? 本文就在前后端分离模式的架构下,针对前端在Web开发中,所遇到的安全问题以及应对措施和注意事项,并提出解决方案. 跨站脚本攻击(XSS)的防御 问题及解决思路 跨站脚本攻击(XSS,Cross-site scripting)是最常见和基本的攻击Web网站的方法.攻击者可以在网页上发布

基于NodeJS的前后端分离的思考与实践(一)全栈式开发_node.js

前言 为了解决传统Web开发模式带来的各种问题,我们进行了许多尝试,但由于前/后端的物理鸿沟,尝试的方案都大同小异.痛定思痛,今天我们重新思考了"前后端"的定义,引入前端同学都熟悉的NodeJS,试图探索一条全新的前后端分离模式. 随着不同终端(Pad/Mobile/PC)的兴起,对开发人员的要求越来越高,纯浏览器端的响应式已经不能满足用户体验的高要求,我们往往需要针对不同的终端开发定制的版本.为了提升开发效率,前后端分离的需求越来越被重视,后端负责业务/数据接口,前端负责展现/交互逻

基于NodeJS的前后端分离的思考与实践(三)轻量级的接口配置建模框架_node.js

前言 使用Node做前后端分离的开发模式带来了一些性能及开发流程上的优势, 但同时也面临不少挑战.在淘宝复杂的业务及技术架构下,后端必须依赖Java搭建基础架构,同时提供相关业务接口供前端使用.Node在整个环境中最重要的工作之一就是代理这些业务接口,以方便前端(Node端和浏览器端)整合数据做页面渲染.如何做好代理工作,使得前后端开发分离之后,仍然可以在流程上无缝衔接,是我们需要考虑的问题.本文将就该问题做相关探讨,并提出解决方案. 由于后端提供的接口方式可能多种多样,同时开发人员在编写Nod

基于阿里的Node全栈之路(五)前后端分离进阶-接口篇

上一篇文章我就简单的贴了下代码,放出来不到一天就破千了,这让我非常的意外,也很开心;) 我会好好的把上一篇的代码注释补一下的.然后决定再放一些我的代码和理解,俗话说: Talk is cheap, show me the code! 还记得我的架构中,只有前端静态代码,同时所有的请求是经过跨域发到api上的,那么这次,我们就来好好的分析下request接口的实现和我自己尝试的一种的开发流程--api文档(新接口文档) 先贴上我之前的前后端分离的方式,再简单的介绍下,看过前面文章的同学直接跳过哈!

前后端分离之SpringBoot项目Token认证

写在开始 有人说,爱上一座城,是因为城中住着某个喜欢的人.其实不然,爱上一座城,也许是为城里的一道生动风景,为一段青梅往事,为一座熟悉老宅.或许,仅仅为的只是这座城.就像爱上一个人,有时候不需要任何理由,没有前因,无关风月,只是爱了. -林徽因 前段时间,大体了解了一下前后端分离之Vue项目构建测试打包发布,并简单的记录了一下. 其实,如果单纯的前后端分离项目,大可不必使用Token,原始的session就可以解决问题,当然前提是要在一个域(域名.IP.端口必须保持一致)下,前后端开发人员可使用