前几天实现了在 nginx 中使用 lua 实现远程鉴权，今天想试试在 IIS 中能不能实现相同的功能。查询资料发现需要使用 URL 重写和 HTTP 请求模块，没有深究。干脆使用 ASP.NET 中间件来实现吧。
在 StratUp.cs 的 Configure 方法中，或 Program.cs 文件中添加以下代码：
// 远程鉴权
app.Use(async (context, next) =>
{
var ip = context.Connection.RemoteIpAddress!.ToString();
var ua = context.Request.Headers.UserAgent.ToString();
var host = context.Request.Host.Host;
var uri = new Uri(context.Request.GetDisplayUrl()).PathAndQuery;
var client = new HttpClient();
client.Timeout = TimeSpan.FromSeconds(1); // 设置超时时间
try
{
var requestUrl = "https://鉴权地址/";
var requestMessage = new HttpRequestMessage(HttpMethod.Get, requestUrl);
requestMessage.Headers.Add("X-Real-IP", ip);
requestMessage.Headers.Add("User-Agent", ua);
requestMessage.Headers.Add("X-Forwarded-Host", host);
requestMessage.Headers.Add("X-Forwarded-Uri", uri);
// 发送请求
var response = await client.SendAsync(requestMessage);
// 检查响应状态码
if (response.StatusCode == HttpStatusCode.Forbidden)
{
// 如果返回403，则拒绝访问
context.Response.StatusCode = (int)HttpStatusCode.Forbidden;
await context.Response.WriteAsync("Access Denied");
}
else
{
// 如果返回其他状态码，则继续执行管道中的下一个中间件
await next();
}
}
catch (TaskCanceledException ex) when (ex.CancellationToken.IsCancellationRequested)
{
// 如果请求超时（任务被取消），则继续执行管道中的下一个中间件
await next();
}
catch
{
// 如果遇到错误，则继续执行管道中的下一个中间件
await next();
}
});代码很简单，使用 HttpClient 发送请求，若返回 403 则拒绝访问，其它情况继续执行业务逻辑，超时或报错的情况按需修改即可。
若鉴权接口在私网中，建议将鉴权接口域名和私网 IP 添加到 hosts 文件中。
User-Agent 字符串不会进行更新以区分 Windows 11 和 Windows 10。
但我们可以使用 JS 进行客户端判断是否为 Windows 11：
navigator.userAgentData.getHighEntropyValues(["platformVersion"])
.then(ua => {
if (navigator.userAgentData.platform === "Windows") {
const majorPlatformVersion = parseInt(ua.platformVersion.split('.')[0]);
if (majorPlatformVersion >= 13) {
console.log("Windows 11 or later");
}
else if (majorPlatformVersion > 0) {
console.log("Windows 10");
}
else {
console.log("Before Windows 10");
}
}
else {
console.log("Not running on Windows");
}
});支持客户端提示 User-Agent 浏览器：
| 浏览器 | 通过客户端提示 User-Agent 区别？ |
|---|---|
| Microsoft Edge 94 及以上 | 是 |
| Chrome 95 及以上 | 是 |
| Opera | 是 |
| Firefox | 否 |
| Internet Explorer 11 | 否 |
这个现象在国产浏览器上使用极速内核时出现，原因是百度编辑器上传图片功能通过 <form /> 提交到 <iframe /> 时，因跨域导致 cookie 丢失。
ASP.NET 的 ASP.NET_SessionId 默认的 SameSite 属性值为 Lax，将其设置为 None 即可：
protected void Session_Start(object sender, EventArgs e)
{
// 解决在部分国产浏览器上使用百度编辑器上传图片时（iframe），未通过 cookie 传递 ASP.NET_SessionId 的问题
string ua = Request.UserAgent ?? "";
var browsers = new string[] { "QQBrowser/" /*, "Chrome/" 不要直接设置 Chrome，真正的 Chrome 会出现正常页面不传递 Cookie 的情况 */ };
bool inWeixin = ua.Contains("MicroMessenger/"); // 是否在微信中打开（因微信PC端使用QQ浏览器内核，下面的设置会导致其网页授权失败）
if (browsers.Any(c => ua.Contains(c)) && !inWeixin)
{
Response.Cookies["ASP.NET_SessionId"].SameSite = SameSiteMode.None;
}
}以上代码加入到 Global.asax 的 Session_Start 方法中，或百度编辑器所在页面。
注意一：SameSite=None 时会将父页面的 cookie 带入到 iframe 子页的请求中，从而导致 cookie 泄露，请确保项目中无任何站外引用，如网站浏量统计器、JS组件远程CDN等！
注意二：微信PC版的内嵌浏览器使用QQ浏览器内核，以上代码会导致其微信网页授权不能正常执行。
* 若无特殊注明，本文中的“手机”包含平板电脑
判断网页是否在移动设备中打开
Web Form：
public static bool IsMobileDevice
{
get
{
return (HttpContext.Current.Request.Browser?.IsMobileDevice ?? false)
|| (HttpContext.Current.Request.UserAgent?.Contains("Mobile") ?? false);
}
}ASP.NET Core：
好像还没有找到，可能是因为随着响应式布局的流行以及电脑和手机之间的界线越来越不明朗，取消了这个判断？
判断网页是否在微信浏览器中打开（宽松）
Web Form：
public bool IsInWechat
{
get
{
return HttpContext.Current.Request.UserAgent?.Contains("MicroMessenger") ?? false;
}
}ASP.NET Core：
需注入 IHttpContextAccessor
public bool IsInWechat
{
get
{
string ua = httpContextAccessor.HttpContext.Request.Headers[HeaderNames.UserAgent];
return ua?.Contains("MicroMessenger") ?? false;
}
}判断网页是否在微信浏览器中打开（严谨）
使用 JS-SDK 网页授权来判断
* 本文凡使用变量 httpContextAccessor 或 _httpContextAccessor 的地方都需要需要注入 Microsoft.AspNetCore.Http.IHttpContextAccessor
* 在视图（view）中应以 ViewContext 类引出
获取当前页面网址：
using Microsoft.AspNetCore.Http.Extensions;
string url = Request.GetDisplayUrl();获取当前访问的域名和端口：
获取来源：
Request.GetTypedHeaders().Referer
判断 Scheme 是否为 https：
Request.IsHttps获取客户端IP和端口、服务器IP和端口：
获取浏览器用户代理（UserAgent）：
httpContextAccessor.HttpContext.Request.Headers[HeaderNames.UserAgent];获取当前请求的唯一标识：
httpContextAccessor.HttpContext.TraceIdentifier返回结果：80000564-0002-f700-b63f-84710c7967bb
用途：可作为生成随机数的种子。
获取客户端IP地址：
httpContextAccessor.HttpContext.Connection.RemoteIpAddress获取当前项目根目录磁盘路径：
AppContext.BaseDirectory // 以“\”结尾注意：此路径到项目根目录，而非网站根目录，网站根目录请自行追加，默认为 wwwroot\
编码/解码：（参数和返回值均为 string?）
using System.Net;
WebUtility.HtmlEncode(myString)
WebUtility.HtmlDecode(myString)
WebUtility.UrlEncode(myString)
WebUtility.UrlDecode(myString)更多：https://xoyozo.net/Blog/Index/Core
今天终于把大量占用论坛服务器带宽的元凶找到了！
我们的论坛使用阿里云的 ECS+RDS+OSS+CDN 架构，最近发现 ECS 的带宽怎么都不够用了，也没有什么突发事件呀，再说附件都在 OSS 上。观察了云监控控制台，发现半夜里的流量也不减呀，白天更是触顶下不来，坛友们真是不辞辛劳为 PV 作贡献啊。
我对 CentOS 还是不够熟悉的，查阅了一些资料后，终于找到方向入手了。
重点肯定是日志文件了，但是面对每天几个 G 的大块头，还真是无法下手，一条一条看估计胡子都白花花了。
那么，首先安装 GoAccess 这个好东西（yum install goaccess）
然后进入网站日志目录，用 GoAccess 来分析一下（goaccess -f xxxxxx.log -a），具体用法参官网
选择日志格式，nginx 默认为 NCSA Combined Log Format，空格选中，回车确认
稍等片刻就可以看到主界面了，统计信息丰富多彩，统计结果一目了然，看截图，如果你分析的日志文件是当前正在使用中的，它还会每秒刷新主界面，让你看到实时统计
大致分为几块内容：
按 1 定位到“按天访问量”
按 2 定位到“最多次被请求的 URL”
按 3 定位到“最多次被请求的静态文件”
按 4 定位到“最多次被请求的 404”
按 5 定位到“最多次请求的用户 IP”
按 6 定位到“用户的操作系统”
按 7 定位到“用户的浏览器”
按 8 定位到“按小时的统计”
按以上数字键后，再按回车可以查看具体或更多的信息，按 s 可以更换排序，按 q 返回或退出
那么我先找 5 最多次请求的用户 IP，排前面的全部是从 60.191.127.4 到 60.191.127.26 的 IP，每个 IP 都是几 G 级的带宽占用。
负责任的，你必须保证这些 IP 不是政府或大企业的对公 IP，而且得拿这些 IP 直接去日志文件里搜到底请求了哪些 URL。经查证，它们只请求版块的帖子列表页，没有请求任何图片、脚本、样式等，还有，UserAgent 中没有带 Spider 之类的关键字，证明不是搜索引擎的蜘蛛，那么就可以果断认为它“不是人”
啥都不说了，找到 nginx 的 conf 配置文件，在 server 中添加 deny 60.191.127.0/24;
检查配置：nginx -t
使配置生效：nginx -s reload
呵呵，马上就能在阿里云监控里看到过山车式的折线了。
另外，备注下查看各IP的连接数的命令：
netstat -an|grep :80| awk '{print $5}'| cut -d':' -f1| sort |uniq -c