编程笔记

edge 经常占用大量内存,最新版的edge支持设置占用内存量

步骤

调整内存使用设置

在 Microsoft Edge 的最新版本中，您可以手动设置浏览器的内存使用量。具体步骤如下：
打开 Edge 浏览器，点击右上角的三个点（菜单）

选择“设置”,在“系统和性能”中找到性能下的“启用资源控件”选项，限制 Edge 的内存使用量，例如设置在 1GB 到 16GB 之间。

选择合适控制资源选项中选择”始终”

图示

如果没有下方的设置,可更新edge版本后重试

ShadyPanda ran a seven-year browser-extension campaign that infected about 4.3 million Chrome and Edge users. The group published seemingly legitimate extensions—examples include Clean Master and WeTab—accumulating featured badges and millions of installs to gain user trust. Once widely deployed, they silently pushed malicious updates that transformed those extensions into backdoors and spyware: executing remote JavaScript, harvesting full browsing histories, keystrokes, cookies, and browser fingerprints, and exfiltrating data to attacker-controlled domains. The campaign highlights a systemic flaw in marketplace security:one-time submission reviews plus automatic updates allow trusted extensions to be weaponized after approval, requiring ongoing behavioral monitoring.

名为 ShadyPanda 的组织策划并实施了长达七年的浏览器扩展恶意活动，感染了约 430 万用户。他们先发布合法插件（如 Clean Master、WeTab）以获取信任和“Featured/精选”推荐，积累数百万用户后通过静默更新将这些扩展武器化。这些扩展成为后门与间谍软件，窃取浏览历史、执行远程代码，暴露出应用商店“只在提交时审查”的系统性漏洞。

如何使用 github Fine-grained personal access token 修改组织下仓库文件

默认的必应搜索搜索代码相关的信息很多csdn的文章,质量不行,使用 -*.csdn.net过滤掉

默认

搜索coze,默认为:

国内版 https://cn.bing.com/search?q=coze
国际版 https://bing.com/search?q=coze

屏蔽后

国内版 https://cn.bing.com/search?q=coze%20-site:*.csdn.net
国际版 https://bing.com/search?q=coze%20-site:*.csdn.net

配置

使用 Infinity 插件的可以这样配置:

逐步走读 Linux 的启动过程：从按下电源到进入内核的第一行 C 代码，涵盖 CPU 复位、BIOS/UEFI、引导加载器、内核 setup 阶段与内存映射等关键环节。

独立开发的AI图生图工具“即梦”获得了第一位付费用户，并且现在支持在线支付了。

收款方式

最开始为了快速打通，是在定价页面上贴了微信二维码，让用户加群支付，这种方式过于复杂，用户体验也不是很好。

从多个渠道了解了独立开发的收款方式，最终选择了微信支付。微信支付在国内用户中足够流行，目前也是最容易接入的几种可靠支付方式之一，并且使用起来也比较方便。

现在可以在“AI图生图”的官方网站上直接购买服务啦。

效果如下：

其他方式

国外的Stripe，lemonsqueezy很流行，但搜了很多资料，目前看都是需要以公司为主体才能申请，个人很难通过。

参考

• 使用闲鱼平台实现虚拟商品销售，需要接入第三方平台自动发货，或自行部署自动发货的程序,github项目
• stripe
• lemonsqueezy
• 境外支付网关Stripe注册指北
• 个人开发者如何收款–国内篇,二级支付，不推荐
• 万里汇，跨境电商
• linuxdo上分享的全球收款教程，stripe

一名开发人员分享了如何在一次虚假的区块链公司面试中差点被安装恶意软件的经历，以及如何通过人工智能提示避免了灾难。

Go 1.25 在标准库中引入了一个新的中间件 http.CrossOriginProtection。这让我思考：我们是否终于可以在不依赖基于令牌的检查（如双重提交 Cookie）的情况下防止 CSRF 攻击？是否可以在不引入第三方包（如 justinas/nosurf 或 gorilla/csrf）的情况下构建安全的 Web 应用？

答案是一个谨慎的 “是” —— 只要满足一些重要条件。

http.CrossOriginProtection 中间件

该中间件通过检查请求中的 Sec-Fetch-Site 和 Origin 头来判断请求来源。它会自动拒绝来自非同源的 非安全请求（如 POST、PUT），并返回 403 Forbidden。

工作原理

• 现代浏览器 会自动在请求中包含 Sec-Fetch-Site 头。
• 如果请求来源与目标页面同源，则头部为 same-origin。
• 如果不同源，则 http.CrossOriginProtection 会拒绝请求。
• 如果没有 Sec-Fetch-Site，则回退检查 Origin 与 Host 是否匹配。
• 如果两者都不存在，则认为请求不是来自浏览器，允许通过。
• 仅对 非安全方法（POST、PUT 等）进行检查，GET/OPTIONS 等安全方法始终允许。

使用示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

package main

import (
    "fmt"
    "log/slog"
    "net/http"
    "os"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/", home)

    slog.Info("starting server on :4000")
    err := http.ListenAndServe(":4000", http.NewCrossOriginProtection(mux))
    if err != nil {
        slog.Error(err.Error())
        os.Exit(1)
    }
}

func home(w http.ResponseWriter, r *http.Request) {
    fmt.Fprint(w, "Hello!")
}

如果您愿意，也可以配置 http.CrossOriginProtection 的行为。配置选项包括能够添加受信任的来源（允许来自这些来源的跨域请求），以及能够为被拒绝的请求使用自定义处理程序，而不是默认的 403 Forbidden 响应。

想自定义行为时，可以使用如下模式：

文件: main.go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

package main

import (
	"fmt"
	"log/slog"
	"net/http"
	"os"
)

func main() {
	mux := http.NewServeMux()
	mux.HandleFunc("/", home)

	slog.Info("starting server on :4000")

	err := http.ListenAndServe(":4000", preventCSRF(mux))
	if err != nil {
		slog.Error(err.Error())
		os.Exit(1)
	}
}

func preventCSRF(next http.Handler) http.Handler {
	cop := http.NewCrossOriginProtection()

	cop.AddTrustedOrigin("https://foo.example.com")

	cop.SetDenyHandler(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		w.WriteHeader(http.StatusBadRequest)
		w.Write([]byte("CSRF check failed"))
	}))

	return cop.Handler(next)
}

func home(w http.ResponseWriter, r *http.Request) {
	fmt.Fprint(w, "Hello!")
}

限制

http.CrossOriginProtection 的主要限制是它只对阻止来自现代浏览器的请求有效。您的应用程序仍然容易受到来自不包含 Sec-Fetch-Site 或 Origin 头（通常是 2020 年之前的）的旧版浏览器的 CSRF 攻击。

目前，浏览器对 Sec-Fetch-Site 头的支持率为 92%，对 Origin 头为 95%。因此，通常情况下，仅仅依靠 http.CrossOriginProtection 不足以作为您唯一的 CSRF 防护措施。

还需要注意的是，只有当您的应用程序具有“可信来源”时才会发送 Sec-Fetch-Site 头——这基本上意味着您的应用程序在生产环境中使用 HTTPS（或开发期间使用 localhost），http.CrossOriginProtection 才能充分发挥作用。

您还应该知道，当请求中不存在 Sec-Fetch-Site 头，并且回退到比较 Origin 和 Host 头时，Host 头不包含方案。这个限制意味着当不存在 Sec-Fetch-Site 头但存在 Origin 头时，http.CrossOriginProtection 会错误地允许从 http://{host} 到 https://{host} 的跨域请求。为了减轻这种风险，您理想情况下应该配置您的应用程序使用 HTTP 严格传输安全 (HSTS)。

强制使用 TLS 1.3

深入研究这个问题让我开始思考… 如果您已经计划使用 HTTPS 并强制使用 TLS 1.3 作为最低支持的 TLS 版本呢？您能否确信所有支持 TLS 1.3 的网络浏览器也支持 Sec-Fetch-Site 或 Origin 头之一呢？

据我从 MDN 兼容性数据和 Can I Use 网站的表格来看，答案是“是”，适用于（几乎）所有主流浏览器。

如果您强制使用 TLS 1.3 作为最低版本：

• 不支持 TLS 1.3 的旧版浏览器根本无法连接到您的应用程序。
• 对于支持 TLS 1.3 并可以连接的现代主流浏览器，您可以确信至少支持 Sec-Fetch-Site 或 Origin 头之一——因此 http.CrossOriginProtection 将有效工作。

我能看到的唯一例外是 Firefox v60-69 (2018-2019)，它不支持 Sec-Fetch-Site 头，并且不为 POST 请求发送 Origin 头。这意味着 http.CrossOriginProtection 将无法有效阻止来自该浏览器的请求。Can I Use 显示 Firefox v60-69 的使用率为 0%，因此这里的风险似乎非常低——但世界上某个地方可能仍然有一些计算机在运行它。

此外，我们只掌握了主流浏览器（Chrome/Chromium、Firefox、Edge、Safari、Opera 和 Internet Explorer）的信息。但当然，还存在其他浏览器。它们大多数是 Chromium 或 Firefox 的分支，因此很可能没问题，但这里没有保证，并且很难量化风险。

因此，如果您使用 HTTPS 并强制使用 TLS 1.3，这是确保 http.CrossOriginProtection 有效工作的一大步。然而，Firefox v60-69 和非主流浏览器仍然存在非零风险，因此您可能希望增加一些纵深防御并同时使用 SameSite Cookie。

我们稍后会更多地讨论 SameSite Cookie，但首先我们需要快速绕道讨论“源 (origin)”和“站点 (site)”这两个术语之间的区别。

跨站点与跨源

在 Web 规范和 Web 浏览器的世界中，跨站点 (cross-site) 和跨源 (cross-origin) 是细微不同的概念，在这样的安全上下文中，理解它们之间的区别并确切地表达我们的意思非常重要。

我将快速解释。

如果两个网站共享完全相同的方案 (scheme)、主机名 (hostname) 和端口（如果存在），则它们具有相同的源 (origin)。因此 https://example.com 和 https://www.example.com 不是相同的源，因为主机名 (example.com 和 www.example.com) 不同。它们之间的请求将是跨源的。

如果两个网站共享相同的方案和可注册域 (registerable domain)，则它们是“同站 (same site)”的。

注意：可注册域是主机名中紧邻（并包括）有效顶级域 (effective TLD) 的部分。以下是一些示例：

• 对于 https://www.google.com/，顶级域是 com，可注册域是 google.com。
• 对于 https://login.mail.ucla.edu，顶级域是 edu，可注册域是 ucla.edu。
• 对于 https://www.gov.uk，顶级域是 gov.uk，可注册域是 www.gov.uk。

您可以在此处找到有效顶级域的完整列表。

因此，https://example.com、https://www.example.com 和 https://login.admin.example.com 都被认为是同站的，因为方案 (https) 和可注册域 (example.com) 相同。它们之间的请求不会被认为是跨站的，但会是跨源的。

注意：某些浏览器版本使用不同的同站定义，它不要求相同的方案，只要求相同的可注册域。对于这些浏览器版本，https://admin.example.com 和 http://blog.example.com 也将被视为同站。

如今，这通常被称为无方案同站 (schemaless same-site)，但在历史版本或文档中，它可能只被称为同站。

那么，我在这里想要表达的要点是什么呢？

Go 的 http.CrossOriginProtection 中间件的命名是准确且恰当的。它阻止跨源请求。它比只阻止跨站请求更严格，因为它也阻止来自同一站点（即可注册域下的其他源）的请求。

这很有用，因为它有助于防止您的老旧、十多年未更新的 WordPress 博客 https://blog.example.com 被攻破，并被用来向您的重要网站 https://admin.example.com 发起请求伪造攻击的情况。

当大多数人——包括我自己在内——随意谈论“CSRF 攻击”时，我们大多数时候指的是实际上是跨源请求伪造 (cross-origin request forgery)，而不仅仅是跨站请求伪造 (cross-site request forgery)。很遗憾 CSRF 是描述这类攻击的常用和已知缩写，因为大多数时候 CORF 会更准确和恰当。但嘿！这就是我们所处的混乱世界。

然而，在本文的其余部分，当我的意思确实是跨源请求伪造时，我将使用 CORF 代替 CSRF。

SameSite Cookie

SameSite Cookie 属性自 2017 年起普遍受到网络浏览器的支持，Go 自 v1.11 起也支持。如果您在 Cookie 上设置 SameSite=Lax 或 SameSite=Strict 属性，则该 Cookie 将仅包含在发送到设置它的同一站点的请求中。反过来，这可以防止跨站请求伪造攻击（但不能防止来自同一站点内的跨源攻击）。

这里有一些好消息——所有支持 TLS 1.3 的主流浏览器也都完全支持 SameSite Cookie，据我所知没有例外。因此，如果您强制使用 TLS 1.3，您可以确信所有使用您应用程序的主流浏览器都会遵守 SameSite 属性。

这意味着通过在 Cookie 上使用 SameSite=Lax 或 SameSite=Strict，您可以消除我们之前谈到的 Firefox v60-69 引起的跨站请求伪造风险。

综合考量

如果您结合使用 HTTPS，强制将 TLS 1.3 作为最低版本，适当使用 SameSite=Lax 或 SameSite=Strict Cookie，并在您的应用程序中使用 http.CrossOriginProtection 中间件，据我所知，主流浏览器只剩下两个未被缓解的 CSRF/CORF 风险：

1. Firefox v60-69 中来自同一站点的 CORF 攻击（即来自您的可注册域下的另一个子域）。
2. 从您的源的 HTTP 版本发起的 CORF 攻击，来自不支持 Sec-Fetch-Site 头的浏览器。

对于第一个风险，如果您在可注册域下没有任何其他网站，或者您确信这些网站是安全的且未被攻破，那么鉴于 Firefox v60-69 的使用率极低，这可能是一个您愿意接受的风险。

对于第二个风险，如果您的源根本不支持 HTTP（包括重定向），那么您无需担心这一点。否则，您可以通过在 HTTPS 响应中包含 HSTS 头来缓解风险。

在本文的开头，我提到在某些条件下不使用基于令牌的 CSRF 检查可能是可以的。那么，让我们回顾一下这些条件是什么：

• 您的应用程序使用 HTTPS 并强制将 TLS 1.3 作为最低版本。您接受使用旧版浏览器的用户将根本无法连接到您的应用程序。
• 您遵循良好实践，绝不响应使用安全方法 GET、HEAD、OPTIONS 或 TRACE 的请求来更改重要的应用程序状态。
• 您同时使用 http.CrossOriginProtection 中间件和 SameSite=Lax 或 SameSite=Strict Cookie。使用 SameSite Cookie 对于一般的纵深防御很重要，更具体地说，是为了缓解来自 Firefox v60-69 的 CSRF 攻击。
• 由于来自 Firefox v60-69 的未受保护的同站 CORF 攻击风险，您要么在您的可注册域下没有任何其他网站，要么您确信它们是安全且未被攻破的。
• 您的应用程序源根本没有 HTTP 版本，或者您在 HTTPS 响应中包含 HSTS 头。
• 最后，您愿意接受来自非主流浏览器（支持 TLS 1.3 但不支持 Origin 或 Sec-Fetch-Site 头或 SameSite Cookie）的 CSRF/CORF 攻击的难以量化的风险。是否存在这样的浏览器？我不知道，我也不确定是否有办法 100% 确定地回答这个问题。因此，您需要在此处进行自己的风险评估，这可能是一个您只愿意接受的风险，如果您的应用程序是一个低价值目标，并且成功进行 CSRF/CORF 攻击的影响既孤立又轻微。

原文

• https://www.alexedwards.net/blog/preventing-csrf-in-go

在数字创意的浪潮中，人工智能（AI）正以前所未有的方式赋予我们表达自我的力量。曾经需要专业技能和昂贵软件才能实现的视觉艺术，如今AI 的进步，变得触手可及。今天，我们向您隆重介绍一款强大而易用的在线工具——AI图生图，它将彻底改变您的创作流程，让每个人都能轻松成为艺术家。

最重要的是，这款工具限时免费试用，并且无需注册登录，您可以立即开始您的创意之旅！

立即访问 AI图生图，开启无限创造力

核心功能亮点

“AI图生图”不仅仅是一个简单的图像生成器，它集成了多种强大功能，旨在满足从初学者到专业人士的各种需求。

1. 强大的“文生图”与“图生图”模式

无论您是想将脑海中的奇幻场景变为现实，还是希望在现有图片的基础上进行二次创作，我们都能满足您。

• 文生图 (Text-to-Image): 只需输入一段描述性的文字（我们称之为“提示词”），AI 就能为您绘制出对应的图像。您的想象力是唯一的边界！
• 图生图 (Image-to-Image): 您可以上传一张自己的图片作为参考，AI
  将智能地理解其内容、风格和构图，并根据您的新提示词进行创新性地重绘或风格迁移。

2. 丰富的内置预设风格

灵感枯竭？没关系！网站内置了上百种精心调校的预设风格，涵盖3D、动漫、现实主义、纸艺、水墨画等多种艺术形式。只需一键点击，即可将您的想法应用到不同风格上，轻松探索多种可能性。

3. 极致简单的三步操作流程

我们坚信，强大的功能不应以牺牲易用性为代价。整个创作过程被简化为三个直观的步骤：

1. 描述您的想法： 在输入框中填写您的提示词，或上传参考图，并选择您喜欢的风格。
2. AI 魔法生成： 点击“生成”按钮，我们强大的 AI 模型将立即开始工作。
3. 下载与分享：
   短短几十秒后，一幅高质量的图像便会呈现眼前。您可以立即下载高清版本，或在历史记录中随时回顾。

无限的应用场景

“AI图生图”的潜力覆盖了各行各业，无论您的身份是什么，都能从中受益。

• 设计师与艺术家： 快速生成概念原型，探索不同视觉风格，为您的项目注入源源不断的灵感。
• 营销与运营人员： 无需再为寻找配图而烦恼。轻松生成独特、免版权风险的社交媒体帖子、博客文章配图和广告素材。
• 内容创作者： 为您的视频、播客或小说创作引人入胜的封面和插图。
• 普通爱好者： 制作个性化的手机壁纸、社交媒体头像，或者仅仅是享受将奇思妙想变为现实的乐趣。

立即开始您的创作之旅！

创意不应被技术门槛所束缚。“AI图生图”致力于将最前沿的AI技术以最简单的方式带给每一位热爱生活、充满想象力的人。

忘记复杂的参数和昂贵的订阅费吧。现在就打开浏览器，访问我们的网站，释放您被压抑已久的创造力！

官方网站： https://seedreamt.programnotes.cn/

我们期待看到您独一无二的精彩作品！

创意作品