主页 / user-8776746

ynn's questions

Martin Hope
ynn
Asked: 2025-02-11 17:49:47 +0800 CST
  • 5

在 中bash，已知set -e在命令替换中被忽略（除非inherit_errexit被启用）。

但是，在false命令替换中执行命令时，set -e不会被忽略。为什么？

代码：

set -e
shopt | grep inherit_errexit

echo hello

a=$(false)

echo world

预期的：

inherit_errexit off
hello
world

实际的：

inherit_errexit off
hello

shell returned 1
bash
Martin Hope
ynn
Asked: 2025-01-19 12:52:01 +0800 CST
  • 5

基于浏览器的应用程序的RFC OAuth 2.0 草案（发布日期：2025 年 1 月 17 日）在 6.1 中引入了BFF 模式。前端的后端 (BFF)。

架构如下：

在此处输入图片描述

草案称

JavaScript 应用程序触发到 BFF（C）的导航，以使用 PKCE 扩展启动授权码流（如第 6.1.3.1 节所述），BFF 通过将浏览器重定向到授权端点（D）来做出响应。

当用户被重定向回来时，浏览器会将授权码传递给 BFF（E），然后 BFF 可以使用其客户端凭据和 PKCE 代码验证器在令牌端点（F）将其兑换为令牌。

这意味着 PKCE code_verifier，code_challenge并且code_challenge_method都是在服务器端计算和存储的，但是为什么呢？

我有三个问题：

  • 在步骤 (E) 中，客户端向后端发送授权码。但是，后端如何识别code_verifier此授权码是从哪里派生出来的？我认为没有办法，因为代码片段只显示在步骤 (E) 中发送了授权码。

  • 虽然草案中没有提到，但这个“如何识别代码验证器”的问题可以通过HttpOnly提前将临时会话作为 cookie 发出并让客户端在步骤 (E) 中发送来解决。我说得对吗？

  • 如果我是对的，那么为什么要使用临时会话（例如HttpOnlycookie）呢？我认为只需计算code_verifier和客户端就可以完全消除对临时会话的需求。在步骤 (E) 中，客户端除了授权码之外还可以向后端发送。code_challengecode_challenge_methodcode_verifier

oauth-2.0
Martin Hope
ynn
Asked: 2025-01-18 16:01:57 +0800 CST
  • 5

我已阅读完以下所有 RFC：

[3]建议基于浏览器的应用程序使用下列架构之一：

  • 后端用于前端 (BFF)，其中后端代理与 OAuth 2.0 相关的所有请求，包括对资源服务器的访问。客户端不会暴露任何（未加密的）令牌。

  • 令牌中介后端 (TMB)，其中只有后端存储刷新令牌，而访问令牌在客户端公开。

  • 基于浏览器的 OAuth 2.0 客户端，其中 OAuth 2.0 不涉及任何后端。每个令牌都暴露在客户端。

[3] 还特别推荐针对敏感应用采用 BFF 模式：

强烈建议商业应用程序、敏感应用程序和处理个人数据的应用程序采用此架构。

相反，[2]（在整个 RFC 中，特别是在第 4.1 节中）仅指 OAuth 2.0 中不涉及后端的架构，它在概念上对应于上面的基于浏览器的 OAuth 2.0 客户端模式。

但为什么呢？我有以下三个问题：

  • 是否建议对本机应用程序也使用 BFF 模式？

  • 是否有任何正式来源（例如另一个 RFC）来支持您的答案？

  • 为什么 [2] 没有提及 BFF 模式？ 或许是因为原生应用的执行环境比浏览器应用安全得多，在浏览器应用中攻击者可以注入并执行恶意的 JavaScript 代码。但我认为理论上也可以通过二进制补丁或内存编辑等技术对原生应用（尤其是桌面应用）做类似的事情。

oauth-2.0
Martin Hope
ynn
Asked: 2024-11-10 13:36:28 +0800 CST
  • 6

我预计以下代码无法编译，但它确实编译了（playground）：

fn main() {
    (0..3)
        .map(|i| {
            struct S {
                v: usize,
            }
            S { v: i }
        })
        .collect::<Vec<_>>();
}

我认为每个闭包调用都会定义一个新的结构类型（及其实例），因此结果不能作为某种单一类型的向量收集，但它似乎S不是那么本地。

这在底层是如何工作的？我想要严格的解释，比如指向 Rust 参考页面的链接，所以添加了#language-lawyer标签。

如果你在不了解 Rust 工作原理的情况下直接阅读上面的代码，我认为可以有两种解释，如下所示。我认为第二种解释是正确的，但代码编译的事实意味着第一种解释是正确的。但为什么呢？这就是我的问题。

解释1

//`S` is *global* in some sense.
struct S {
    v: usize,
}

//Every invocation of the closure just creates a new instance of the type `S`.
for i in 0..3 {
    vec.push(S { v: 0 });
}

解释2

{
    //Every invocation of the closure declares a new struct type
    // which is local to the invocation.
    struct __S_anonymous_01 {
        v: usize,
    }
    //And it then creates a new instance of that type.
    vec.push(__S_anonymous_01 { v: 0 });
}
{
    struct __S_anonymous_02 {
        v: usize,
    }
    vec.push(__S_anonymous_02 { v: 1 });
}
{
    struct __S_anonymous_03 {
        v: usize,
    }
    vec.push(__S_anonymous_03 { v: 2 });
}

//And `__S_anonymous_{01|02|03}` are all different
// though they have the same structure
// because Rust doesn't support duck typing.
rust
Martin Hope
ynn
Asked: 2024-11-03 00:06:19 +0800 CST
  • 6

此代码立即完成（操场）：

use std::sync::Mutex;

fn f(_: usize, _: usize) {}

fn main() {
    let m = Mutex::new(0);

    let i = { *m.lock().unwrap() };
    let j = { *m.lock().unwrap() };
    f(i, j);
}

此代码也立即完成（操场）：

use std::sync::Mutex;

fn f(_: usize, _: usize) {}

fn main() {
    let m = Mutex::new(0);

    f(
        {
            let i = *m.lock().unwrap();
            i
        },
        {
            let j = *m.lock().unwrap();
            j
        },
    );
}

我觉得这段代码在语义上与上面的代码相同，都是永久阻塞（playground）：

use std::sync::Mutex;

fn f(_: usize, _: usize) {}

fn main() {
    let m = Mutex::new(0);

    f({ *m.lock().unwrap() }, { *m.lock().unwrap() });
}

为什么？

rust