0X00 前言

上周在新公司接到的一个任务”给 XXX 系统集成 LDAP 登录”。我以前是没有了解过 LDAP 的，一听是集成登录功能，脑子里第一时间想到的就是之前做过的 SSO，但是经过一番搜索发现 LDAP 和 SSO 完全是两回事，而且发现还是不少人不了解其中的一项或两项技术，正好在这儿整理一下顺便分享给大家~

内容都是比较基础的，主要介绍了什么是 SSO、SSO 的基本原理、什么是 LDAP、LDAP 的基本原理和 LDAP 如何与 SSO 关联。如果你对这些有兴趣那不妨继续看下去，如果你都了解了那就去看看其他文章或者休息一会儿好了~

现在开始做一些技术背景预设：假设你公司有 10 个站点，分别是site_0.just666.com/site_1.just666.com.....，同时每个站点都有用户系统，也就是说用户可以登录到站点上去做些操作。

用户肯定不愿意访问每个站点的时候都要登录，比如你登陆淘宝之后再看天猫肯定不想再登陆一次了，如果天猫要你再登陆一次且密码还跟淘宝那边不通你肯定要骂人了。现在怎么办呢？SSO 和 LDAP 两种技术就是用来解决这个问题的。

0X00 前言

都说“生活需要仪式感“，那对我来说的第一次跳槽还是值得记录的，用处肯定是没什么，但是总归是给自己一点点生活上的仪式感吧。而且脑子记住的东西可能过几年就忘记了，真正记录成文字的东西存活时间就会长久很多。（记录在网络上就算我自己把博客删了，都还会有垃圾站原封不动的抄走，简直不可能丢🤣）

本来说离职当天就来写这篇文章的，结果当天晚上同时请客去吃饭又去唱了歌，回家都凌晨两点了，隧作罢。现在离职手续全部都办好了，新公司的文件们也都准备好了，就等假期过后直接到新公司入职。所以也终于有时间坐下来不用考虑工作相关的任何事情来写一写自己的想法了～

这不是日记，按蓝青峰跟朱潜龙的说法正经人谁写日记啊🤪（狗头）

0X01 为什么离开

从我以实习生的身份加入创宇到最后离开一共是 1159 天，算下来是三年多一点点，时间也算是很久的了。毕竟我大学也就只有前三年是在学校的，后面就出来实习了。现在走呢也不是说因为公司有啥问题或者我被开除了，只是说我自己觉得是时候出去看看了，不想常年在一家公司里待下去

这次跳槽主要是这三个问题导致的：

1. 💰️首先是“工资问题“；大家出来工作，99.99%的人都得是为了赚钱吧。我因为是实习转正的，所以薪资起点会比较低，即使后来的调薪比例都还挺高的也会导致最后的薪资并没有怎么多；所以说自己也想要换个地方拿到更高的薪资，要恰饭的嘛；

2. 👨‍💻其次是“专业技能“；开发者嘛，想要自我提升的人还是很多的。但是因为我做的事情是针对少数人使用的内部系统，所以对个人的技术力需求和考验并没有什么。在工作中不太能接触到更高的东西和更宽的东西，自己私下时间学习到的更高更宽的知识又比较难应用起来。虽然在舒适圈是真的舒适，但是想要提升的话总有一天要打破舒适圈的，我觉得这一天该到了；

3. 👀️最后是“眼界和见识“；我个人觉得我已经在同一个岗位做同一个业务时间够久了，也想要见到其他不同的行业和人们。

所以总结下来，就是说目前我：使用“Python“编写“Django“程序，然后运行在内网环境里，给“内部审核系统“提供稳定可靠的“web 服务“，每个月赚到“**“的工资。现在双引号里所有的东西我觉得都是时候可以改变的，对于技术栈来说的“T 型人才“的横和竖都是可以发展的了；对于工资来说就更是了，起薪低的情况下很难有大额上涨的，所以跳槽也是一个大家都理解的操作。

0X00 What’s this

我们知道 MySQL 中存在“事务”这么个事物（我是故意拗口的，哈哈哈哈哈哈哈）；我们也知道事务“一荣俱荣，一损俱损”（要么事物内所有查询均生效，要么均不生效）。那么现在问题来了，银行数据库中有两个事务在同时进行，我们来看一下这两个事务

一条 SQL 就是一个查询，不一定是 SELECT xxx 才叫查询。

1
2
3
4
5
6
7
8
9
10
11

-- 事务 A    shawn 转账给 bluce 100 块钱
BEGIN;
UPDATE account SET money = money - 100 WHERE username = 'shawn';    -- 这行代码标记为  A-1
UPDATE account SET money = money + 100 WHERE username = 'bluce';     -- 这行代码标记为  A-2
COMMIT;

-- 事务 B
BEGIN;
SELECT money FROM account WHERE username = 'shawn';    -- 这行代码标记为 B-1
SELECT money FROM account WHERE username = 'bluce';     -- 这行代码标记为 B-2
COMMIT;

现在有这么一个情况：shawn 和 bluce 两人账上都有 100 块钱，此时事务 A 和 B 同时开始执行，那么事务 B 所查询到的两人的账户余额究竟是多少呢？这个问题并没有一个确切的结果，因为 B 在查询的时候，转账正在进行中。不过要回答这个问题也不是做不到，就需要引入标题中提到的“隔离等级”这个概念了。

我们在 MySQL 中使用这四种隔离等级：READ UNCOMMITTED/READ COMMITTED/REPEATABLE READ/SERIALIZABLE。隔离等级的不同就意味着在同一个时间节点下查询到的内容可能不同，数据的可靠性也会变得不同。接下来我们来简单了解一下这四种隔离等级，并且通过一个测试数据库来验证一下。

0X01 How to try it

首先要建一个数据库来做测试，表结构和两条基础数据长这样，可以通过随便什么方法把表先建好。

1
2
3
4
5
6
7
8

CREATE TABLE `account` (
  `id` int(11) NOT NULL,
  `username` varchar(10),
  `money` int(11) DEFAULT 0,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

INSERT INTO `account` VALUES (1, 'shawn', 100),(2, 'bluce', 100);

然后我们打开两个 MySQL 的终端连接（一定是两个），其中一个用来执行事务 A，一个用来修改隔离等级然后观察结果。

修改隔离等级的时候，可以选择“全局”或者“会话”两种级别，我们在测试阶段就只需要修改“会话”级就可以了。用的是SET session transaction isolation level read committed;这样的方法，其中最后的read committed就是其中一个隔离等级。

注意在会话级别修改隔离等级应该是在你 select 去验证的会话里执行，而非执行事务的会话。换个说法就是“隔离等级”是针对事务外的，而非针对事务。

0X00 使用 with as 语法

我们写程序经常会操作文件，我们都知道写文件要 open/write/close ，尤其是 close ，没有的话文件就会出问题（有些内容在缓存里，没写入磁盘）。不过我们现在写文件应该没什么人这样写了，都是用with open('filename', 'w') as f的方式来操作文件了。如果说这样做的好处，那多数人都会说“不用手动关闭文件了”，错肯定没错的。

上下比起来，上面的方式不仅多了一点点代码，而且随着中间逻辑代码变多，很可能会导致最后忘记 close，从而引发 bug。

0X01 这就是上下文管理器

上面 with xxx as xxx 的调用方式就是在调用上下文管理器。简单来说上下文管理器就是：在执行你编写的代码（with xxx as xxx后面那坨）之前，操作一波；再在你编写的代码执行完后，操作一波。我们简单理解一下就是在 with open('file_name', 'w') as f 内层缩进的代码执行完成后自动帮你执行了f.close()（当然没这么简单，有兴趣可以去看一下 open 的源码，但是大体逻辑是这样的）。

0X00 objects 是个啥

想必所有用过 Django 的人都会用到 Django 自带的 ORM 进行数据库查询。那既然用过 Django 的 ORM 就来看一下这段代码好了， models.Stuent.objects.filter(name='Shawn') 这段代码是什么意思呢？很简单，就是查询到名字为”Shawn”的学生信息。具体来说， models 应该是一个放了多个 model 的文件，Student 是一个具体的模型，filter 是筛选，name='Shawn' 则是筛选条件。那么问题来了，中间那个 objects 是个啥呢？（你知道？知道还在这儿看啥，有这空看看其他文章，打打游戏看看电影不好吗🤣）

通过 type 可知，这个 objects 是一个 django.db.models.manager.Manager 的实例（或者是他子类的实例）。然后我们来看看这个Manager是个什么❓

A Manager is the interface through which database query operations are provided to Django models. At least one Manager exists for every model in a Django application.

从 Django 文档得知“Manager 是 Django 用来进行数据库查询的一个接口，在 Django 应用中每个 model 都需要至少有一个 Manager”。