标签 Go 下的文章

Go语言gRPC服务Handler单元测试详解

本文永久链接 – https://tonybai.com/2023/11/25/grpc-handler-unit-testing-in-go

在云原生时代和微服务架构背景下,HTTP和RPC协议成为服务间通信和与客户端交互的两种主要方式。对于Go语言而言,标准库提供了net/http/httptest包,为开发人员提供了便捷的方式来构建服务端HTTP Handler单元测试的测试脚手架代码,而无需真正建立HTTP服务器,让开发人员可以聚焦于对Handler业务逻辑的测试。比如下面这个示例:

// grpc-test-examples/httptest/http_handler_test.go

func myHandler(w http.ResponseWriter, r *http.Request) {
    // 设置响应头
    w.Header().Set("Content-Type", "text/plain")

    // 根据请求方法进行不同的处理
    switch r.Method {
    case http.MethodGet:
        // 处理GET请求
        fmt.Fprint(w, "Hello, World!")
    ... ...
    }
}

func TestMyHandler(t *testing.T) {
    // 创建一个ResponseRecorder来记录Handler的响应
    rr := httptest.NewRecorder()

    // 创建一个模拟的HTTP请求,可以指定请求的方法、路径、正文等
    req, err := http.NewRequest("GET", "/path", nil)
    if err != nil {
        t.Fatal(err)
    }

    // 调用被测试的Handler函数,传入ResponseRecorder和Request对象
    // 这里假设被测试的Handler函数为myHandler
    myHandler(rr, req)

    // 检查响应状态码和内容
    if rr.Code != http.StatusOK {
        t.Errorf("Expected status 200; got %d", rr.Code)
    }
    expected := "Hello, World!"
    if rr.Body.String() != expected {
        t.Errorf("Expected body to be %q; got %q", expected, rr.Body.String())
    }
}

注:对http client端的单元测试,也可以利用httptest的NewServer来构建一个fake的http server

然而,对于使用主流的gRPC等RPC协议的服务端Handler来说,是否存在类似httptest的测试脚手架生成工具包呢?对gRPC的服务端Handler有哪些单元测试的方法呢?在这篇文章中,我们就一起来探究一下。

1. 建立被测的gRPC服务端Handler

我们首先来建立一个涵盖多种gRPC通信模式的服务端Handler集合。

gRPC支持四种通信模式,它们分别为:

  • 简单RPC(Simple RPC,也称为Unary RPC)

这是最简单的,也是最常用的gRPC通信模式,简单来说就是一请求一应答

  • 服务端流RPC(Server-streaming RPC)

客户端发来一个请求,服务端通过流返回多个应答。

  • 客户端流RPC(Client-streaming RPC)

客户端通过流发来多个请求,服务端以一个应答回复。

  • 双向流RPC(Bidirectional-Streaming RPC)

客户端通过流发起多个请求,服务端也通过流对应返回多个应答。

注:关于gRPC四种通信方式的详情,可以参考我之前写的《gRPC客户端的那些事儿》一文。

我们这个SUT(被测目标)是包含以上四种通信模式的gRPC服务,它的Protocol Buffers文件如下:

// grpc-test-examples/grpctest/IDL/proto/mygrpc.proto

syntax = "proto3";

package mygrpc;

service MyService {
  // Unary RPC
  rpc UnaryRPC(RequestMessage) returns (ResponseMessage) {}

  // Server-Streaming RPC
  rpc ServerStreamingRPC(RequestMessage) returns (stream ResponseMessage) {}

  // Client-Streaming RPC
  rpc ClientStreamingRPC(stream RequestMessage) returns (ResponseMessage) {}

  // Bidirectional-Streaming RPC
  rpc BidirectionalStreamingRPC(stream RequestMessage) returns (stream ResponseMessage) {}
}

message RequestMessage {
  string message = 1;
}

message ResponseMessage {
  string message = 1;
}

通过protoc,我们可基于上述proto文件生成MyService桩(Stub)代码,生成的代码放在了mygrpc目录下面:

// grpc-test-examples/grpctest/Makefile

all: gen

gen:
    protoc -I ./IDL/proto mygrpc.proto --gofast_out=plugins=grpc:./mygrpc

注:你的环境下需要安装protocprotoc-gen-go才能正确执行上面生成命令,具体的安装方法可参考protoc安装文档

注:除了使用经典的protoc基于proto文件生成Go源码外,也可以基于Go开发的buf cli进行代码生成和API管理。buf cLi是现代、快速、高效的Protobuf API管理的终极工具,为基于Protobuf的开发和维护提供了全面的解决方案。等有机会的时候,我在以后的文章中详细说说buf。

有了生成的桩代码后,我们便可以建立一个gRPC服务器:

// grpc-test-examples/grpctest/main.go

package main

import (
    pb "demo/mygrpc"
    "log"
    "net"

    "google.golang.org/grpc"
)

func main() {
    // 创建 gRPC 服务器
    lis, err := net.Listen("tcp", ":50051")
    if err != nil {
        log.Fatalf("failed to listen: %v", err)
    }
    s := grpc.NewServer()

    // 注册 MyService 服务
    pb.RegisterMyServiceServer(s, &server{})

    // 启动 gRPC 服务器
    log.Println("Starting gRPC server...")
    if err := s.Serve(lis); err != nil {
        log.Fatalf("failed to serve: %v", err)
    }
}

我们看到:在main函数中,我们创建了一个TCP监听器,并使用grpc.NewServer()创建了一个gRPC服务器。然后,我们通过调用pb.RegisterMyServiceServer()将server类型的实例注册到gRPC服务器上,以处理来自客户端的请求。最后,我们启动gRPC服务器并监听指定的端口。

上面代码中注册到服务器中的server类型就是实现了MyService服务接口的具体类型,它实现了MyService定义的所有方法:

// grpc-test-examples/grpctest/server.go

package main

import (
    "context"
    "fmt"
    "strconv"

    pb "demo/mygrpc"
)

type server struct{}

func (s *server) UnaryRPC(ctx context.Context, req *pb.RequestMessage) (*pb.ResponseMessage, error) {
    message := "Unary RPC received: " + req.Message
    fmt.Println(message)

    return &pb.ResponseMessage{
        Message: "Unary RPC response",
    }, nil
}

func (s *server) ServerStreamingRPC(req *pb.RequestMessage, stream pb.MyService_ServerStreamingRPCServer) error {
    message := "Server Streaming RPC received: " + req.Message
    fmt.Println(message)

    for i := 0; i < 5; i++ {
        response := &pb.ResponseMessage{
            Message: "Server Streaming RPC response " + strconv.Itoa(i+1),
        }
        if err := stream.Send(response); err != nil {
            return err
        }
    }

    return nil
}

func (s *server) ClientStreamingRPC(stream pb.MyService_ClientStreamingRPCServer) error {
    var messages []string

    for {
        req, err := stream.Recv()
        if err != nil {
            return err
        }

        messages = append(messages, req.Message)

        if req.Message == "end" {
            break
        }
    }

    message := "Client Streaming RPC received: " + fmt.Sprintf("%v", messages)
    fmt.Println(message)

    return stream.SendAndClose(&pb.ResponseMessage{
        Message: "Client Streaming RPC response",
    })
}

func (s *server) BidirectionalStreamingRPC(stream pb.MyService_BidirectionalStreamingRPCServer) error {
    for {
        req, err := stream.Recv()
        if err != nil {
            return err
        }

        message := "Bidirectional Streaming RPC received: " + req.Message
        fmt.Println(message)

        response := &pb.ResponseMessage{
            Message: "Bidirectional Streaming RPC response",
        }
        if err := stream.Send(response); err != nil {
            return err
        }
    }
}

在上面代码中,我们创建了一个server结构体类型,并实现了MyService的所有RPC方法。每个方法都接收相应的请求消息,并返回对应的响应消息。我们的目标仅是演示如何对上述gRPC Handler进行单元测试,所以这里的实现逻辑非常简单。

接下来,我们就来逐一对这些gRPC的Handler方法进行单测,我们先从简单的UnaryRPC方法开始。

2. Unary RPC Handler的单元测试

Unary RPC是最简单,也是最容易理解的RPC通信模式,即客户端与服务端采用一请求一应答的模式。server类型的UnaryRPC Handler方法的原型如下:

// grpc-test-examples/grpctest/server.go

func (s *server) UnaryRPC(ctx context.Context, req *pb.RequestMessage) (*pb.ResponseMessage, error)

就像文章开头做的那个httpserver的handler单测一样,我们肯定不想真实启动一个gRPC server,也不想测试gRPC服务器本身。我们只想测试服务端handler方法的逻辑是否正确。

观察一下这个方法原型,我们发现它仅依赖两个消息结构:RequestMessage和ResponseMessage,这两个消息结构是上面基于proto文件自动生成的,这样我们就可以不借助任何工具包实现对UnaryRPC handler方法的单测,也无需启动真实的gRPC Server:

// grpc-test-examples/grpctest/server_test.go

type server struct{}

func TestServerUnaryRPC(t *testing.T) {
    s := &server{}

    req := &pb.RequestMessage{
        Message: "Test message",
    }

    resp, err := s.UnaryRPC(context.Background(), req)
    if err != nil {
        t.Fatalf("UnaryRPC failed: %v", err)
    }

    expectedResp := &pb.ResponseMessage{
        Message: "Unary RPC response",
    }

    if resp.Message != expectedResp.Message {
        t.Errorf("Unexpected response. Got: %s, Want: %s", resp.Message, expectedResp.Message)
    }
}

将其改造为基于subtest和表驱动的测试也非常easy:

// grpc-test-examples/grpctest/server_test.go

func TestServerUnaryRPCs(t *testing.T) {
    tests := []struct {
        name           string
        requestMessage *pb.RequestMessage
        expectedResp   *pb.ResponseMessage
    }{
        {
            name: "Test Case 1",
            requestMessage: &pb.RequestMessage{
                Message: "Test message",
            },
            expectedResp: &pb.ResponseMessage{
                Message: "Unary RPC response",
            },
        },
        // Add more test cases as needed
    }

    s := &server{}

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            resp, err := s.UnaryRPC(context.Background(), tt.requestMessage)
            if err != nil {
                t.Fatalf("UnaryRPC failed: %v", err)
            }

            if resp.Message != tt.expectedResp.Message {
                t.Errorf("Unexpected response. Got: %s, Want: %s", resp.Message, tt.expectedResp.Message)
            }
        })
    }
}

如果gRPC handler测试都像UnaryRPC这样简单那就好了,但实际上…,好吧,我们继续向下看就好了。

3. 针对Streaming通信模式的单元测试

3.1 ServerStreamingRPC的测试

前面说过,gRPC支持三种Streaming通信模式:Server-Streaming RPC、Client-Streaming RPC和Bidirectional-Streaming RPC。

我们先来看看Server-Streaming RPC的方法原型:

// grpc-test-examples/grpctest/server.go
func (s *server) ServerStreamingRPC(req *pb.RequestMessage, stream pb.MyService_ServerStreamingRPCServer) error

我们看到除了RequestMessag外,该方法还依赖一个MyService_ServerStreamingRPCServer的类型,这个类型是一个接口类型:

// grpc-test-examples/mygrpc/mygrpc.pb.go

type MyService_ServerStreamingRPCServer interface {
    Send(*ResponseMessage) error
    grpc.ServerStream
}

到这里,你脑子中可能已经冒出了一个想法:使用fake object来对ServerStreamingRPC进行单测,这的确是一个可行的方法,我们下面就基于这个思路实现一下。

注:关于基于fake object进行单测的内容,大家可以看看我以前写的一篇文章《[]单测时尽量用fake object(https://tonybai.com/2023/04/20/provide-fake-object-for-external-collaborators)》。

3.2 基于fake object的测试

我们首先创建一个实现MyService_ServerStreamingRPCServer的fake object用以代替真实运行RPC服务器时由服务器传入的stream object:

// grpc-test-examples/grpctest/server_with_fakeobject_test.go

import (
    "testing"

    pb "demo/mygrpc"

    "google.golang.org/grpc"
)

type fakeServerStreamingRPCStream struct {
    grpc.ServerStream
    responses []*pb.ResponseMessage
}

func (m *fakeServerStreamingRPCStream) Send(resp *pb.ResponseMessage) error {
    m.responses = append(m.responses, resp)
    return nil
}

我们看到fakeServerStreamingRPCStream的Send方法只是将收到的ResponseMessage追加到且内部的ResponseMessage切片中。

接下来我们为ServerStreamingRPC编写测试用例:

// grpc-test-examples/grpctest/server_with_fakeobject_test.go

func TestServerServerStreamingRPC(t *testing.T) {
    s := &server{}  

    req := &pb.RequestMessage{
        Message: "Test message",
    }  

    stream := &fakeServerStreamingRPCStream{}  

    err := s.ServerStreamingRPC(req, stream)
    if err != nil {
        t.Fatalf("ServerStreamingRPC failed: %v", err)
    }  

    expectedResponses := []string{
        "Server Streaming RPC response 1",
        "Server Streaming RPC response 2",
        "Server Streaming RPC response 3",
        "Server Streaming RPC response 4",
        "Server Streaming RPC response 5",
    }                                                                                                          

    if len(stream.responses) != len(expectedResponses) {
        t.Errorf("Unexpected number of responses. Got: %d, Want: %d", len(stream.responses), len(expectedResponses))
    }                                                                                                          

    for i, resp := range stream.responses {
        if resp.Message != expectedResponses[i] {
            t.Errorf("Unexpected response at index %d. Got: %s, Want: %s", i, resp.Message, expectedResponses[i])
        }
    }
}

在这个测试中,ServerStreamingRPC接收一个请求(req),并通过fake stream object的Send方法返回了5个response,通过与预期的response对比,即可做出测试是否通过的断言。

到这里,我们看到:fake object完全满足对gRPC Server Handler进行测试的要求。不过我们需要针对不同的Handler建立不同的fake object类型,和文初基于httptest创建的测试用例相比,用例间欠缺了一些一致性。

那grpc-go是否提供了类似httptest的工具来帮助我们更一致的实现grpc server handler的测试用例呢?我们继续往下看。

3.3 利用grpc-go提供的测试工具包

grpc-go项目在test下提供了bufconn包,可以帮助我们像httptest那样建立用于测试的“虚拟gRPC服务器”,下面是基于bufconn包建立gRPC测试用服务器的代码:

// grpc-test-examples/grpctest/server_with_buffconn_test.go

package main

import (
    "context"
    "log"
    "net"
    "testing"

    pb "demo/mygrpc"

    "google.golang.org/grpc"
    "google.golang.org/grpc/test/bufconn"
)

func newGRPCServer(t *testing.T) (pb.MyServiceClient, func()) {
    // 创建 bufconn.Listener 作为服务器的监听器
    listener := bufconn.Listen(1024 * 1024)

    // 创建 gRPC 服务器
    srv := grpc.NewServer()

    // 注册服务处理程序
    pb.RegisterMyServiceServer(srv, &server{})

    // 在监听器上启动服务器
    go func() {
        if err := srv.Serve(listener); err != nil {
            t.Fatalf("Server failed to start: %v", err)
        }
    }()

    // 创建 bufconn.Dialer 作为客户端连接
    dialer := func(context.Context, string) (net.Conn, error) {
        return listener.Dial()
    }

    // 使用 DialContext 和 bufconn.Dialer 创建客户端连接
    conn, err := grpc.DialContext(context.Background(), "bufnet", grpc.WithContextDialer(dialer), grpc.WithInsecure())
    if err != nil {
        t.Fatalf("Failed to dial server: %v", err)
    }

    // 创建客户端实例
    client := pb.NewMyServiceClient(conn)
    return client, func() {
        err := listener.Close()
        if err != nil {
            log.Printf("error closing listener: %v", err)
        }
        srv.Stop()
    }
}

newGRPCServer是一个用于在测试中创建gRPC服务器和客户端的辅助函数,它使用bufconn.Listen创建一个bufconn.Listener作为服务器的监听器。bufconn包提供了一种在内存中模拟网络连接的方法。然后,它使用grpc.NewServer()创建了一个新的gRPC服务器实例,并使用pb.RegisterMyServiceServer将待测的服务实例(这里是server类型实例)注册到gRPC服务器中。接下来,它创建了与该服务器建连的gRPC客户端,由于该客户端要与bufconn.Listener建连,这里用了一个dialer函数,该函数将通过调用listener.Dial()来建立与服务器的连接。之后基于该连接,我们创建了MyServiceClient的客户端实例,并返回,供测试用例使用。

基于newGPRCServer这种方式,我们改造一下UnaryRPC的测试用例:

// grpc-test-examples/grpctest/server_with_buffconn_test.go

func TestServerUnaryRPCWithBufConn(t *testing.T) {
    client, shutdown := newGRPCServer(t)
    defer shutdown()

    tests := []struct {
        name           string
        requestMessage *pb.RequestMessage
        expectedResp   *pb.ResponseMessage
    }{
        {
            name: "Test Case 1",
            requestMessage: &pb.RequestMessage{
                Message: "Test message",
            },
            expectedResp: &pb.ResponseMessage{
                Message: "Unary RPC response",
            },
        },
        // Add more test cases as needed
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            resp, err := client.UnaryRPC(context.Background(), tt.requestMessage)
            if err != nil {
                t.Fatalf("UnaryRPC failed: %v", err)
            }

            if resp.Message != tt.expectedResp.Message {
                t.Errorf("Unexpected response. Got: %s, Want: %s", resp.Message, tt.expectedResp.Message)
            }
        })
    }
}

我们看到,相对于前面的TestServerUnaryRPCs,两者复杂度在一个层次。如果结合下面的ServerStreamRPC的测试用例,你就能看出这种方式在测试用例一致性方面的优势了:

// grpc-test-examples/grpctest/server_with_buffconn_test.go

func TestServerServerStreamingRPCWithBufConn(t *testing.T) {
    client, shutdown := newGRPCServer(t)
    defer shutdown()

    req := &pb.RequestMessage{
        Message: "Test message",
    }

    stream, err := client.ServerStreamingRPC(context.Background(), req)
    if err != nil {
        t.Fatalf("ServerStreamingRPC failed: %v", err)
    }

    expectedResponses := []string{
        "Server Streaming RPC response 1",
        "Server Streaming RPC response 2",
        "Server Streaming RPC response 3",
        "Server Streaming RPC response 4",
        "Server Streaming RPC response 5",
    }

    gotResponses := []string{}

    for {
        resp, err := stream.Recv()
        if err != nil {
            break
        }
        gotResponses = append(gotResponses, resp.Message)
    }

    if len(gotResponses) != len(expectedResponses) {
        t.Errorf("Unexpected number of responses. Got: %d, Want: %d", len(gotResponses), len(expectedResponses))
    }

    for i, resp := range gotResponses {
        if resp != expectedResponses[i] {
            t.Errorf("Unexpected response at index %d. Got: %s, Want: %s", i, resp, expectedResponses[i])
        }
    }
}

我们再也无需为每个Server Handler建立各自的fake object了!

由此看到:grpc-go的test/bufconn就是类似httptest的那个grpc server handler的测试脚手架搭建工具。

3.4 其他Streaming模式的Handler测试

有了bufconn这一利器,其他Streaming模式的Handler测试实现逻辑就大同小异了。本文示例中的ClientStreamingRPC和BidirectionalStreamingRPC两个Handler的测试用例就作为作业,交给各位读者去完成吧!

4. 小结

在本文中,我们详细探讨了如何对gRPC服务端Handler进行单元测试,我们的目标是找到像net/http/httptest包那样的,可以为gRPC服务端handler测试提供脚手架代码帮助的测试方法。

我们按照gRPC的四种通信方式,由简到难的逐一探讨各种Handler的单测方法。UnaryRPC handler测试最为简单,毫无技巧的普通测试逻辑便能应付。

但一旦涉及streaming通信方式的测试,我们就需要借助类似fake object的单测技术了。但fake object也有不足,那就是需要为每个RPC handler建立单独的fake object,费时费力还缺少一致性!

好在,grpc-go项目为我们提供了test/bufconn包,该包可以像net/http/httptest包那样帮助我们快速建立可复用的测试脚手架代码,这样我们便可以为所有服务端RPC Handler建立一致、稳定的单元测试用例了!

当然,服务端RPC Handler的单测方法可能不止文中提及这些,各位读者如果有更好的方法和实践,欢迎在评论区留言!

本文涉及的源码可以在这里下载。

5. 参考资料


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

通过实例理解Web应用跨域问题

本文永久链接 – https://tonybai.com/2023/11/19/understand-go-web-cross-origin-problem-by-example

在开发Web应用的过程中,我们经常会遇到所谓“跨域问题(Cross Origin Problem)”。跨域问题是由于浏览器的同源策略(Same-origin policy)导致的,它限制了不同源(Origin:域名、协议或端口)之间的资源交互。在这篇文章中,我将通过一些具体的示例来把跨域问题以及主流解决方法说清楚,供大家参考。

1. 什么是跨域问题

跨域问题指的是当一个Web应用程序在访问另一个域(Origin)的资源时,浏览器会阻止这个跨域的请求(Cross Origin Request)。这句针对跨域问题的诠释里有一个术语“域(Origin)”,它到底是什么呢?

1.1 什么是Origin

在Mozilla官方术语表中,”Origin”指的是一个Web应用/网站的标识,由协议(protocol/scheme)、域名(domain,或主机名host)和端口(port)组成。如果两个应用/网站的协议、域名和端口都相同,它们就被认为是同源的(same origin);否则,它们被视为不同源。我们看到:Origin是一个典型的三元组(protocol, domain, port),只有三元组相同的两个应用/站点才会被认为是同源的(same origin)。

下面是一些判断两个应用/站点是否同源的例子及判断理由:

知道了Origin三元组后,我们来揪出跨域问题背后的“罪魁祸首”。

1.2 同源策略 – 跨域问题的“罪魁祸首”

浏览器为了增加安全性而采取的一项重要措施,那就是“同源策略”。同源策略限制了一个网页中的脚本只能与同源(三元组:协议、域名、端口相同)的资源进行交互,而不能直接访问不同源的资源。

浏览器的这种同源策略限制主要包含以下几点:

  • Cookie、LocalStorage和IndexDB无法读取非同源的资源。
  • DOM和JS对象无法获得非同源资源。例如iframe、img等标签加载的资源,DOM无法访问;JS无法操作非同源页面的DOM。
  • AJAX请求不能发送到非同源的域名,浏览器会阻止非同源的AJAX请求。
  • 不能读取非同源网页的Cookie、LocalStorage和IndexDB。

下图(图片来自网络)展示了同源策略对恶意脚本代码对非同源数据访问的限制:

上面这张图片清晰地展示了恶意脚本代码试图访问非同源数据进行恶意登录的过程。

首先,用户通过浏览器访问正常网站domain1.com,并用用户名密码正常登录该网站,domain1.com使用cookie技术在用户浏览器中保存了与用户登录domain1.com相关的会话信息或token信息。

之后,用户又访问了恶意站点domain2.com,该站点首页的脚本代码在被下载到用户浏览器中后,试图访问浏览器cookie中有关domain1.com的cookie信息,并试图用该信息冒充用户登录domain1.com做恶意操作。

浏览器的同源策略成功禁止了恶意代码的这些恶意操作,浏览器从domain2.com下载的脚本代码只能访问与domain2.com同源的信息。

通过这个过程我们看到:浏览器同源策略的本意是防止恶意网站通过脚本窃取用户的敏感信息,比如登录凭证、个人资料等。如果同源策略不存在,恶意网站就可以自由地读取、修改甚至篡改其他网站的数据,给用户和网站带来巨大的安全风险。

不过,这种策略的存在给开发人员在开发过程带来诸多烦恼,比如:跨域数据访问限制、跨域脚本调用限制以及无法在不同域名之间共享会话信息等。为此,开发人员需要使用一些技术手段来解决这些跨域问题,这增加了开发的复杂性,并且需要额外的配置和处理,给开发人员带来了一定的麻烦。此外,不正确地处理跨域请求也可能导致安全漏洞,因此开发人员还需要对跨域请求进行合理的安全控制和验证。

1.3 获取请求中的“origin”

为了做同源检测,我们需要获取和确定请求中的origin信息。那么如何读取和确定呢?

在HTTP请求头中,”Origin”字段表示发送请求的页面或资源的源信息。该字段包含了发送请求的页面的完整URL或者仅包含协议、域名和端口的部分URL。

在同源策略下,所有的跨域请求都必须携带”Origin”请求头字段,指示请求的来源。因此,在符合同源策略的情况下,每个请求都应该携带”Origin”字段。

在服务器端,我们可以通过读取请求头中的”Origin”字段来确定请求的origin,具体的方法会根据使用的编程语言和框架而有所不同,例如在Go中可以通过r.Header.Get(“Origin”)来获取”Origin”字段的值。由于”Origin”字段是由客户端提供的,服务器端在处理请求时,需要进行验证和安全性检查,以防止伪造或恶意的请求。

然而,有些情况下,请求可能不会携带”Origin”字段。例如,非浏览器环境下的请求(如服务器间的请求、命令行工具等)可能不会包含”Origin”字段。此外,某些旧版本的浏览器可能也不会发送”Origin”字段。

在这种情况下,我们就需要通过其他方式来确定请求的来源。例如,服务端可以查看请求头中的Referer字段来获取请求的来源。Referer字段指示了请求的来源页面的URL。通过检查Referer字段,服务端可以判断请求是否来自不同的域。此外,服务器端还可以检查请求头中的Host字段,该字段指示了请求的目标主机。如果请求的目标主机与服务端所在的主机不一致,那么可以判断请求是跨域的。

不过,需要注意的是,服务端的这些方法都依赖于请求头中的信息,而请求头可以被客户端伪造或修改。因此,为了更可靠地判断请求是否跨域,服务端应该综合考虑多个因素,并进行适当的验证和安全措施。

下面我们看一个可以复现跨域问题的示例。

1.4 复现跨域问题的Go代码示例

出现跨域问题的示例的图示如下:

在这个示例中,我们有两个Web应用:server1.com:8081和server2.com:8082。根据前面对Origin的理解,这两个Web应用显然不是同源的。

server1.com和server2.com对应的Go代码分别如下:

// cross-origin-examples/reproduce/server1.com

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "text/html; charset=utf-8")

        html := `
            <!DOCTYPE html>
            <html>
            <head>
                <title>Cross-Origin Example</title>
                <script>
                    function makeCrossOriginRequest() {
                        var xhr = new XMLHttpRequest();
                        xhr.open("GET", "http://server2.com:8082/api/data", true);
                        xhr.onreadystatechange = function() {
                            if (xhr.readyState === 4 && xhr.status === 200) {
                                console.log(xhr.responseText);
                            }
                        };
                        xhr.send();
                    }
                </script>
            </head>
            <body>
                <h1>Cross-Origin Example</h1>
                <button onclick="makeCrossOriginRequest()">Make Cross-Origin Request</button>
            </body>
            </html>
        `

        fmt.Fprintf(w, html)
    })

    err := http.ListenAndServe("server1.com:8081", nil)
    if err != nil {
        panic(err)
    }
}

// cross-origin-examples/reproduce/server2.com

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/api/data", func(w http.ResponseWriter, r *http.Request) {
        fmt.Printf("recv request: %#v\n", *r)
        w.Write([]byte("Welcome to api/data"))
    })

    http.ListenAndServe("server2.com:8082", nil)
}

注:在编译启动上面两个程序之前,需要在/etc/hosts中将server1.com和server2.com的地址指为127.0.0.1。

从示意图来看,用户使用浏览器与两个Web应用的交互过程是这样的:

首先,用户通过浏览器访问了server1.com:8081的主页,并收到server1.com:8081返回的应答包体。该应答包体是一个html页面,如下图:

接下来,用户点击“Make Cross-Origin Request”按钮,页面内通过ajax向server2.com:8082/api/data发起GET请求。

最后,我们在(Edge/Chrome)浏览器的控制台上将看到下面错误:

通过下面server2.com的日志,我们看到ajax请求已经发到server2.com并被正确处理:

recv request: http.Request{Method:"GET", URL:(*url.URL)(0xc00010a480), Proto:"HTTP/1.1", ProtoMajor:1, ProtoMinor:1, Header:http.Header{"Accept":[]string{"*/*"}, "Accept-Encoding":[]string{"gzip, deflate"}, "Accept-Language":[]string{"zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6"}, "Connection":[]string{"keep-alive"}, "Origin":[]string{"http://server1.com:8081"}, "Referer":[]string{"http://server1.com:8081/"}, "User-Agent":[]string{"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36 Edg/116.0.1938.81"}}, Body:http.noBody{}, GetBody:(func() (io.ReadCloser, error))(nil), ContentLength:0, TransferEncoding:[]string(nil), Close:false, Host:"server2.com:8082", Form:url.Values(nil), PostForm:url.Values(nil), MultipartForm:(*multipart.Form)(nil), Trailer:http.Header(nil), RemoteAddr:"127.0.0.1:49773", RequestURI:"/api/data", TLS:(*tls.ConnectionState)(nil), Cancel:(<-chan struct {})(nil), Response:(*http.Response)(nil), ctx:(*context.cancelCtx)(0xc000106320)}

server2.com在服务端并没有主动判断是否是同源请求,但即使服务器没有进行跨域校验并返回成功的响应和数据,浏览器也会拦截脚本读取跨域响应数据的尝试,这是由浏览器的同源策略所决定的。这也是我们看到上面截图中报错的原因。

那么解决跨域问题有哪些主流的解决方法呢?我们继续看一下。

2. 跨域问题的主流解决方法

为了解决跨域问题,有下面几种常见的解决方法:

  • JSONP(JSON with Padding)

通过动态创建\<script>标签来加载跨域的JavaScript脚本,进而实现跨域数据获取。

  • CORS(跨域资源共享, CORS是Cross-Origin Resource Sharing)

通过在服务器响应头中设置CORS访问策略以允许指定的Origin访问资源。

  • 代理服务器

在同域下创建一个代理服务器,将跨域请求转发到目标服务器并返回结果。代理服务器对响应头统一增加Access-Control-Allow-Origin等CORS相关字段,表示允许跨域访问。

其中CORS是解决跨域问题时应用最为广泛的方法。CORS(跨域资源共享)主要是通过设置HTTP头来解决跨域问题的。

服务器端通过在响应(Response)的HTTP头中设置Access-Control-Allow-Origin头来设置允许的请求来源域(Origin: 三元组)。

如果设置为“*”,则表示允许任意域发起跨域请求:

Access-Control-Allow-Origin: *

也可以在响应中将Access-Control-Allow-Origin设置为只允许指定的Origin访问资源,比如:

Access-Control-Allow-Origin: http://server1.com:8081

Access-Control-Allow-Origin头的值还支持设置多个origin,多个origin用逗号分隔:

Access-Control-Allow-Origin: http://server1.com:8081,https://server2.com:8082

注:关于Access-Control-Allow-Origin的值是否要带上protocol和port的问题,我实测的情况是必须带。前面说过:Origin是三元组,只有完全相同才算是同源。

此外,域名必须具体到二级域名才能匹配成功。顶级域名如“.com”、“.org”是不允许的。

服务端响应的跨域设置还不仅Access-Control-Allow-Origin一个,我们还可以设置Access-Control-Allow-Methods、Access-Control-Allow-Headers、Access-Control-Max-Age等字段来更细粒度的进行跨域访问控制。

注:有些值Access-Control-XXX-xxx字段仅用于Preflight Request(预检请求),比如:Access-Control-Allow-Methods。CORS Preflight Request是一种CORS请求,它使用特定的方法和Header检查CORS协议是否被理解和服务器是否被感知。它是一个OPTIONS请求,使用两个或三个HTTP请求头: Access-Control-Request-Method(访问控制请求方法)、Origin(起源)和可选的 Access-Control-Request-Headers(访问控制请求头)。

3. 使用CORS解决跨域问题的示例

下面我们修改一下server2.com的代码来解决前面遇到的跨域问题:

// cross-origin-examples/solve/server2.com/main.go

func main() {
    http.HandleFunc("/api/data", func(w http.ResponseWriter, r *http.Request) {
        fmt.Printf("recv request: %#v\n", *r)
        w.Header().Set("Access-Control-Allow-Origin", "http://server1.com:8081")
        w.Write([]byte("Welcome to api/data"))
    })

    http.ListenAndServe("server2.com:8082", nil)
}

我们仅在server2.com/main.go中增加了一行代码,旨在允许来自http://server1.com:8081的跨域请求访问server2.com的资源:

w.Header().Set("Access-Control-Allow-Origin", "http://server1.com:8081")

启动新版server2.com后,再点击页面上的“Make Cross-Origin Request”按钮,我们在浏览器的控制台上就能看到应答成功被接受并显示。

4. 小结

本文介绍了日常Web应用开发过程中经常遇到的跨域问题,探讨了“域(Origin)”概念以及跨域问题的真实原因:即浏览器的同源策略限制了不同源请求资源的访问。

接下来通过Go代码示例演示了跨域问题的表现形式,并介绍了几种主要的跨域解决方案,最后对最常见的CORS解决方案做了细致说明,并用实例展示了服务端设置CORS头后跨域问题的解决。

希望本文可以帮助大家更深入的理解和掌握Web应用跨域问题以及解决方法。

本文涉及的源码可以在这里下载。

5. 参考资料


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats