Dvorak
Dvorak

Dvorak Chen

All Posts


学学dotnet core中的身份验证和授权-2-cookie

这篇文章深入探讨了在.NET Core中使用Cookie实现身份验证与授权的完整流程。通过登录接口下发加密Cookie凭证、配置身份验证策略、添加中间件解析声明、编写基于声明的授权策略,逐步构建了完整的身份验证体系。文章展示了如何通过ClaimsIdentity和ClaimsPrincipal封装用户信息,并利用SignInAsync方法将凭证写入Cookie。特别值得注意的是在授权策略中如何通过RequireAssertion方法组合多个声明条件,例如同时验证"张三"和"核酸24"的双重限制。测试过程中揭示了Cookie验证失败时默认重定向到/Account/Login的机制,这种设计引发思考:当系统需要支持多终端登录时,如何避免Cookie的跨域问题?文章最后指出Cookie验证在实际应用中存在局限性,这启发我们思考:在微服务架构下,是否应该采用JWT等更灵活的验证方式?当面对更复杂的授权场景时,如何设计可扩展的声明验证策略?这些开放性问题为读者提供了延伸思考的空间。--Qwen3

.NET Authentication Authorization ASP.NET Core Cookie authentication Claims based security

学学dotnet core中的身份验证和授权-1-概念

在.NET Core中构建安全系统时身份验证与授权如同建筑的门禁与房间权限的双重机制其关系如同证件查验与权限核验的先后逻辑——身份验证如同核验证件确认访客真实身份而授权则如同检查权限清单决定其能否进入特定区域。这种相辅相成的设计中声明(Claim)扮演着核心角色如同证件上的条目信息它通过类型-值的结构化数据承载身份特征例如身份证中的"姓名:张三"对应声明类型"姓名"与值"张三"。当请求携带由服务器颁发的凭证经过身份验证程序后声明信息将传递给授权系统进行权限判定。这种基于声明的授权机制允许开发者自定义权限规则如要求声明中包含"核酸检测:24小时"的条目才能访问特定接口。当授权程序根据声明判断通过时请求将被允许否则将触发预设的拒绝策略。这种设计模式不仅解决了凭证来源与信息传递的闭环问题更提供了灵活的权限控制框架——当系统需要处理更复杂的权限场景时如何设计声明结构如何平衡安全与性能如何实现动态授权策略这些未解的实践问题或许正是打开你思维的钥匙。--Qwen3

.NET Authentication Authorization ASP.NET Core Claims .NET Core

Rust - bytecodec 编解码库

在构建自定义网络协议编解码器时开发者常面临方法命名混乱调用不统一的挑战当面对Peer对象这类包含多个字段的结构时手动实现to_bytesfrom_bytes方法会导致代码碎片化缺乏可维护性bytecodec库通过定义标准化的EncoderDecoder trait为这一问题提供了解决方案其核心思想是将编解码逻辑封装在trait实现中并提供扩展方法简化调用流程该库预定义了Utf8Encoder等基础编码器可直接用于String等常见类型对于NatTypeSocketAddr等自定义类型则需通过组合已有编码器构建新的Encoder结构如NatTypeEncoderPubAddrEncoder通过实现start_encoding方法按字段顺序触发子编码器的初始化在encode方法中依次调用各字段编码器并插入换行符实现协议格式要求值得注意的是is_idle方法的实现需要判断所有子编码器是否完成编码这体现了状态机设计的精髓当面对更复杂的嵌套结构时如何设计可扩展的编码器组合机制如何平衡编解码性能与代码可读性如何处理协议版本演进带来的兼容性问题这些问题都值得开发者深入思考并探索bytecodec提供的高级特性来构建更健壮的协议实现--Qwen3

Rust bytecodec serialization custom encoder codec struct

Rust 小技巧之临时作用域

在Rust编程中Result和Option的处理往往让代码显得冗余而杂乱文章通过对比两种不同的代码组织方式揭示了临时作用域这一优雅的解决方案当需要临时变量或一次性操作时将逻辑包裹在花括号内的临时作用域能够自动管理资源释放无需额外函数抽象的开销这种写法不仅让核心变量如email的生命周期更加清晰还能在作用域结束时自动清理中间变量例如在读取用户输入的场景中相比将逻辑封装到read_email函数临时作用域如同一个精准的收纳盒既保持了代码的紧凑性又避免了函数调用的层级感文章最后抛出了一个值得思考的问题当面对复杂逻辑时我们该如何在函数抽象与临时作用域之间做出选择是追求极致的代码复用还是拥抱更轻量级的局部处理这种取舍或许正是Rust语言哲学中对资源控制与代码简洁平衡的生动体现--Qwen3

Rust Result and Option Code Optimization Rust Patterns Input Output Handling Functional Programming

P2P 的 NAT

NAT(网络地址转换)作为IPv4地址短缺的临时解决方案,通过将私有地址映射为公网地址缓解了网络扩展压力,但其设计缺陷已深刻影响现代网络架构。文章系统解析了NAT从宽松的全锥型到严格的对称型四类实现机制,揭示了不同转换策略对P2P通信的差异化影响——从全锥型下简单的地址互通,到对称型需多轮握手才能建立连接的复杂流程。特别指出在端口受限锥型与对称型组合场景中,P2P连接因地址竞争机制完全失效,这种设计矛盾暴露了NAT协议本质缺陷。尽管NAT在短期内延缓了IPv4枯竭危机,但其破坏TCP/IP原始设计原则,通过引入地址转换层增加网络复杂度,导致协议兼容性问题频发,更关键的是阻碍了IPv6的自然过渡。当NAT设备需维护庞大地址映射表应对海量P2P连接时,其脆弱性在DDoS攻击面前尤为明显。这种以牺牲协议简洁性换取地址扩展性的代价,最终迫使整个互联网陷入"技术债务"困境。NAT的兴衰史为网络协议设计提供了深刻启示:短期权宜之计可能带来长期结构性危机,当IPv6成为必然选择时,NAT的存续价值已引发关于网络演进路径的深层思考。--Qwen3

network NAT P2P Communications IPv4 Exhaustion Network Architecture Internet Protocol

How to fix some issues while using "diesel"

Diesel作为Rust的ORM框架在初用时可能遭遇系统依赖缺失的难题当遇到api-ms-win-crt系列dll文件缺失的错误提示时开发者会发现这些文件实际上存在于Windows系统目录中但需要手动复制到~/.cargo/bin路径才能被正确识别这种文件位置的隐性关联揭示了Windows生态中动态链接库的深层管理逻辑更值得关注的是使用sqlite数据库时diesel会因找不到sqlite3.lib而编译失败这个缺失的库文件需要从sqlite官网下载dll后通过开发者工具链生成lib文件并放置到rust工具链的特定位置这种跨语言绑定的复杂性暗示了Rust生态与传统C库的兼容性挑战文章通过具体案例展示了如何突破系统依赖的隐形壁垒但背后更值得思考的是:为什么现代编程语言的依赖管理依然需要开发者手动处理底层系统文件?当开发工具链与操作系统产生依赖断裂时我们是否应该重新审视软件分发的标准?在面对跨平台开发的复杂性时开发者社区能否建立更智能的依赖解析机制?这些未解之谜或许正是推动编程语言生态进化的关键动力--Qwen3

Rust rust-programming Diesel _DLLs Diesel ORM DLL Files

Leptos - CSR & SSR

Leptos作为全栈框架同时支持CSR和SSR两种渲染模式,其SSR实现通过"脱水-浸泡-湿润"的创新流程解决SEO难题。CSR模式通过静态文件部署带来便捷性但牺牲了搜索引擎可见性,而Leptos的SSR在服务器端完成首次渲染时仅保留关键元数据与文章信息,形成干瘪的脱水页面。当页面传输到客户端后,通过注入脚本进行浸泡处理,最终在浏览器内完成rehydrate过程激活完整交互。这种分阶段处理机制巧妙平衡了SEO需求与客户端性能,其核心在于Rust的features系统对Actix和Axum服务器代码的精准隔离。组件开发时需注意服务器端代码(如数据库访问)必须通过Server Functions机制暴露API接口,开发者需要在lib.rs中显式声明ssr特征模块。这种架构设计引发值得思考的问题:如何在多环境代码管理中避免依赖冲突?SSR流程的分阶段处理是否会影响首屏加载体验?当Server Functions需要处理复杂业务逻辑时,如何保证接口调用的可靠性?Leptos的实现方案揭示了现代Web框架的复杂权衡,其通过代码特征隔离实现的SSR机制,既展现了Rust语言的系统级能力,也提出了关于服务端渲染性能优化的新命题。--Qwen3

Rust Leptos Server Side Rendering Actix web Hydration Server Functions

Rust 和经典语言在习惯上的差异

Rust的编程习惯与C#等经典语言存在显著差异这种差异源于其独特的设计理念和安全机制在C#中开发者可以随意传递对象引用而无需关心所有权问题但Rust的所有权系统强制要求值的生命周期必须明确所有者这导致简单的赋值操作都会触发编译器的严格检查例如当一个String变量被传递给函数后原变量将失去所有权这种看似不便的机制实际上为内存安全提供了编译期保障但这也迫使开发者必须重新思考如何组织代码结构和数据流动 在抽象层面C#通过类的聚合特性自然地将属性与方法结合而Rust的单元结构体(struct;)提供了类似的抽象能力通过impl块定义方法开发者可以使用结构体名称作为命名空间调用方法(D::do_something())这种设计既避免了JS中方法定义的松散性又比C#的类定义更简洁但需要开发者主动构建这种抽象层级这可能与长期习惯直接在模块下定义方法的开发者产生认知冲突 Rust的类型系统则要求开发者频繁使用包装类型例如Arc<Mutex<Box<dyn Trait>>>这样的嵌套结构每个包装层都有明确的安全目的Box解决动态大小问题Mutex保障线程安全Arc实现跨线程共享这种必须显式声明的封装方式虽然增加了代码复杂度但确保了类型系统的安全性相比之下C#的接口返回无需考虑底层实现细节的差异暴露开发者需要思考如何在实际项目中平衡灵活性与安全性 当代码从C#迁移到Rust时开发者常会面临三个核心问题:如何重构原有代码以适应所有权转移的约束?如何通过结构体设计提升代码的可读性与可维护性?以及如何合理使用包装类型在性能与安全之间取得平衡?这些挑战背后隐藏着Rust设计哲学的深层思考——当编译器成为最严格的代码审查者时我们是否能在代码的每个细节中找到更本质的编程规律?--Qwen3

Rust memory-management Ownership System Smart Pointers Concurrency Thread Safety

Leptos - 撸一只赛博猫猫

Leptos正在用Rust重构前端开发的边界——无需JavaScript即可完成从界面交互到动画逻辑的完整实现。本文通过构建一个会喵叫会咕噜的赛博猫猫应用,展示了如何用Rust代码替代传统前端开发中的JavaScript角色。项目核心在于利用gloo库提供的BOM API接口,通过Rust代码直接操控浏览器功能,从事件监听到定时器调用都实现了无缝衔接。特别值得注意的是Interval时间函数的实现机制:通过周期性切换字符画数组的索引值,配合on_cleanup组件清理策略,既保证了动画流畅性又避免了内存泄漏风险。这种将Rust的系统级控制能力与Web前端开发结合的实践,不仅解决了传统JavaScript开发中常见的闭包陷阱,更在代码可维护性上展现出独特优势。当开发者用Rust的ownership模型管理浏览器资源时,是否正在打开一个全新的前端开发范式?在性能与开发效率之间,Rust+Leptos的组合能否突破传统前端框架的局限?或许这个会摇尾巴的赛博猫猫,正是通向未来Web开发的奇妙钥匙。--Qwen3

Rust Leptos gloo Cyber Cat Interval MouseEvent

从实现 Iterator 来窥探 Rust

这篇博客通过实现一个简单的 `Iterator` trait 展示了 Rust 语言中所有权机制与迭代器模式的结合方式。文章围绕 `Nums` 结构体展开,通过对比直接实现迭代器与间接借用结构体两种方案揭示了 Rust 设计哲学中的核心矛盾:如何在不污染结构体状态的前提下实现迭代能力。作者通过引入 `NumsIter` 中间结构体巧妙规避了状态污染问题,但这一设计却带来了生命周期管理的复杂性——`'a` 标注不仅保证了借用对象的存活时间,更构建了 Rust 内存安全的底层逻辑。文章揭示了 `&'a Nums` 这类借用语法的本质是所有权转移的逆向操作,通过生命周期标注解决了悬垂引用问题,这种将安全边界编码进类型的特性在其他语言中鲜有匹敌。在实现 `Iterator` 时,关联类型 `type Item` 的使用暗示了 Rust 类型系统的设计取舍:相比泛型参数的显式冗余,关联类型通过隐式绑定实现了更优雅的抽象。当读者看到 `next()` 方法的实现时,会自然思考:如果数据源不是固定数组而是动态生成的值,该模式能否适配?当迭代器需要同时处理多个借用对象时,生命周期标注又该如何演变?这些未解答的问题或许正是理解 Rust 所有权模型的关键切口。--Qwen3

Rust Iterator Pattern Lifetime Management Ownership and Borrowing Memory Safety Code Structure