资源权限管理
这里所描述的资源管理是指API管理,或者接口管理。最初的目是实现一个基于角色权限的细粒度访问控制,同时具备自上而下与自下而上的两种配置与管理方式。
在实际的权限管理中,受特别是后端的权限管理有非常大的不透明性。除了开发者本身,在接口这个粒度上几乎没有人能完全知道系统中,甚至功能点中到底有哪些接口。所以更实际的方式是采用白名单管理,不做配置就没有权限。这种基于白名单或者黑名单的管理方式我称作为自上而下的权限管理。这种方式的缺点就是基于人工的有限配置带来的规模限制与精确控制的限制。
TL;DR点击列表跳转
资源与权限
认证管理
登录认证
访问认证
菜单管理
前端资源展示
资源控制
资源管理
接口扫描
元数据管理
接口控制
授权管理
接口数量
实际使用
最后
1、资源与权限资源权限的分类
对于当前流行的前后端分离系统来说实际上权限管理可以粗略的分别为,前端权限管理与后端权限管理。
前端权限管理:前端的权限管理可以理解为UI的权限控制,即能看到什么与能操作什么,也就是菜单和按钮。
后端权限管理:后端权限从不同维度有着不同的划分,但是仅从对外使用上可以简单的认为是接口 ...
我的2021
春节假期下了几天雨,体感又潮湿又阴冷。无意间在图片收藏里看到这张。
在2022年新年伊始回想起2021年的经历,发现竟然没有什么值得关注的事情。整个2021年基本在埋头工作,这其中有不少内容是在对之前期望和目标以及一些执行方法的实践。就如同最近看到一本关于知识管理的书里面说的3W理论,即先问why(为什么),接下来how(如何),最后才是what(什么)。在现实中大多是直接what,直接得出结论。这也许是当今这个知识与内容高度泛滥的年代我们被迫养成的习惯,快速得出一个结论并快速执行。就好像看到电商网站不厌其烦给推送商品,我们要做的就是立刻决定买还是不买,很多时候甚至忽略了购物的本质。而现在的网络环境又有非常明显的自动归类与转借概念的现象出现,大多数时候我们只是在一个给定的范围内选择,在范围之外又出现大量的新生概念与转借的“名词”。这样层层间隔让人将很多行为自动归类到一些概念上去,这样进一步加速自我思考与行为的自动归类。加剧了不经思考被各类概念裹挟的被动选择,再加上社会分工越来越精细,接触的信息越来越固定化,想要遇事多思考摆脱信息茧房越来越困难。
翻了下整个2021年的观影记录,发 ...
低代码随笔
低代码这个概念不知道是什么时候出现的,不过在我印象中类似的说法似乎已经有很久的历史。
对我来说真正开始思考是在大概三年前开发一款相对复杂的流程审批系统开始的,当时需要设计在一个较大的组织架构中多角色与用户的流程审批功能。在最终选择使用activiti6做底层实现后开始了符合实际业务场景的改造,这主要包括流程设计器对接外部的角色与用户系统,流程设计器的节点对接外部接口调用(比如通知),流程跳转节点与内置表单组合后支持表达式的判断。而后端代码增加了动态的节点权限赋值,任意节点取消,运行中的流程图修改,主业务异常后的流程数据补偿等。
等上线后发现实际业务和流程有非常强的耦合。业务上线是先各方面定下一个业务流程,有些流程可能非常长非常多的审批人员,或是复杂的节点逻辑。随后前后端开发人员实现,并按照业务绘制流程图,发布流程图,业务上线后在配置中选择与最新的流程图编码(编码一致,版本可升级)绑定。运行一段时间后我发现业务流程虽然支持绘制流程图进行版本升级,进而变更流程执行逻辑,但是实际这样用的场景非常少,因为流程的变更需要具体业务代码的支持。而很多业务模块在设计中有非常强的上下文依赖关系,无论是 ...
个人数据存储
个人数据的问题自从进入互联网时代几乎成了困扰每个人的问题。
当时刚工作的时候几乎对任何事物都存在非常强烈的好奇,想把接触到的一切东西都存起来。存的东西非常的杂乱,比如各种漫画,番剧,剧集,电影以及各种大量的二次作品,当然还有一个最主要的原因是网络环境非常的糟糕,也就是所谓的“小水管”,在线看视频都要缓冲好久,下载资源即便是迅雷也是常年几十KB(当然这不排除是资源本身就非常偏门)。相对的在线观看最多的还是看二次创作的作品,影视作品更多的还是下载之后再看。
另外当时流行论坛文化,各类专门论坛,比如编程,工具什么的。我记得当时比较常去的如C语言和操作系统相关的论坛,也记得当时U盘自动运行引起大规模病毒传播时尝试使用批处理文件做一些清理工作,以及之后“熊猫烧香”爆发的时候各处求助的情况。视频类的各大字幕组论坛也是各类爱好者的最佳交流场所,大家在工作与学习之余聊着CV,制作公司,萌战等,非常快乐。那时候收集也是一种乐趣。
TL;DR点击列表跳转
本地硬盘时代
1.1 寻觅之旅
1.2 网盘时代
1.3 多媒体存储的意义
本地网络
2.1 NAS
服务端
最后
1. 本地硬盘时代 ...
我的2020
2020年现在回忆起来从各个方面来说都是不平凡的一年,这年改变了我之前心里最大的关于未来的不确定预期。
从19年开始显得尤为明显的是整个互联网行业伴随着整体经济的增长速度放缓,各个细分领域的业务增长红利都渐渐失去。表现出来就是整体投资变少了,之前红红火火的创业仿佛突然没有了,大部分小型的创业公司都难以熬过一到两年。社交媒体上也弥漫着各类业务萎缩,员工福利与薪资的各种抱怨,以及某些行业大佬宣扬的今年是以往最差的一年,也是未来最好的一年。
作为一个互联网相关从业者,从七八年前亲眼看到移动互联网带动下的这一轮经济飞速发展,即便到了现在一般的民众也基本会认为互联网带来的便利依旧在持续着。但是做为一个开发者个人在四年前从移动互联网相关需求进入平稳期,甚至是饱和的时候,已经明显的感觉到行业野蛮成长的时期已经过去了。到了19年一些细分领域似乎在不为人知的快速发展,但是在整体大环境不容乐观的前提下,更多的对未来抱有不确定预期的人显得格外焦虑。
在19年几乎所有人都在想未来会有多差,下一个增长点在哪里的时候,谁也没有想到2020年突发的全球性质的黑天鹅事件,彻底的改变了世界发展的轨迹,也必然的打乱 ...
一九年七月番扫番报告
不知道从什么时候开始对现在每个季度的新番开始渐渐失去兴趣了(和上图没关系)。
回想起来最近追番感觉非常不错的是19年的1月,那时候的《灵能百分百》、《玛娜利亚》和《烟草》真正的让我非常期待下一周的到来。即便是回来补的《天使降临我身边》和《荒野的寿飞行队》都给我带来的非常好的观感。另外《飞行队》比较奇妙,我暂时把它归为军武题材。虽然表现形式上非常不错,但是似乎这感觉总不是很对的样子…
随后到来四月本来最期待的《Carole&Tuesday》和《皿三昧》也由于各种原因没有追下来,再加上《水果篮子》以及《鬼灭》刚开始给我不好的观感,其实四月我似乎都没有追什么新番的样子,就这样一直到来七月。而七月随便看了看《埃尔梅罗二世》以及《一方》就这样来到了八月。
刚开始的转机似乎是天气渐渐的热起来让我想起去年的这个时候。我一般周末早上洗衣服并在这个过程中扫一下这周的视频,其实主要就是新番。七月就是按照《一方》和《二世》的顺序,晾衣服的时候随着每周阳光越来越刺眼心情越来越好,直到阳光强烈到散射的撒到显示器上,我突然想起了原来是这样,和去年一样。
去年的夏天给我的印象是那么的长,天气是那么的晴 ...
一次数据丢失的经历
![Time Capsule](/resources/2018/mac-data-loss-time-capsule.jpg)
Time Capsule
一、我的水果笔记本2014年入了当年的新Mac,记得这貌似是难得的屏幕下面没有印制文字的版本。用了4四年到了2018年几乎也没有出现什么问题,所以每次看到设置项中的时间机器选项虽然觉得非常必要,但是也没有真正想过来一次备份。说道Mac的好处其实有很大一部分是水果全家桶的功劳,Mac也同样的有非常高的一致性,虽然这点没有iOS来的高。对于开发者来说其固态硬盘和Unix环境真的是让人很难拒绝,而我还有自己的需求那就是文字。
说真的我第一次在益田的水果店看到Mac屏幕的时候真的给我很大的冲击,虽然一开始键位并不是很舒服但是那种打字的感觉和字体渲染效果让我非常着迷。之后我的大部分文字工作都在Mac上完成,包括了很多很多内容。
二、数据损坏七月的某一天紧张工作中,我终于遇到了传说中的机器进水事件。当时我还认为Mac本进水擦擦就好了,但是我在拿风扇吹机器的时候拿手机查了一下突然意识到问题的严重性。但是我脑海中一闪而过的是我有大量的文章还 ...
聊一聊Spring - 开篇
一、前言Spring这一技术栈发展到现在从某种程度上说是非常不可思议了,这最重要的是Spring随时代的变化而变化。在服务隔离、微服务与前后端分离等大行其道的今天,Spring衍生出的Spring-boot成为Java后端开发的首选,让Java这种“沉重”的语言一下子“轻盈”了起来。仿佛也如同node.js和python一样快速的搭建出开发环境或Demo一样。而这其中Spring boot提供的基于注解的开发方式几乎不依赖各类配置文件的方式,让大部分开发人员摆脱了繁杂的XML配置文件。
但是就行我之前说过的那样一旦一项技术过于工程化,那么这个行业的从业人员可能就面临比较严峻的形式。因为这时已经不需要太多的专业技术人员,需要的更多是“操作员”和“执行者”。伴随着Spring boot在Java后端大行其道,即便是现在企业项目在选型和做技术架构的时候也开始向微服务方向靠拢。而拥有Spring Cloud方案的Spring boot技术栈其实在事实上已经成为了首选,特别是那些刚刚从传统SSH/SSM项目转型出来的开发团队。
在接触了不少传统企业级应用开发者和一些新接触这一技术 ...
微信小程序从入门到重新入门
由于最近参与项目的缘故,需要了解一下微信小程序的整个开发与上架流程,于是去看了几天官方文档之后决定从零开始写一个小程序。
微信小程序完全是依托于微信平台才能发展到如此规模。与微信小程序相似的业务其实在之前不知道涌现出多少,所以当微信公布要做小程序时几乎所有人都不看好,而经过多年的迭代开发现在微信小程序在加上微信小游戏,已经开始渐渐深入大众日常。而这其普通人最为熟悉的应该是各类商城与点餐小程序,并且可以看出这类小程序已经形成一定的平台规模。
目录
现状
上手
准备工作
架构
后端
自己搭建
腾讯云小程序方案
小程序
入门
重新入门
最后
一、现状
从个人入门现状来看,微信小程序本身限制很多,并且其表现效果并不尽如人意(关于这点在重新入门章节再做说明)。但是目前的现状是小程序日活1.7亿,月活4.3亿参与开发者100多万,乐观预测18年小程序总量将超过120万,从数量上超越AppStore应用总和。同时小程序用户日均使用时长7.5分钟,用户在使用微信是有1/12的时间在使用小程序。
值得注意的是小程序本身的定位正在发生变化。从微信公众号关联小程序开始,又到微 ...
一种会话本地头像生成器
v1.0 1st Edition
这篇文章介绍一种会话头像的本地生成方式,主要的应用场景是类似IM(即时通信)会话列表。在实际开发中头像的生成依赖多个功能模块,这里也进行简单的设计方面介绍,如果对这方面有经验的朋友可直接跳转到TL;DR(太长不看),也可以直接从下面的列表跳转到本文的主题。
在正文开始之前首先阐述一下开发与设计层面的一些思想。
对客观事物的抽象与实现向来都是范围上由大到小,认知上由抽象到具体。
对程序设计来说,万万不能从细节着手拼凑出整体结构。实现不论复杂与否必须在设计上保持形式的简洁,以及细节的优雅,形式的简洁是一切的前提,细节的优雅则可以通过迭代与重构慢慢追求。
TL;DR 请点击列表跳转
前言
依赖
用户缓存
图像请求框架
图像生成
组合图像
绘制圆形
画布剪切
最后
前言之前参与一个项目为其中添加一个即时通信功能,并且此功能是以插件的方式提供,即SDK。考虑到此功能复杂度较高,并且从设计角度来看其功能边界与主程序和各种第三方功能存在一定的覆盖,所以从一开始就尽量考虑到从集成到后续开发,以及使用上的诸多问题。这些问题如果随后有时间专门另起文章进行说 ...