E também pode ser usada por você mesmo, para depurar, verificar e testar a mesma aplicação.

## O fluxo de `password` { #the-password-flow }

Agora vamos voltar um pouco e entender o que é isso tudo.

O "fluxo" `password` é uma das formas ("fluxos") definidas no OAuth2 para lidar com segurança e autenticação.

O OAuth2 foi projetado para que o backend ou a API pudesse ser independente do servidor que autentica o usuário.

///

### [APIStar](https://github.com/encode/apistar) (<= 0.5) { #apistar-0-5 }

Pouco antes de decidir construir o **FastAPI** eu encontrei o servidor **APIStar**. Ele tinha quase tudo o que eu estava procurando e tinha um ótimo design.

Ao usar os clientes gerados automaticamente, você terá **preenchimento automático** para:

* Métodos.
* Corpos de requisições, parâmetros de query, etc.
* Corpos de respostas.

Você também terá **erros em linha** para tudo.

E sempre que você atualizar o código do backend e **regenerar** o frontend, ele terá quaisquer novas *operações de rota* disponíveis como métodos, as antigas removidas, e qualquer outra alteração será refletida no código gerado. 🤓

### Deletar um Hero Novamente { #delete-a-hero-again }

**Deletar** um hero permanece praticamente o mesmo.

Não vamos satisfazer o desejo de refatorar tudo neste aqui. 😅

{* ../../docs_src/sql_databases/tutorial002_an_py310.py ln[96:103] hl[101] *}

### Executar o App Novamente { #run-the-app-again }

Você pode executar o app novamente:

<div class="termy">

* Faça uma tradução nova deste documento para o seu idioma de destino (veja, por exemplo, o comando `translate-page` do `translate.py`). Isso criará a tradução em `docs/{language code}/docs/_llm-test.md`.
* Verifique se está tudo certo na tradução.
* Se necessário, melhore seu prompt específico do idioma, o prompt geral ou o documento em inglês.
* Em seguida, corrija manualmente os problemas restantes na tradução, para que fique uma boa tradução.

Ambas as dependências retornarão apenas um erro HTTP se o usuário não existir ou se estiver inativo.

Portanto, em nosso endpoint, só obteremos um usuário se o usuário existir, tiver sido autenticado corretamente e estiver ativo:

{* ../../docs_src/security/tutorial003_an_py310.py hl[58:66,69:74,94] *}

/// info | Informação

Você pode ter qualquer combinação de dependências que você quiser.

O **FastAPI** se encarrega de executá-las na ordem certa.

/// note | Detalhes Técnicos

Tudo isso funciona graças aos [gerenciadores de contexto](https://docs.python.org/3/library/contextlib.html) do Python.

O **FastAPI** utiliza eles internamente para alcançar isso.

///

/// tip | Dica

A coisa importante e "mágica" aqui é que `get_current_user` terá diferentes listas de `scopes` para validar para cada *operação de rota*.

Tudo depende dos `scopes` declarados em cada *operação de rota* e cada dependência da árvore de dependências para aquela *operação de rota* específica.

///

No GitHub, o template vai orientar você a escrever a pergunta certa para que você consiga obter uma boa resposta com mais facilidade, ou até resolver o problema sozinho antes de perguntar. E no GitHub eu consigo garantir que sempre vou responder tudo, mesmo que leve algum tempo. Eu pessoalmente não consigo fazer isso com os sistemas de chat. 😅

Depois atribuímos esses dois valores da tupla às variáveis `id` e `name`.

Assim, se o usuário não fornecer um ID de item, ele ainda receberá uma sugestão aleatória.

...fazemos tudo isso em uma única linha simples. 🤯 Você não ama Python? 🐍

{* ../../docs_src/query_params_str_validations/tutorial015_an_py310.py ln[22:30] hl[29] *}

## Recapitulando { #recap }