Docs

Playground

GitHub

DocsServidor

Segurança & Server Actions

Editar esta página

4 min de leitura

O eQuantic.UI facilita a comunicação entre cliente e servidor através das Server Actions, garantindo que essa ponte seja segura por padrão.

⚡ Server Actions

Uma Server Action é um método C# definido num componente que pode ser invocado diretamente do browser. O compilador gera automaticamente a ponte de chamada (Fetch API) e o middleware do servidor resolve a execução.

Exemplo:

[ServerAction]

[Authorize(Roles = "Admin")]

public async Task<bool> DeleteUser(Guid userId) {

// Lógica executada apenas no servidor

}

🔒 Uma página que exige autorização

Desde 0.2.0-preview.61

[Page("/backoffice/queue")]

[Authorize(Policy = "Backoffice")]

public sealed class VerificationQueuePage : StatefulComponent, IServerPrefetch { … }

Os mesmos [Authorize] e [AllowAnonymous] que uma Server Action recebe protegem uma página. A rota dela os leva como metadados do endpoint, como o RequireAuthorization faria, então a autorização do ASP.NET Core decide com os esquemas e as políticas que o app configurou (AddAuthentication, AddAuthorization):

•

um carregamento completo anônimo é desafiado pelo esquema padrão, o redirecionamento do OpenID Connect para entrar, por exemplo;

•

um visitante autenticado sem a política recebe 403;

•

uma navegação cliente para a página recebe um 401 ou um 403 no lugar da página, e o roteador então carrega a rota por inteiro, para que o desafio ou o 403 aconteça como em qualquer visita;

•

um pedido recusado nunca chega à página: o IServerPrefetch dela não roda, e nenhum dos seus campos é escrito no HTML.

[Authorize] sem política pede só um visitante autenticado. Sob uma FallbackPolicy do app inteiro, uma página marcada com [AllowAnonymous] (a página de entrada) continua servindo, e o runtime e os módulos de página de que ela precisa também. Um [Authorize] na classe protegia só as Server Actions da página; agora protege a página também.

As páginas de 404 e de 500 que um app registra respondem à mesma pergunta antes de serem desenhadas no lugar de uma rota, como as rotas delas respondem: uma página que não declara requisito fica sob a FallbackPolicy, o pedido é o recurso da política, e uma página que o visitante não pode ver não é desenhada, nem o IServerPrefetch dela roda.

🛡️ Camadas de proteção

1. Autorização (RBAC)

O eQuantic.UI suporta os atributos [Authorize] e [AllowAnonymous].

•

O ServerActionsMiddleware verifica se o usuário atual tem as permissões necessárias antes de invocar o método.

•

Se a autorização falhar, o servidor devolve 403 Forbidden ou 401 Unauthorized, bloqueando a execução da lógica de negócio.

2. Validação de payload

Para prevenir ataques de injeção e consumo excessivo de recursos:

•

Limite de tamanho: o middleware impõe limites estritos ao tamanho do corpo da requisição.

•

Whitelist de tipos: a desserialização de argumentos é restrita a tipos conhecidos e seguros, prevenindo ataques de desserialização insegura.

3. Registro de ações

Apenas métodos explicitamente marcados com [ServerAction] podem ser invocados. Não é possível chamar qualquer método público arbitrário via API, o que mantém a superfície de ataque controlada.

4. De onde veio a requisição

Desde 0.2.0-preview.61

Uma Server Action recusa a requisição que a página de outro site envia, antes de ler qualquer parte dela. O navegador diz de onde veio a requisição, e o endpoint responde 403 Forbidden quando:

•

o Origin não é o host da própria app nem uma origem que a app permite, incluindo o Origin: null opaco;

•

não há Origin, e o Sec-Fetch-Site diz cross-site ou same-site.

Uma requisição sem nenhum dos dois cabeçalhos não vem de um navegador, e é executada. O host da própria app é o Host da requisição: atrás de um proxy que o reescreve, o app.UseForwardedHeaders() o restaura a partir dos proxies em que a app confia, e um X-Forwarded-Host cru nunca é lido. Comparam-se o host e a porta, não o esquema, e um Host sem porta vale pela porta padrão da origem, então uma app atrás de um proxy que termina o TLS não precisa de configuração.

Uma página servida de outro domínio que não o das suas ações lista essa origem, no appsettings.json: