Observe que em nenhuma parte do código está a senha em texto puro "`secret`", nós temos apenas o hash.

///

<img src="/img/tutorial/security/image08.png">

Chame o endpoint `/users/me/`, você receberá o retorno como:

```JSON
{
  "username": "johndoe",
  "email": "******@****.***",
  "full_name": "John Doe",
  "disabled": false
}
```

<img src="/img/tutorial/security/image09.png">

* Documentação automática de modelos de dados com [**JSON Schema**](https://json-schema.org/) (já que o OpenAPI em si é baseado no JSON Schema).
* Projetado em torno desses padrões, após um estudo meticuloso. Em vez de uma camada improvisada por cima.
* Isso também permite o uso de **geração de código do cliente** automaticamente em muitas linguagens.

/// info | Informação

Isso está disponível com a versão 2 do Pydantic ou superior. 😎

///

/// tip | Dica

Se você precisar fazer qualquer tipo de validação que exija comunicação com algum componente externo, como um banco de dados ou outra API, você deveria usar Dependências do FastAPI em vez disso; você aprenderá sobre elas mais adiante.

/// info | Información

Esto está disponible con Pydantic versión 2 o superior. 😎

///

/// tip | Consejo

Si necesitas hacer cualquier tipo de validación que requiera comunicarte con algún componente externo, como una base de datos u otra API, deberías usar Dependencias de FastAPI, las aprenderás más adelante.

Estos validadores personalizados son para cosas que pueden comprobarse solo con los mismos datos provistos en el request.

///

## Resumen { #recap }

Tener **HTTPS** es muy importante y bastante **crítico** en la mayoría de los casos. La mayor parte del esfuerzo que como desarrollador tienes que poner en torno a HTTPS es solo sobre **entender estos conceptos** y cómo funcionan.

### Dependências { #dependencies }

O mesmo se aplica para as [dependências](tutorial/dependencies/index.md). Se uma dependência tem as funções com padrão `def` ao invés de `async def`, ela é rodada no threadpool externo.

### Sub-dependências { #sub-dependencies }

**incrementalmente**, adicionando **uma camada em cima da outra**, começando do topo do `Dockerfile` e adicionando qualquer arquivo criado por cada uma das instruções do `Dockerfile`.

Docker e ferramentas similares também usam um **cache interno** ao construir a imagem, se um arquivo não mudou desde a última vez que a imagem do contêiner foi construída, então ele irá **reutilizar a mesma camada** criada na última vez, ao invés de copiar o arquivo novamente e criar uma nova camada do zero....

pkg syscall (linux-386), const ELNRNG Errno
pkg syscall (linux-386), const EMEDIUMTYPE Errno
pkg syscall (linux-386), const EMULTIHOP Errno
pkg syscall (linux-386), const ENAVAIL Errno
pkg syscall (linux-386), const ENOANO Errno
pkg syscall (linux-386), const ENOCSI Errno
pkg syscall (linux-386), const ENODATA Errno
pkg syscall (linux-386), const ENOKEY Errno
pkg syscall (linux-386), const ENOLINK Errno

pkg syscall (linux-386), const ENETDOWN = 100
pkg syscall (linux-386), const ENETRESET = 102
pkg syscall (linux-386), const ENETUNREACH = 101
pkg syscall (linux-386), const ENFILE = 23
pkg syscall (linux-386), const ENOANO = 55
pkg syscall (linux-386), const ENOBUFS = 105
pkg syscall (linux-386), const ENOCSI = 50
pkg syscall (linux-386), const ENODATA = 61
pkg syscall (linux-386), const ENODEV = 19

pkg syscall (linux-arm-cgo), const EMEDIUMTYPE Errno
pkg syscall (linux-arm-cgo), const EMULTIHOP Errno
pkg syscall (linux-arm-cgo), const ENAVAIL Errno
pkg syscall (linux-arm-cgo), const ENOANO Errno
pkg syscall (linux-arm-cgo), const ENOCSI Errno
pkg syscall (linux-arm-cgo), const ENODATA Errno
pkg syscall (linux-arm-cgo), const ENOKEY Errno
pkg syscall (linux-arm-cgo), const ENOLINK Errno