if (!requestManager.findUserBean(FessUserBean.class).map(user -> user.hasRoles(acceptedRoles)).orElse(Boolean.FALSE)) {
            response.sendError(HttpServletResponse.SC_UNAUTHORIZED, "Unauthorized access: " + request.getServletPath());
            return;
        }

        try {
            getSessionManager().getAttribute(Constants.SEARCH_ENGINE_API_ACCESS_TOKEN, String.class).ifPresent(token -> {

If it doesn't see an `Authorization` header, or the value doesn't have a `Bearer ` token, it will respond with a 401 status code error (`UNAUTHORIZED`) directly.

You don't even have to check if the token exists to return an error. You can be sure that if your function is executed, it will have a `str` in that token.

You can try it already in the interactive docs:

        /** Bad request status indicating client error. */
        BAD_REQUEST(1),
        /** System error status indicating server error. */
        SYSTEM_ERROR(2),
        /** Unauthorized status indicating authentication failure. */
        UNAUTHORIZED(3),
        /** General failure status. */
        FAILED(9);

        private final int id;

        Status(final int id) {
            this.id = id;
        }

///

## 무엇을 하는지 { #what-it-does }

요청에서 `Authorization` 헤더를 찾아, 값이 `Bearer `에 어떤 token이 붙은 형태인지 확인한 뒤, 그 token을 `str`로 반환합니다.

`Authorization` 헤더가 없거나, 값에 `Bearer ` token이 없다면, 곧바로 401 상태 코드 오류(`UNAUTHORIZED`)로 응답합니다.

오류를 반환하기 위해 token이 존재하는지 직접 확인할 필요조차 없습니다. 함수가 실행되었다면 그 token에는 `str`이 들어 있다고 확신할 수 있습니다.

대화형 문서에서 이미 시도해 볼 수 있습니다:

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

mechanisms that prevent unwanted access to the data from other tenants.

Network isolation between different models is also important not only to prevent
unauthorized access to data or models, but also to prevent malicious users or
tenants sending graphs to execute under another tenant’s identity.

The isolation mechanisms are the responsibility of the users to design and

/// info

The additional header `WWW-Authenticate` with value `Bearer` we are returning here is also part of the spec.

Any HTTP (error) status code 401 "UNAUTHORIZED" is supposed to also return a `WWW-Authenticate` header.

In the case of bearer tokens (our case), the value of that header should be `Bearer`.

You can actually skip that extra header and it would still work.

///

## 它做了什麼 { #what-it-does }

它會從請求中尋找 `Authorization` 標頭，檢查其值是否為 `Bearer ` 加上一段 token，並將該 token 以 `str` 回傳。

若未找到 `Authorization` 標頭，或其值不是 `Bearer ` token，則會直接回傳 401（`UNAUTHORIZED`）錯誤。

你不必再自行檢查 token 是否存在；你可以確信只要你的函式被執行，該 token 參數就一定會是 `str`。

你可以在互動式文件中試試看：

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

我們還沒驗證 token 是否有效，但這已是個開始。

## 小結 { #recap }

///

## 它做了什么 { #what-it-does }

它会在请求中查找 `Authorization` 请求头，检查其值是否为 `Bearer ` 加上一些令牌，并将该令牌作为 `str` 返回。

如果没有 `Authorization` 请求头，或者其值不包含 `Bearer ` 令牌，它会直接返回 401 状态码错误（`UNAUTHORIZED`）。

你甚至无需检查令牌是否存在即可返回错误；只要你的函数被执行，就可以确定会拿到一个 `str` 类型的令牌。

你已经可以在交互式文档中试试了：

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

我们还没有验证令牌是否有效，但这已经是一个良好的开端。

## 小结 { #recap }

因此，在端點中，只有在使用者存在、已正確驗證且為啟用狀態時，我們才會取得使用者：

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

/// info

這裡我們一併回傳值為 `Bearer` 的額外標頭 `WWW-Authenticate`，這也是規範的一部分。

任何 HTTP（錯誤）狀態碼 401「UNAUTHORIZED」都應該同時回傳 `WWW-Authenticate` 標頭。

在 bearer tokens（我們的情況）下，該標頭的值應該是 `Bearer`。

其實你可以省略這個額外標頭，功能仍會正常。

但此處加上它是為了遵循規範。

同時也可能有工具會期待並使用它（現在或未來），而這可能對你或你的使用者有幫助，現在或未來皆然。

這就是標準的好處...

///

因此，在端点中，只有当用户存在、通过身份验证、且状态为激活时，才能获得该用户：

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

/// info | 信息

此处返回值为 `Bearer` 的响应头 `WWW-Authenticate` 也是规范的一部分。

任何 401“UNAUTHORIZED”HTTP（错误）状态码都应返回 `WWW-Authenticate` 响应头。

本例中，因为使用的是 Bearer Token，该响应头的值应为 `Bearer`。

实际上，忽略这个附加响应头，也不会有什么问题。

之所以在此提供这个附加响应头，是为了符合规范的要求。

说不定什么时候，就有工具用得上它，而且，开发者或用户也可能用得上。

这就是遵循标准的好处...