提到session,大家肯定会联想到登录,登录成功后记录登录状态,同时标记当前登录用户是谁.功能大体上就是这个样子,但是今天要讲的不是功能,而是实现.通过探讨session的实现方式来发掘一些可能你之前不知道的有趣的事情.为 了记录session,在客户端和服务器端都要保存数据,客户端记录一个标记,服务器端不但存储了这个标记同时还存储了这个标记映射的数据.好吧,还是说 点白话吧,在客户端记录的其实是一个sessionid,在服务器端记录的是一个key-value形式的数据结构,这里的key肯定是

Cookie Cookie是什么 HTTP是无状态协议,服务器不能记录浏览器的访问状态,也就是说服务器不能区分两次请求是否由同一个客户端发出 Cookie就是解决HTTP协议无状态的方案之一,中文是小甜饼的意思 Cookie实际上就是服务器保存在浏览器上的一段信息.浏览器有了Cookie之后,每次向服务器发送请求时都会同时将该信息发送给服务器,服务器收到请求后,就可以根据该信息处理请求 Cookie由服务器创建,并发送给浏览器,最终由浏览器保存 Cookie的用途 保持用户登录状态 Cookie

本文核心内容是利用jwt-go中间件来开发golang webapi用户登陆模块的token下发和验证,小程序登陆功能只是一个切入点,这套逻辑同样适用于其他客户端的登陆处理. 小程序登陆逻辑 小程序的登陆逻辑在其他博主的文章中已经总结得非常详尽,比如我参考的是这篇博文:微信小程序登录逻辑整理,所以在这里不再赘述,只是大致归纳一下我的实现流程: 在小程序端调用wx.login方法,异步获得到微信下发的 jscode ,然后将 jscode 发送到 golang 服务端(如果需要详细用户信息,见参考

前言: go语言的gin框架go里面比较好的一个web框架, github的start数超过了18000.可见此框架的可信度 如何获取请求中的参数 假如有这么一个请求: POST   /post/test?id=1234&page=1  HTTP/1.1 请求头:  Content-Type: application/x-www-form-urlencoded form表单参数:  name=manu&message=this_is_great gin的实现: id := c.Query(

GRBAC 项目地址: https://github.com/storyicon/grbac Grbac是一个快速,优雅和简洁的RBAC框架.它支持增强的通配符并使用Radix树匹配HTTP请求.令人惊奇的是,您可以在任何现有的数据库和数据结构中轻松使用它. grbac的作用是确保指定的资源只能由指定的角色访问.请注意,grbac不负责存储鉴权规则和分辨"当前请求发起者具有哪些角色",更不负责角色的创建.分配等.这意味着您应该首先配置规则信息,并提供每个请求的发起者具有的角色. grb

前言: 一切语言.技术或者框架,本质都是工具,工具的价值在于为使用者提供竞争优势. 一.Beego和Gin全方位比较 MVC Beego支持完整的MVC, Gin不支持完整的MVC(需要开发者自己实现MVC) 路由&Session Beego支持正则路由, Gin不支持正则路由 Beego支持Session, Gin不支持Session(需要安装另外的包) 安装session,推荐包:github.com/astaxie/session 性能 二.适用场景 Beego在业务方面较Gin支持的更多

要上传图片到aws s3首先需要 知道 aws 的地区 也就是region ,还需要知道储存桶的名字,其次就是Access key ID和Secret access key package handler import ( "bytes" "io/ioutil" "log" "net/http" "github.com/aws/aws-sdk-go/aws" "github.com/aws/aws

上代码 腾讯这个例子还是很值得学习的,不轻有东西,单也不重到看着都蒙圈的样子. https://github.com/Tencent/bk-cmdb/blob/master/src/web_server/service/service.go Beego没gin配置静态页面方便 下面是gin的静态页面承载配置. ws.Static("/static", s.Config.Site.HtmlRoot) ws.LoadHTMLFiles(s.Config.Site.HtmlRoot + &q

Cookie和Session Cookie和Session是Web开发绕不开的一个环节,本文介绍了Cookie和Session的原理及在Go语言中如何操作Cookie. Cookie Cookie的由来 HTTP协议是无状态的,这就存在一个问题. 无状态的意思是每次请求都是独立的,它的执行情况和结果与前面的请求和之后的请求都无直接关系,它不会受前面的请求响应情况直接影响,也不会直接影响后面的请求响应情况. 一句有意思的话来描述就是人生只如初见,对服务器来说,每次的请求都是全新的. 状态可以理解为

文章引用自 Cookie和Session Cookie和Session是Web开发绕不开的一个环节,本文介绍了Cookie和Session的原理及在Go语言中如何操作Cookie. Cookie Cookie的由来 HTTP协议是无状态的,这就存在一个问题. 无状态的意思是每次请求都是独立的,它的执行情况和结果与前面的请求和之后的请求都无直接关系,它不会受前面的请求响应情况直接影响,也不会直接影响后面的请求响应情况. 一句有意思的话来描述就是人生只如初见,对服务器来说,每次的请求都是全新的. 状

原文链接: https://blog.by24.cn/archives/about-session.html Web 开发中,Session 是经常用到的概念,但是在日常交流中,似乎又经常引起误解. 在我看来,引发误解的原因主要有两个: 大量使用简称,导致混淆了 数据 与 索引 不同 语言/框架 对 Session 做了不同形式的封装,导致特征不同 下面,我就尝试着捋一下整个问题,看看能不能尽量消除这些误会. 注:其它通讯领域也有使用 Session 这个词汇,本文仅探讨 Web 开发中的 Se

一.对mvc的支持 beego支持完整的mvc M:Model,beego orm,把数据库数据变成object 特性 支持go的所有类型存储 更简洁的curd风格 完整实现了健壮的ORM 支持的数据库 mysql.postgresql.sqlite3 V:View模板 特性 支持静态文件处理 支持模板的处理 支持模板的分页处理 C:各种业务逻辑处理 特性 路由控制 控制器函数 支持csrf session 错误处理和日志功能 gin不支持完整的mvc 需要开发者自己实现mvc 特性 支持HTM

功能和背景介绍 在项目的登录功能中,如果在登录时发现用户名和密码在用户表中不存在,会自动将用户名和密码保存在用户表中,创建一个新的用户. 因此,除了使用手机号和验证码登录以外,还支持使用用户名.密码进行登录. 如果首次使用手机号和验证码进行登录,会默认将手机号作为用户名创建新的用户,将用户结构体对象的数据保存在数据库中. 因此,我们有必要创建用户表. 用户数据结构体定义 在项目中,使用结构体定义用户数据结构.结构体定义如下所示: type Member struct { Id int64 `xo

用户头像上传 功能介绍 在用户中心中,允许用户更换自己的头像.因此,我们开发上传一张图片到服务器,并保存成为用户的头像. 接口解析 在用户模块的控制器MemberController中,解析头像上传的接口,解析如下: func (mc *MemberController) Router(engine *gin.Engine) { ... //用户头像上传 engine.POST("/api/upload/avator",mc.uploadAvator) } 在文件上传过程中,后台服务器

跨域简介 当两个域具有相同的协议(如http), 相同的端口(如80),相同的host,那么我们就可以认为它们是相同的域(协议,域名,端口都必须相同). 跨域就指着协议,域名,端口不一致,出于安全考虑,跨域的资源之间是无法交互的(例如一般情况跨域的JavaScript无法交互,当然有很多解决跨域的方案) 解决跨域几种方案 /* CORS 普通跨域请求:只服务端设置Access-Control-Allow-Origin即可, 前端无须设置,若要带cookie请求:前后端都需要设置. JSONP 缺

中间件推荐 1.1.1. 列表 谷歌翻译欢迎查看原文 https://github.com/gin-gonic/contrib/blob/master/README.md RestGate - REST API端点的安全身份验证 staticbin - 用于从二进制数据提供静态文件的中间件/处理程序 gin-cors - CORS杜松子酒的官方中间件 gin-csrf - CSRF保护 gin-health - 通过gocraft/health报告的中间件 gin-merry - 带有上下文的漂

在gin框架中使用JWT JWT全称JSON Web Token是一种跨域认证解决方案,属于一个开放的标准,它规定了一种Token实现方式,目前多用于前后端分离项目和OAuth2.0业务场景下. 什么是JWT? JWT全称JSON Web Token是一种跨域认证解决方案,属于一个开放的标准,它规定了一种Token实现方式,目前多用于前后端分离项目和OAuth2.0业务场景下. 为什么需要JWT? 在之前的一些web项目中,我们通常使用的是Cookie-Session模式实现用户认证.相关流程大

package main import ( "github.com/gin-gonic/gin" "awesomeProject/app/app_routers" "strings" "fmt" "net/http" ) /* 路由初始化*/ var ( engine = gin.Default() ) func main() { // 允许使用跨域请求 全局中间件 engine.Use(Cors()) /

Gin封装的最好的地方就是context和对response的处理. github的README的介绍,基本就是对这两个东西的解释. 本篇文章主要解释context的使用方法, 以及其设计原理 为什么要将Request的处理封装到Context中 在阅读gin的源码时, 请求的处理是使用type HandlerFunc func(*Context)来处理的. 也就是 func(context *gin.Context) { context.String(http.StatusOK, "some

跨域访问的问题 OPTIONS请求 全局跨域访问中间件 // 跨域访问:cross origin resource share func Cors() gin.HandlerFunc { return func(context *gin.Context) { method := context.Request.Method origin := context.Request.Header.Get("Origin") var headerKeys []string for k, _ :=

Cookie介绍 Http协议是无状态的,服务器不能记录浏览器的访问状态,也就是说服务器不能判断请求的客户端是否已经登录 Cookie就是解决http协议无状态的方案之一 Cookie实际上就是服务器保存在浏览器上的一小段文本信息,浏览器有了Cookie之后,每次向服务器发送请求时都会同时将该信息发送给服务器,服务器收到请求后,就可以根据该信息处理请求 Cookie由服务器创建,并发送给浏览器,最终由浏览器进行保存 cookie的用途: 测试服务端发送cookie给客户端,客户端请求时携带coo