b23.kim

很久以前，我看到一个评论区对域名的级数吵的不可开交。有人认为这是三级域名，也有人认为这是二级域名。双方各执一词，始终坚信自己是对的，而对方是错的（评论区吵架现状）。而原视频讲的是一个免费域名分发的好像是（具体我也忘了，我大概在三年前看到的那个视频） 因为突然想起来这个，所以我决定单独新开一篇文章来讲这个事。“三级域名”和“二级域名”到底应该如何区分。实际上这个还真难分对错，因为参考系不同所以在不同的角度下有不同的答案。 举个例子，假如lhy.b23.kim这个域名（其实真的存在，我分发给我朋友用的）。如果按“三级域名”的标准解读：1.kim2.b233.lhy正好，从后缀开始从右往左数，确实是三级。那么这个角度是相对于注册局而言的。ICANN管理根部，把不同类型的根分配给不同的注册局。然后由用户/企业挑选根部来注册出新的一级，注册完成后在自己的域(例如b23.kim)下进一步管理子级的创建和分发使用。这是一种技术严谨的观察角度。根也被称为“顶级域名”，也就是一级域名。一级就是顶级，因为没有在它们之上的域了所以是顶级。（学新闻学的会把这里的“顶级”当形容词来用，比如BV1...

众所周知，Artalk支持标准的OAuth接口的社交登录方式。但是有些奇怪的SSO提供的接口可能不是标准的OAuth，甚至Artalk和提供SSO的软件都不支持修改自己读取的路径或写入的路径。（点名Casdoor）灵感来源：https://blog.liushen.fun/posts/8624756e/ 登录的一般过程本文将以Casdoor作为例子，实际根据相关接口情况思路通用。在此之前我们需要了解Artalk的OAuth是如何验证的：第一步首先你点击了“登录”按钮，然后选择了OAuth登录方式。这时候Artalk会跳转配置文件的Domain字段/authorize（此时查询参数携带client_id、redirect_uri、response_type、scope、state字段）这个目标登录页面，交由目标OAuth服务(Casdoor)来给用户提供服务。然后你在这个登录页面选择了 使用Github登录 ，跳转了Github官方的验证页。验证完成后会跳转到Github后台配置的回调Casdoor后端域名/callback交给Casdoor来验证和处理GitHub验证完成后的他们...

刚才看到一个非常壮观的视频，里面有个评论非常深入人心：有序只是世界的偶然，无序是世界的本身。这个观点是所有系统的本质。或者说，整个宇宙就是一个庞大的系统。 在宇宙中，每一个天体都沿着自己固定的轨道运行，这是有序。那么凡事都会有至少一个“例外”，举一个夸张的例子吧：如果突然飞过来一个很大的石头把这个天体砸了，而且刚好使它脱离了原先的轨道呢？我知道这个例子看起来很夸张，但在无限的时间尺度下这几乎是必然的。因为你也说不清宇宙环境最终会演化成什么样，在“无限”这个概念下，空间无限大，时间无限长，情况无限多。这样来看它原先“有序”的样子只是在这个过程里偶然发生的。在这种情况下，“有序”这个概念就是“只缘身在此山中”了。从宏观角度来看，世界是无序的。 在计算机世界里，每一台电脑都有序地执行预定的任务，这叫有序。但是计算机的世界本质上是逻辑的世界，是逻辑就会存在疏漏。我们一般管它叫“业务逻辑漏洞”，换句话说就是“出bug了”。最终就会归于这种无序的状态，因为它引入了例外这一个打破原有秩序的东西。最终人们通过代码补丁避免无序性，回归原有“有序”的状态。这样来看甚至就连“秩序”本身都是无序...

Casdoor 是一个开源的统一身份认证平台，定位类似于“通行证中心”。通过标准化的协议和接口，把分散在不同系统中的用户认证集中起来管理，让登录这件事变得更简单。——清羽飞扬 下载、配置文件与安装这个是它的官方文档：https://www.casdoor.org/zh/docs/overview （目前汉化还不完全，而且还有很多不准确的机翻）可以看到它提供了三种安装方式：1.二进制安装包，从Github Release下载：https://github.com/casdoor/casdoor/releases2.Docker容器镜像：https://hub.docker.com/r/casbin/casdoor3.K8s Helm：https://www.casdoor.org/zh/docs/basic/try-with-helm 拉取镜像本文将采用Docker容器的方式来安装，配合宝塔面板。依旧是1panel镜像。下载镜像： 1docker pull docker.1panel.live/casbin/casdoor 下载完成后保留备用。 数据目录设置与数据库配置下一步，...

在给电脑重装完系统以后，我就把自己博客源码迁移过来了。一开始没什么，后面我发现了一个很诡异的事：日期怎么变成这样了，更新日期比发布日期还提前。肯定不对。我发现这里更新日期其实就是这篇文章的“发布日期”，因为这篇是Hello World，是搭建的时候系统自动生成发一篇文章，所以也相当于是建站时间。 那么究竟是为什么呢？其他的文章都没出问题，就这个出问题了。而且出现在迁移后这个时间点。 于是我简单了解了一下Hexo框架对于文章的更新和发表日期是如何确定的，得出了一个结论对于发布日期：它会去读Front-matter里的date参数，如果有就直接把它的值作为发表日期；否则，将会采用文件系统里的文件元数据中的 文件创建日期 作为发表日期。刚好，系统给的示例文章Front-matter是不带date参数的对于更新日期：它会直接读文件元数据中的“修改日期”字段 因为示例文章(Hello world)里面是没有date信息的，所以它的降级策略会去看文件元数据。这样这个诡异问题的源头就在文件元数据上。 如果是刚创建出来的文件，那么它的创建日期和修改日期应该是一致的，修改日期就是创建日期。那么如果...

Uptime-Kuma是一个Server级的网站状态监控软件，它能实现看自己的状态。配置好后你甚至都能看别人的网站状态。而且最关键的是它不仅支持监控HTTP协议的服务器，同时还支持诸如UDP和自定义TCP协议的监控。https://github.com/louislam/uptime-kuma 安装作为一个Docker软件，安装Docker是必不可少的。然后你需要一个镜像站来拉取代码。本文统一使用docker.1panel.live源。安装命令： 1docker pull docker.1panel.live/louislam/uptime-kuma:2 启动命令： 1docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma docker.1panel.live/louislam/uptime-kuma:2 如果你能看到类似9c3d9374d8022c436c840410e6acb17165c5abca79634cef4fee4883d8d23eaf的输出就成功...

之前阿里云送礼物，于是我就领了一个。原本这是开箱记录文的，平平无奇没什么好说的。但是哎，这次可不一样。这此的可是混合着，咳咳的重磅惊喜。 开箱哎不是，怎么右上角……能想象到画面了我是菜鸟，想寄就寄倒也无所谓了，反正只是外包装哈哈 嗯，挺好，木座也有。下面就寄希望于没有给我少张数了。稍微数了下，算上封面确实一共13张，没少。我倒是粗略的看了下，没看有没有重复页，因为当时要忙着去上课。 放学以后我就回来看二叉树树的群，发现竟然有两个月都是July。况且当时我还没意识到事情的严重性…… 大厂漏勺我是通过看二叉的群才知道原来有如此离谱的印刷质量问题，真的离谱到炸了。 然后二叉不是在直播吗，我截了张图，节目效果拉满了真的 一想到他们一整个仓库都是这样的我就想笑。更炸裂的是，给二叉树树发的台历直接就只有个木头底座，卡片根本没有：这个或许是我见过的最好笑的，太惨了（众所周知喜剧的内核是悲剧）这难道就是传说中的阿里云实体版“云原生台历”，只剩底座了内容全丢包了 不过好在能申请补发。如果你的也有问题就去这里填单吧：https://survey.aliyun.com/apps/zhiliao/YIc...

好奇看了下自己的域名，然后想着我的“同行域名”都怎么样了。于是根据域名whois信息写下了这篇收集。 b23.com: 1999-06-11 上古神器b23.it: 2002-08-02b23.net: 2003-03-07b23.ru: 2007-09-10b23.cz: 2008-06-06 注册局文件精确到秒05:35:23，但不知道时区b23.ch: 2009-01-11b23.be: 2010-03-23b23.hk: 2010-06-10b23.io: 2013-11-03b23.in: 2017-01-23b23.online: 2017-04-13b23.tv: 2017-08-22 B站官方短链接b23.me: 2017-12-08b23.fit: 2019-09-24b23.fr: 2020-04-08b23.site: 2020-05-21b23.top: 2021-01-01b23.wtf: 2021-02-03b23.tech: 2021-04-13b23.fun: 2021-07-28b23.work: 2021-08-06b23.icu: 2021-...

OK啊，我们的大工信部的网站也没有逃过被人打/服务器内部错误/访问人数大……总之各种原因引发的拒绝服务。 前段时间我在外面用手机看https://beian.miit.gov.cn/ 的时候就总感觉莫名其妙的好像很卡的感觉，没想到是初见端倪了。 于是下面就是现在它的样子，也就是我写稿的时候：你就看这响应吧，竟然整整过了近20秒？！要知道，国内网站几乎是秒开的，响应不会超过10ms。这20秒简直恐怖。 于是二叉在群里发出了尖锐的爆鸣声： 然后我又去试了遍，发现响应时间直接来到了28秒！ 我是真的服了，这还是能用的状态。不能用的时候拒绝服务那种，要是遇到个备案的要短信核验，然后短信有效期只有一天。这你怎么整？这就体现出灾备的重要性了。强烈建议他们搞个备用验证方案，一个不行换另一个。再不就是把这唯一的验证通道给整好，整安全点，最起码别让别人用不了就行。好神奇的现实世界

大家好啊 腾讯作为国内一家知名的 草 台 班 子 企业，想必一定是非常“严谨”的。得益于它那优秀的内部，它能做到很多很荒诞的东西。其中便包括经典的错别字和漏字。对普通人而言犯点错误也难免，但是这是出在这种知名大企业上，而且还扮演着举足轻重的地位。在我们的印象里，腾讯这种大企业应该是象征着严谨和技术能力雄厚的但实际上是…… 如果互联网有一个 “赛博整活/出幺蛾子排行榜”，腾讯绝对是当之无愧的 T0 级别 霸榜选手。它的“幺蛾子”不仅仅是多，而是种类丰富、花样翻新、逻辑感人，经常能打出让技术人员和用户同时脑溢血的操作。——gemini-3-pro 那废话不多说，我们直接进入正题： QQ手游戏这个其实出自ARK模板com.tencent.gamecenter.collect_card_share_v2的某一业务下面的卡片签名接口里面的其中一个在json模板里透传给前端的desc字段的值。《QQ手游戏》我估计写这个逻辑的人当时想的要么是“QQ手机游戏”，要不就是“QQ手游”。那么少打一个字或者多打一个字是为什么呢？我开始思考……终于知道了答案，嗷卧槽这里我估计大概率是用“输...