首页 文章 精选 留言 我的

精选列表

搜索[多分片],共10000篇文章
优秀的个人博客,低调大师

EMQX 多版本发布、新增自定义函数功能

11 月,EMQX 开源版和企业版分别发布了多个迭代版本,在安全性保障和生态集成方面又有了新的提升。 MQTT 消息云服务 EMQX Cloud 推出了新功能——自定义函数,用户可以更方便地将 IoT 数据处理为符合数据流的数据格式。 EMQX 11 月 EMQX 开源版发布了 v4.4.11、v4.3.22 以及 v5.0.10、v5.0.11 版本,企业版发布了 v4.3.17 以及 v4.4.11 版本。 由于开源版 4.3 版本已达到 18 个月生命周期(v4.3.0 于 2021 年 5 月 8 日发布),因此 v4.3.22 是 EMQX 4.3 开源版的最后一个社区版本。 同时,我们还将 v4.4 和 v5.0 的二进制包中 Erlang/OTP 版本从 v24.1.5 升级到了 v24.3.4.2。 Google Cloud Pub/Sub 集成 企业版 v4.4.11 中新增了 Google Cloud Pub/Sub 集成,您可以使用 Pub/Sub 将 MQTT 消息发送到位于 Google Cloud 上的服务和托管的后端应用中,更快地基于 GCP 构建物联网应用。 对于 Google IoT Core 用户,您无需做更多改变就能将 MQTT 传输层迁移至 EMQX,继续使用 Google Cloud 上的应用和服务。 CRL 与 OCSP Stapling 持有数字证书的物联网设备,如果出现私钥泄漏、证书信息有误的情况,或者设备需要永久销毁时,需要吊销对应证书以确保不被非法利用,4.4 版本中加入了 CRL 与 OCSP Stapling 功能用以解决这个问题,为您的物联网应用提供灵活且高级别的安全保障。 CRL(Certificate Revocation List,证书吊销列表) 是由 CA 机构维护的一个列表,列表中包含已经被吊销的证书序列号和吊销时间。EMQX 允许配置 CA 的请求端点并定时刷新获取 CRL,而客户端无需维护 CRL,在连接握手时通过 EMQX 即可完成证书有效性验证。 OCSP(Online Certificate Status Protocol,在线证书状态协议)是另外一个证书吊销方案,相比于 CRL, OCSP 提供了实时的证书验证能力。OCSP Stapling 是该项技术的最新改进,进一步解决了 OCSP 隐私问题和性能问题。 启用 OCSP Stapling 后,EMQX 将自行从 OCSP 服务器查询证书并缓存响应结果,当客户端向 EMQX 发起 SSL 握手请求时,EMQX 将证书的 OCSP 信息随证书链一同发送给客户端,由客户端对证书有效性进行验证。 固定认证与 ACL 顺序 在 EMQX 4.x 版本中添加了两个新配置,用于设置认证和 ACL 检查顺序。当启用多个认证或 ACL 插件/模块时,您可以使用逗号分隔的插件名称或别名来设置其执行顺序。 通过文件初始化 API 密钥 4.x 版本的另一个新特性是能够通过文件初始化 API 密钥,预设的密钥可以帮助用户在 EMQX 启动时做一些工作:如运维人员编写运维脚本管理集群状态,开发者导入认证数据到内置数据库中、初始化自定义的配置参数,在之前这些工作必须在启动完成后新建密钥对才能进行。 # 指定 bootstrap 文件 # etc/plugins/emqx_management.conf management.bootstrap_user_file ="etc/bootstrap_apps_file.txt" ​ # 使用 {appid}:{secret} 的格式初始化密钥对 # etc/bootstrap_apps_file.txt appid1:secret appid2:secret2 产品优化改进 我们修复了多个已知 BUG,包括连接 MongoDB 认证失败时打印大量日志的错误,消息重发布或桥接消息到其他 MQTT Broker 时添加主题校验流程避免消息发布错误,以及 EMQX 5.0 中大规模性能测试时连接数非常大的情况下复制节点可能无法启动的问题。 除此之外,我们还在 MQTT 协议实现和安全设计上中添加了许多改进,包括 gen_rpc 库质询-响应式的身份验证支持。 更好的运维体验 4.x 版本中移除对 GET /emqx_prometheus 接口的认证要求,用户可以更方便地使用 Prometheus 抓取 EMQX 指标。 此外,上月发起的 v5.0 中 REST API 体验改善计划也正在进行。EMQX 5.0.11版本中已经包含了一些不错的改进,包括 /gateways API 的重新设计。 各版本详细更新日志请查看: EMQX 开源版 v4.3.22 EMQX 开源版 v4.4.11 EMQX 企业版 v4.3.17 EMQX 企业版 v4.4.11 EMQX 开源版 v5.0.10 EMQX 开源版 v5.0.11 EMQX Cloud 自定义函数 EMQX Cloud 全新推出了自定义函数功能,借助云平台的函数计算能力,用户可定义编写脚本,并在数据集成功能中调用该函数。设备通过 topic 上报数据,平台接收数据后,数据解析脚本对设备上报的数据进行处理,进而再转入其他的工作流当中。 自定义函数功能可应用于多种场景:如将设备端上报的非十进制数据转化为十进制数据,符合应用标准后存入到数据库中;或者是将设备中的原始数据转化、整合为符合特殊行业协议的数据格式。 目前自定义函数支持部署在阿里云平台上的专业版用户,每个开通服务的部署都可以获得每个月 50000 次的免费调用次数,现在开通服务即可以立刻使用。有关自定义函数功能详情请关注后续推送。 优化丢弃消息监控指标 对丢弃消息监控指标进行了优化。现在,在部署控制台中选择指标,在丢弃消息指示中,可以看到丢弃消息的种类:过期而被丢弃的消息以及因为队列占满而被丢弃的消息。这将使运维监控和错误排查更方便。 EMQX Kubernetes Operator 11 月,自动化部署管理工具 EMQX Kubernetes Operator 进行了如下完善优化: 解决了在 v2alpha1 中,当没有发现 sts 时候出现的 crash bug 解决了在用户没有修改 CR 的情况下,sts 可能会一直更新的问题 解决了当 replicas 设置为 1 时,service 无法更新的问题 修复了在 status.Condition 中,lastTransitionTime 字段的错误 新增支持 EMQX 和 reloader 镜像 Registry 版权声明: 本文为 EMQ 原创,转载请注明出处。 原文链接:https://www.emqx.com/zh/blog/emqx-newsletter-202211

优秀的个人博客,低调大师

ThingsPanel 发布物联网手机客户端(多图)

ThingsPanel 是一款物联网底层开源软件,主要功能是采集设备数据、可视化、自动化控制,为众多集成商、设备商、方案商提供快速的产品和交付方案。 ThingsPanel的手机端 APP 用于对ThingsPanel提供移动管理和控制支持。主要实现的功能包括监测、控制、策略、以及设备添加管理等功能。是ThingsPanel的轻型使用客户端,支持SAAS场景。 手机端的功能特点包括: 使用Uniapp开发,可以方便的编译成iOS,安卓,微信小程序以及其他小程序,H5。 可以扫码添加设备(设备需要在后台先导入)。 查看监测值。 切换智能化业务和设备分组。 手动控制。 设置控制策略,分为设备触发和时间条件触发两种。 查看操作日志。 个人账号管理功能。 手机验证码登录。 小程序截图 代码库位置 https://gitee.com/ThingsPanel/app

优秀的个人博客,低调大师

ShopWind v3.4.0 多商户商城更新发布

📚 项目介绍 ShopWind是一款基于Yii2.0框架深度重构的B2B2C、O2O行业的电商系统软件,您可以轻松创建和发布属于自己品牌的专业的电商平台,进行全方位的品牌宣传和产品推广。ShopWind v3.x标准版开始走向开源,打造一款完全开源的电商系统,可以免费用于商业运营或者二次开发,免于商业版权的烦恼。v3.x商业版包含PC、手机H5、微商城、APP客户端(Andorid+iOS)、微信小程序、今日头条小程序等多端,其中PC端为开源免费项目,移动端为增值项目。ShopWind提供专业、快速、安全的底层软件设计和免费的更新升级服务,做好完善的开发文档和接口文档方便开发者在底层软件的基础上开发各种应用、模板、或者插件。 🎨 系统演示 PC体验 前台体验:http://test.shopwind.net买家测试账号:buyer 密码:123456 支付密码:123456 后台体验:http://test.shopwind.net/admin平台管理员账号:admin 密码:123456 商家体验:http://test.shopwind.net/seller/login.html商家测试账号:seller 密码:123456 移动端体验(商业版) H5端体验:https://h5.shopwind.net买家测试账号:18978189192 密码:111111 支付密码:111111 小程序/APP体验(商业版) 微信小程序(手机浏览器点击链接):https://wxaurl.cn/VUdm2kw795s Android(安卓版)体验:https://appgallery.huawei.com/#/app/C103448437 iOS(苹果版)体验:https://apps.apple.com/cn/app/id1548625748 商家端体验(小程序):https://wxaurl.cn/gIG5wMZSOFc 通用体验账号:买家(账号:18978189192 密码:111111 支付密码:111111)、商家(账号:18978189171 密码:111111) 📚 项目展示 🍻 更新内容 【升级】平台后台管理功能全面升级 【优化】后台栏目设置 【优化】管理权限设置 【优化】营销工具,应用市场等模块 【优化】应用/工具订购功能及流程 【增加】后台门店审核,分销商审核 【优化】图片上传效果 【优化】前台部分页面效果 【优化】精简多余的js/css代码 【修复】后台弹窗不居中问题 【修复】后台权限问题 【修复】修复后台查看订单页错位

优秀的个人博客,低调大师

多图详解万星 Restful 框架原理与实现

rest框架概览 我们先通过 go-zero 自带的命令行工具 goctl 来生成一个 api service,其 main 函数如下: func main() { flag.Parse() var c config.Config conf.MustLoad(*configFile, &c) ctx := svc.NewServiceContext(c) server := rest.MustNewServer(c.RestConf) defer server.Stop() handler.RegisterHandlers(server, ctx) fmt.Printf("Starting server at %s:%d...\n", c.Host, c.Port) server.Start() } 解析配置文件 将配置文件传入,初始化 serviceContext 初始化 rest server 将 context 注入 server 中: 注册路由 将 context 中的启动的 endpoint 同时注入到 router 当中 启动 server 接下来我们来一步步讲解其设计原理!Let's Go! web框架 从日常开发经验来说,一个好的 web 框架大致需要满足以下特性: 路由匹配/多路由支持 支持自定义中间件 框架和业务开发完全解耦,方便开发者快速开发 参数校验/匹配 监控/日志/指标等服务自查功能 服务自保护(熔断/限流) go-zero rest设计 > https://github.com/zeromicro/go-zero/tree/master/rest 概览 借助 context (不同于 gin 的 context),将资源初始化好 → 保存在 serviveCtx 中,在 handler 中共享(至于资源池化,交给资源自己处理,serviveCtx 只是入口和共享点) 独立 router 声明文件,同时加入 router group 的概念,方便开发者整理代码结构 内置若干中间件:监控/熔断/鉴权等 利用 goctl codegen + option 设计模式,方便开发者自己控制部分中间件的接入 上图描述了 rest 处理请求的模式和大部分处理路径。 框架内置的中间件已经帮开发者解决了大部分服务自处理的逻辑 同时 go-zero 在 business logic 处也给予开发者开箱即用的组件(dq、fx 等) 从开发模式上帮助开发者只需要关注自己的 business logic 以及所需资源准备 下面我们来细说一下整个 rest 是如何启动的? 启动流程 上图描述了整体 server 启动经过的模块和大致流程。准备按照如下流程分析 rest 实现: 基于 http.server 封装以及改造:把 engine(web框架核心) 和 option 隔离开 多路由匹配采取 radix-tree 构造 中间件采用洋葱模型 → []Middleware http parse 解析以及匹配校验 → httpx.Parse() 在请求过程会收集指标 (createMetrics()) 以及监控埋点 (prometheus) server engine封装 > 点开大图观看 engine 贯穿整个 server 生命周期中: router 会携带开发者定义的 path/handler,会在最后的 router.handle() 执行 注册的自定义中间件 + 框架中间件,在 router handler logic 前执行 在这里:go-zero 处理的粒度在 route 上,封装和处理都在 route 一层层执行 路由匹配 那么当 request 到来,首先是如何到路由这一层的? 首先在开发最原始的 http server ,都有这么一段代码: type helloHandler struct{} func (h *helloHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) { w.Write([]byte("Hello, world!")) } func main() { http.Handle("/", &helloHandler{}) http.ListenAndServe(":12345", nil) } http.ListenAndServe() 内部会执行到:server.ListenAndServe() 我们看看在 rest 里面是怎么运用的: 而传入的 handler 其实就是:router.NewRouter() 生成的 router。这个 router 承载了整个 server 的处理函数集合。 同时 http.Server 结构在初始化时,是把 handler 注入到里面的: type Server struct { ... Handler Handler } func start(..., handler http.Handler, run func(srv *http.Server) error) (err error) { server := &http.Server{ Addr: fmt.Sprintf("%s:%d", host, port), Handler: handler, } ... return run(server) } 在 http.Server 接收 req 后,最终执行的也是:handler.ServeHTTP(rw, req) 所以内置的 router 也需要实现 ServeHTTP 。至于 router 自己是怎么实现 ServeHTTP :无外乎就是寻找匹配路由,然后执行路由对应的 handle logic。 解析参数 解析参数是 http 框架需要提供的基本能力。在 goctl code gen 生成的代码中,handler 层已经集成了 req argument parse 函数: // generate by goctl func QueryAllTaskHandler(ctx *svc.ServiceContext) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { // custom request in .api file var req types.QueryAllTaskRequest // parse http request if err := httpx.Parse(r, &req); err != nil { httpx.Error(w, err) return } l := logic.NewEventLogic(r.Context(), ctx) resp, err := l.QueryAllTask(req) baseresponse.FormatResponseWithRequest(resp, err, w, r) } } 进入到 httpx.Parse() ,主要解析以下几块: > https://github.com/zeromicro/go-zero/blob/master/rest/httpx/requests.go#L32:6 解析path 解析form表单 解析http header 解析json > Parse() 中的 参数校验 的功能见: > > https://go-zero.dev/cn/api-grammar.html 中的 tag修饰符 Tips 学习源码推荐 fork 出来边看边写注释和心得,可以加深理解,以后用到这块功能的时候也可以回头翻阅。 项目地址 https://github.com/zeromicro/go-zero https://gitee.com/kevwan/go-zero 欢迎使用 go-zero 并 star 支持我们! 微信交流群 关注『微服务实践』公众号并点击 交流群 获取社区群二维码。

优秀的个人博客,低调大师

基于token的多平台身份认证架构设计

1概述 在存在账号体系的信息系统中,对身份的鉴定是非常重要的事情。 随着移动互联网时代到来,客户端的类型越来越多, 逐渐出现了一个服务器,N个客户端的格局。 不同的客户端产生了不同的用户使用场景,这些场景: 有不同的环境安全威胁 不同的会话生存周期 不同的用户权限控制体系 不同级别的接口调用方式 综上所述,它们的身份认证方式也存在一定的区别。 本文将使用一定的篇幅对这些场景进行一些分析和梳理工作。 2使用场景 下面是一些在IT服务常见的一些使用场景: 用户在web浏览器端登录系统,使用系统服务 用户在手机端(Android/iOS)登录系统,使用系统服务 用户使用开放接口登录系统,调用系统服务 用户在PC处理登录状态时通过手机扫码授权手机登录(使用得比较少) 用户在手机处理登录状态进通过手机扫码授权PC进行登录(比较常见) 通过对场景的细分,得到如下不同的认证token类别: 原始账号密码类别 用户名和密码 API应用ID/KEY 会话ID类别 浏览器端token 移动端token API应用token 接口调用类别 接口访问token 身份授权类别 PC和移动端相互授权的token 3token的类别 不同场景的token进行如下几个维度的对比: 天然属性对比: 使用成本 本认证方式在使用的时候,造成的不便性。比如: 账号密码需要用户打开页面然后逐个键入 二维码需要用户掏出手机进行扫码操作 变化成本 本认证方式,token发生变化时,用户需要做出的相应更改的成本: 用户名和密码发生变化时,用户需要额外记忆和重新键入新密码 API应用ID/KEY发生变化时,第三方应用需要重新在代码中修改并部署 授权二维码发生变化时,需要用户重新打开手机应用进行扫码 环境风险 被偷窥的风险 被抓包的风险 被伪造的风险 可调控属性对比: 使用频率 在网路中传送的频率 有效时间 此token从创建到终结的生存时间 最终的目标:安全和影响。 安全和隐私性主要体现在: token 不容易被窃取和盗用(通过对传送频率控制) token 即使被窃取,产生的影响也是可控的(通过对有效时间控制) 关于隐私及隐私破坏后的后果,有如下的基本结论: 曝光频率高的容易被截获 生存周期长的在被截获后产生的影响更严重和深远 遵守如下原则: 变化成本高的token不要轻易变化 不轻易变化的token要减少曝光频率(网络传输次数) 曝光频率高的token的生存周期要尽量短 将各类token的固有特点及可控属性进行调控后,对每个指标进行量化评分(1~5分),我们可以得到如下的对比表: 备注: user_name/passwd和app_id/app_key是等价的效果 4token的层级关系 参考上一节的对比表,可以很容易对这些不同用途的token进行分层,主要可以分为4层: 密码层 最传统的用户和系统之间约定的数字身份认证方式 会话层 用户登录后的会话生命周期的会话认证 调用层 用户在会话期间对应用程序接口的调用认证 应用层 用户获取了接口访问调用权限后的一些场景或者身份认证应用 token的分层图如下: 在一个多客户端的信息系统里面,这些token的产生及应用的内在联系如下: 用户输入用户名和用户口令进行一次性认证 在不同的终端里面生成拥有不同生命周期的会话token 客户端会话token从服务端交换生命周期短但曝光频繁的接口访问token 会话token可以生成和刷新延长access_token的生存时间 access_token可以生成生存周期最短的用于授权的二维码的token 使用如上的架构有如下的好处: 良好的统一性。可以解决不同平台上认证token的生存周期的归一化问题 良好的解耦性。核心接口调用服务器的认证 access_token 可以完成独立的实现和部署 良好的层次性。不同平台的可以有完全不同的用户权限控制系统,这个控制可以在会话层中各平台解决掉 4.1账号密码 广义的账号/密码有如下的呈现方式: 传统的注册用户名和密码 应用程序的app_id/app_key 它们的特点如下: 会有特别的意义 比如:用户自己为了方便记忆,会设置有一定含义的账号和密码。 不常修改 账号密码对用户有特别含义,一般没有特殊情况不会愿意修改。 而app_id/app_key则会写在应用程序中,修改会意味着重新发布上线的成本 一旦泄露影响深远 正因为不常修改,只要泄露了基本相当于用户的网络身份被泄露,而且只要没被察觉这种身份盗用就会一直存在 所以在认证系统中应该尽量减少传输的机会,避免泄露。 4.2客户端会话token 功能:充当着session的角色,不同的客户端有不同的生命周期。 使用步骤: 用户使用账号密码,换取会话token 不同的平台的token有不同的特点。 Web平台生存周期短 主要原因: 环境安全性 由于web登录环境一般很可能是公共环境,被他人盗取的风险值较大 输入便捷性 在PC上使用键盘输入会比较便捷 移动端生存周期长 主要原因: 环境安全性 移动端平台是个人用户极其私密的平台,它人接触的机会不大 输入便捷性 在移动端上使用手指在小屏幕上触摸输入体验差,输入成本高 4.3access_token 功能:服务端应用程序api接口访问和调用的凭证。 使用步骤: 使用具有较长生命周期的会话token来换取此接口访问token。 其曝光频率直接和接口调用频率有关,属于高频使用的凭证。 为了照顾到隐私性,尽量减少其生命周期,即使被截取了,也不至于产生严重的后果。 注意:在客户端token之下还加上一个access_token, 主要是为了让具有不同生命周期的客户端token最后在调用api的时候, 能够具有统一的认证方式。 4.4pam_token 功能:由已经登录和认证的PC端生成的二维码的原始串号(Pc Auth Mobile)。 主要步骤如下: PC上用户已经完成认证,登录了系统 PC端生成一组和此用户相关联的pam_token PC端将此pam_token的使用链接生成二维码 移动端扫码后,请求服务器,并和用户信息关联 移动端获取refresh_token(长时效的会话) 根据 refresh_token 获取 access_token 完成正常的接口调用工作 备注: 生存周期为2分钟,2分钟后过期删除 没有被使用时,每1分钟变一次 被使用后,立刻删除掉 此种认证模式一般不会被使用到 4.5map_token 功能:由已经登录的移动app来扫码认证PC端系统,并完成PC端系统的登录(Mobile Auth Pc)。 主要步骤: 移动端完成用户身份的认证登录app 未登录的PC生成匿名的map_token 移动端扫码后在db中生成map_token和用户关联(完成签名) db同时针对此用户生成web_token PC端一直以map_token为参数查找此命名用户的web_token PC端根据web_token去获取access_token 后续正常的调用接口调用工作 备注: 生存周期为2分钟,2分钟后过期删除 没有被使用时,每1分钟变一次 被使用后,立刻删除掉 5小结与展望 本文所设计的基于token的身份认证系统,主要解决了如下的问题: token的分类问题 token的隐私性参数设置问题 token的使用场景问题 不同生命周期的token分层转化关系 本文中提到的设计方法,在应用层中可以适用于且不限于如下场景中: 用户登录 有时效的优惠券发放 有时效的邀请码发放 有时效的二维码授权 具有时效手机/邮件验证码 多个不同平台调用同一套API接口 多个平台使用同一个身份认证中心 至于更多的使用场景,就需要大家去发掘了。 关于如何在技术上实现不同token的生存周期问题,将在后续文章中进行介绍,敬请期待。 补充内容:关于具备生命周期的token的技术实现方式 1 http://www.cnblogs.com/beer/p/6030882.html

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册