Em bash, sabe-se que set -eele é ignorado em substituições de comando (a menos que inherit_errexitesteja habilitado).
Entretanto, quando falsecommand é executado em substituição de comando, set -eNÃO é ignorado. Por quê?
Código:
set -e
shopt | grep inherit_errexit
echo hello
a=$(false)
echo world
Esperado:
inherit_errexit off
hello
world
Real:
inherit_errexit off
hello
shell returned 1
O rascunho RFC OAuth 2.0 para aplicativos baseados em navegador (publicado: 17 de janeiro de 2025) introduz o padrão BFF em 6.1. Backend para frontend (BFF) .
Aqui está a arquitetura:
O rascunho diz
o aplicativo JavaScript aciona uma navegação para o BFF (C) para iniciar o fluxo do Código de Autorização com a extensão PKCE (descrita na Seção 6.1.3.1), ao qual o BFF responde redirecionando o navegador para o ponto de extremidade de autorização (D).
Quando o usuário é redirecionado de volta, o navegador entrega o código de autorização ao BFF (E), onde o BFF pode então trocá-lo por tokens no ponto de extremidade do token (F) usando suas credenciais de cliente e o verificador de código PKCE.
Isso implica PKCE code_verifier, code_challengee code_challenge_methodtodos são calculados e armazenados no lado do servidor, mas por quê?
Tenho três perguntas:
No passo (E), o cliente envia um código de autorização para o backend. No entanto, como o backend pode identificar de onde code_verifieresse código de autorização foi derivado? Acho que não tem como, porque o snippet não lê nada além de um código de autorização enviado no passo (E).
Embora não mencionado no rascunho, esse problema de "como-identificar-o-verificador-de-código" pode ser resolvido emitindo uma sessão temporal como HttpOnlycookie com antecedência e deixando o cliente enviá-la na etapa (E). Estou certo?
Se eu estiver correto, por que se preocupar em usar sessão temporal (como HttpOnlycookie)? Acho que apenas calcular code_verifier, code_challengee code_challenge_methodo lado do cliente removeria completamente a necessidade de sessão temporal. Na etapa (E), o cliente pode enviar, code_verifieralém disso, um código de autorização para o backend.
Li todos os seguintes RFCs:
[2]: RFC 8252: OAuth 2.0 para aplicativos nativos (observe que isso inclui não apenas aplicativos móveis, mas também aplicativos de desktop.)
[3]: rascunho RFC: OAuth 2.0 para aplicativos baseados em navegador
[3] recomenda o uso de uma das seguintes arquiteturas para aplicações baseadas em navegador:
Backend For Frontend (BFF), no qual o backend faz proxy de todas as solicitações relacionadas ao OAuth 2.0, incluindo acesso a servidores de recursos. Nenhum token (não criptografado) é exposto no lado do cliente.
Token-Mediating Backend (TMB), no qual apenas o backend armazena tokens de atualização, enquanto os tokens de acesso são expostos no lado do cliente.
Cliente OAuth 2.0 baseado em navegador, no qual nenhum backend é envolvido no OAuth 2.0. Cada token é exposto no lado do cliente.
[3] também recomenda o padrão BFF especialmente para aplicações sensíveis:
Essa arquitetura é altamente recomendada para aplicativos comerciais, aplicativos confidenciais e aplicativos que lidam com dados pessoais.
Pelo contrário, [2] (em todo o RFC, mas especialmente na Seção 4.1 ) refere-se apenas à arquitetura onde nenhum backend está envolvido no OAuth 2.0, o que corresponde conceitualmente ao padrão de cliente OAuth 2.0 baseado em navegador acima.
Mas por quê? Tenho essas três perguntas:
É recomendado usar o padrão BFF também para aplicativos nativos?
Existe alguma fonte formal (como outro RFC) para apoiar sua resposta?
Por que [2] não se refere ao padrão BFF? Talvez a razão seja que o ambiente de execução de aplicativos nativos é muito mais seguro do que o de aplicativos baseados em navegador, nos quais os invasores podem injetar e executar códigos JavaScript maliciosos, mas acho que teoricamente também é possível fazer coisas semelhantes para aplicativos nativos (especialmente para aplicativos de desktop) por técnicas como patching binário ou edição de memória.
Eu esperava que o código a seguir não compilasse, mas ele compilou ( playground ):
fn main() {
(0..3)
.map(|i| {
struct S {
v: usize,
}
S { v: i }
})
.collect::<Vec<_>>();
}
Pensei que cada chamada de fechamento definiria um novo tipo de struct (e sua instância), então o resultado não poderia ser coletado como um vetor de algum tipo único, mas parece que Snão é tão local.
Como isso funciona exatamente nos bastidores? Quero uma explicação rigorosa, como um link para uma página de The Rust Reference , então adicionei #language-lawyeruma tag.
Se você literalmente ler o código acima sem saber como o Rust funciona, acho que pode haver duas interpretações, como mostrado abaixo. Achei que a segunda interpretação estava correta, mas o fato de o código compilar implica que a primeira está correta. Mas por quê? Essa é a minha pergunta.
Interpretação 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 });
}
Interpretação 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.
Este código é concluído imediatamente ( playground ):
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);
}
Este código também é concluído imediatamente ( playground ):
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
},
);
}
Este código, que eu acho que é semanticamente o mesmo que os códigos acima, bloqueia para sempre ( playground ):
use std::sync::Mutex;
fn f(_: usize, _: usize) {}
fn main() {
let m = Mutex::new(0);
f({ *m.lock().unwrap() }, { *m.lock().unwrap() });
}
Por que?