Termux是一个Android下一个高级的终端模拟器,开源且不须要root,支持apt管理软件包，十分方便安装软件包,完美支持Python,PHP,Ruby,Go,Nodejs,MySQL等。随着智能设备的普及和性能的不断提高，现在的手机、平板等的硬件标准已达到了初级桌面计算机的硬件标准,用心去打造彻底能够把手机变成一个强大的工具.node

显示菜单项（包括复制、粘贴、更多），此时屏幕出现可选择的复制光标mysql

显示隐藏式导航栏，能够新建、切换、重命名会话session和调用弹出输入法nginx

扩展功能键是什么?就是PC端经常使用的按键如:ESC键，CTR键，TAB键,可是手机上难以操做的一些按键.git

从左向右滑动,显示隐藏式导航栏,长按左下角的KEYBOARD.web

Ctrl键是终端用户经常使用的按键 - 但大多数触摸键盘都没有这个按键。为此，Termux使用音量减少按钮来模拟Ctrl键。
例如，在触摸键盘上按音量减少+ L发送与在硬件键盘上按Ctrl + L相同的输入。

音量加键也能够做为产生特定输入的特殊键.

Termux除了支持apt命令外,还在此基础上封装了pkg命令,pkg命令向下兼容apt命令.apt命令你们应该都比较熟悉了,这里直接简单的介绍下pkg命令:

上面是官方推荐的方法,其实还有更简单的方法,相似于Linux下直接去编辑源文件:

若是你不嫌无聊的话还能够扫描这个二维码,而后就打开个人博客了.

一个基于nodejs编写的命令行下的地图.

终端下的地图!讲究人~ 若是你足够无聊的话,还能够尝试能不能在这个地图上找到本身所在的位置.

甚至还能够在Termux里面在安装其余的Linux发行版.

因为本文篇幅已通过长了,这里不在叙述了,感兴趣,能折腾的本身去找一些资料.下面列出目前网友们用Termux能够成功安装的发行版:

使用ngrok或者frp能够将Termux上面搭建的网站映射到外网上去,手机建站也不是不可能了.

Jupyter notebook（又称IPython notebook），支持运行超过40种编程语言。Python的一个强大的模块,成功安装的话能够实现比caddy的效果,支持web下的终端操做,支持代码高亮运行.因为这里须要安装大量文件,加上用户需求比较少,这一块感兴趣的话能够本身去探索.

是一款命令行工具，用来下载网页中的视频、音频、图片，支持众多网站，包含 41 家国内主流视频、音乐网站，如 网易云音乐、AB
站、百度贴吧、斗鱼、熊猫、爱奇艺、凤凰视频、酷狗音乐、乐视、荔枝FM、秒拍、腾讯视频、优酷土豆、央视网、芒果TV
等等，只需一个命令就能直接下载视频、音频以及图片回来，而且能够自动合并视频。而对于有弹幕的网站，好比 B 站，还能够将弹幕下载回来

仿 Linux shell 文件处理命令的百度网盘命令行客户端.

能够完美在Termux上运行.

相对来讲 国外的Termux DIY的氛围比国内好不少,Youtube上的视频都有很高的播放量:

还记得之前在面试的时候，有一位面试官就问了，关于前端鉴权这块，Token、Cookie、Session、JWT、单点登录是什么？有什么作用？你一般是怎么做的？以及你是怎么存储的呢？那你又是怎么保证它的安全的呢？

一顿连问下来，我是焦头又烂额，欲言而又止.......

其实鉴权的方法有很多，下面我总结了常用的10种鉴权方法，那么哪一种是最适合你的系统呢？哪一种又最安全呢？

那就让我们从下文慢慢探索寻找答案吧 ~

通过这篇文章你将学到什么？

在介绍鉴权方法之前，我们先要了解的是：什么是认证、授权、鉴权、权限控制以及他们之间的关系，有了他们做铺垫，那么我们才能做到从始至终的了解透彻 ~

认证(Identification)是指根据声明者所特有的识别信息，确认声明者的身份。

白话文的意思就是：你需要用身份证证明你自己是你自己。

比如我们常见的认证技术：

• 用户手机：手机短信、手机二维码扫描、手势密码

• 用户的生物学特征：指纹、语音、眼睛虹膜

授权(Authorization)：在信息安全领域是指资源所有者委派执行者，赋予执行者指定范围的资源操作权限，以便对资源的相关操作。

在现实生活领域例如：银行卡（由银行派发）、门禁卡（由物业管理处派发）、钥匙（由房东派发），这些都是现实生活中授权的实现方式。

在互联网领域例如：web 服务器的 session 机制、web 浏览器的 cookie 机制、颁发授权令牌（token）等都是一个授权的机制。

鉴权(Authentication)在信息安全领域是指对于一个声明者所声明的身份权利，对其所声明的真实性进行鉴别确认的过程。

若从授权出发，则会更加容易理解鉴权。授权和鉴权是两个上下游相匹配的关系，先授权，后鉴权。

在现实生活领域：门禁卡需要通过门禁卡识别器，银行卡需要通过银行卡识别器；

鉴权是一个承上启下的一个环节，上游它接受授权的输出，校验其真实性后，然后获取权限（permission），这个将会为下一步的权限控制做好准备。

权限控制(Access/Permission Control)将可执行的操作定义为权限列表，然后判断操作是否允许/禁止

对于权限控制，可以分为两部分进行理解：一个是权限，另一个是控制。权限是抽象的逻辑概念，而控制是具体的实现方式。

在现实生活领域中：以门禁卡的权限实现为例，一个门禁卡，拥有开公司所有的门的权限；一个门禁卡，拥有管理员角色的权限，因而可以开公司所有的门。

在互联网领域：通过 web 后端服务，来控制接口访问，允许或拒绝访问请求。

认证、授权、鉴权和权限控制的关系？

看到这里，我们应该明白了认证、授权、鉴权和权限控制这四个环节是一个前后依次发生、上下游的关系;

需要说明的是，这四个环节在有些时候会同时发生。例如在下面的几个场景：

• 使用门禁卡开门：认证、授权、鉴权、权限控制四个环节一气呵成，在瞬间同时发生

• 用户的网站登录：用户在使用用户名和密码进行登录时，认证和授权两个环节一同完成，而鉴权和权限控制则发生在后续的请求访问中，比如在选购物品或支付时。

这里提个小问题，供大家思考：认证和鉴权之间的关系？欢迎大家在评论区讨论

既然我们已经了解了他们之间的关系，那么我们应该好好讲讲关于前端鉴权有哪些？以及他们之间存在的差异点又在哪里呢？

• 服务器：客户端你好，这个资源在安全区 ”要求进行身份验证；

• 客户端：服务器，我已经携带了用户名和密码给你了，你看一下；（注：如客户端是浏览器，那么此时会自动弹出一个弹窗，让用户输入用户名和密码）；

  输入完用户名和密码后，则客户端将用户名及密码以 Base64 加密方式发送给服务器

  传送的格式如下 (其中 Basic 内容为：用户名:密码 的 ase64 形式)：

  1. 客户端：用户访问某个子系统时（例如），如果没有登录，则跳转至 SSO 认证中心提供的登录页面进行登录；

  2. 服务端：登录认证后，服务端把登录用户的信息存储于 Session 中，并且附加在响应头的Set-Cookie字段中，设置 Cookie 的 Domain 为.) 和 淘宝 (），同时 URL 地址参数携带登录成功后回跳到系统 A 的页面链接（%EF%BC%89%EF%BC%9B）

  3. CAS 认证服务：发现请求 Cookie 中没有携带登录的票据凭证（TGC），所以 CAS 认证服务判定用户处于未登录状态，重定向用户页面至 CAS 的登录界面，用户在 CAS 的登录页面上进行登录操作。

  4. 客户端：输入用户名密码进行 CAS 系统认证；

  5. 系统 A：拿着 ST 向 CAS 认证服务发送请求，CAS 认证服务验证票据 (ST) 的有效性。验证成功后，系统 A 知道用户已经在 CAS 登录了（其中的 ST 可以保存到 Cookie 或者本地中），系统 A 服务器使用该票据 (ST) 创建与用户的会话，称为局部会话，返回受保护资源；

  到这里客户端就可以跟系统 A 愉快的交往啦 ~

  上面 URL 中，response_type参数表示要求返回授权码（code），client_id参数让 B 知道是谁在请求，redirect_uri参数是 B 接受或拒绝请求后的跳转网址，scope参数表示要求的授权范围（这里是只读）

  
  

• 授权服务网站会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时授权服务网站就会跳回redirect_uri参数指定的网址。跳转时，会传回一个授权码，就像下面这样。

  )请求令牌，请求地址如下：

• 用户跳转到授权服务器，登录后同意给予 A 网站授权。这时，授权服务器就会跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站。

  )的用户名和密码。拿到以后，A 就直接向授权服务器请求令牌。

• 授权服务器验证身份通过后，直接给出令牌。

  注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 网站因此拿到令牌。

这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。

• 授权服务器验证通过以后，直接返回令牌。

注意：这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。

) 或者某个 APP (如微信) 的扫码登录入口；就会携带 PC 端的设备信息向服务端发送一个获取二维码的请求；

• 服务器收到请求后，随机生成一个 UUID 作为二维码 ID，并将 UUID 与PC 端的设备信息关联起来存储在 Redis 服务器中，然后返回给 PC 端；同时设置一个过期时间，在过期后，用户登录二维码需要进行刷新重新获取。

• 收到二维码 ID 之后，将二维码 ID 以二维码的形式展示，等待移动端扫码。并且此时的 PC 端开始轮询查询二维码状态，直到登录成功。

  如果移动端未扫描，那么一段时间后二维码会自动失效。

1. 打开手机端对应已登录的 APP (微信或淘宝等)，开始扫描识别 PC 端展示的二维码；

   移动端扫描二维码后，会自动获取到二维码 ID，并将移动端登录的信息凭证（Token）和二维码 ID 作为参数发送给服务端，此时手机必须是已登录（使用扫描登录的前提是移动端的应用为已登录状态，这样才可以共享登录态）。

2. 收到手机端发来的请求后，会将Token 与二维码 ID关联，为什么需要关联呢？因为，当我们在使用微信时，移动端退出时，PC 端也应该随之退出登录，这个关联就起到这个作用。然后会生成一个临时 Token，这个 Token 会返回给移动端，一次性 Token 用作确认时的凭证。

1. 收到确认信息后，点击确认按钮，移动端携带上一步中获取的临时 Token发送给服务端校验；

2. 服务端校验完成后，会更新二维码状态，并且给 PC 端生成一个正式的 Token，后续 PC 端就是持有这个 Token 访问服务端。

3. 轮询到二维码状态为已登录状态，并且会获取到了生成的 Token，完成登录，后续访问都基于 Token 完成。

本公众号部分分享的资料来自网络收集和整理，所有文字和图片版权归属于原作者所有，且仅代表作者个人观点，与本公众号无关，文章仅供读者学习交流使用，并请自行核实相关内容，如文章内容涉及侵权，请联系后台管理员删除。

高并发架构都要考虑哪些方面？

架构师从0搭建一套订单系统！

超融合架构与云、传统架构对比

总结如何画一手好的架构图