85

Webページでは、YUI接続マネージャー/データソースを使用してAJAXリクエストをサーバーに送信します。セッション（ユーザーが認証されているかどうかに関する情報を含む）がすでにタイムアウトしている場合、認証されたユーザーのみが表示できるajax応答ユーザーはhttpステータスコードを返し、セッションがすでにタイムアウトになったことをクライアントに通知する必要があります。その後、クライアントは単にログインページにリダイレクトするか、セッションを延長するかどうかを尋ねます。

私の質問は、この状況で、セッションがタイムアウトしたことをクライアントに伝えるのに最も適切なhttpステータスコードはどれかということです。

wikiからのHTTPステータスコードのリスト

4

11 に答える 11

71

Best I can suggest is a HTTP 401 status code with a WWW-Authenticate header.

The problem with 403 requests is the the RFC 2616 states "Authorization will not help and the request SHOULD NOT be repeated." (i.e. doesn't matter if you are authenticated or not, you are not going to get access to that resource, ever).

The problem with 401 requests is it states they "MUST include a WWW-Authenticate header field". As someone has noted it doesn't appear to be in violation of the spec to use a custom value in a WWW-Authenticate header.

I can't see any reason in RFC 2617 why an HTTP 401 status combined with a custom WWW-Authenticate header like this wouldn't be okay:

WWW-Authenticate: MyAuthScheme realm="http://example.com"

The oAuth spec actually seems to do just this, as they recommend this (though they have to my mind an odd interpretation of the RFC):

WWW-Authenticate: OAuth realm="http://server.example.com/"

This doesn't appear to be specifically SANCTIONED by the RFC, but I can't actually see that it's forbidden by it (it doesn't seem to conflict with any MUST or MUST NOT, SHOULD or SHOULD NOT condition).

I wish there was a more specific HTTP status code for timeouts and for things like CSRF tokens being invalid so this was clearer.

于 2012-04-13T04:40:45.303 に答える
39

HTTP401をお勧めします。

403は基本的に「許可されていない、離れて戻ってこない」と言っているのに対し、401は「IDを持ってこなかったので許可されているかどうかはわかりません。行きます。入手して再試行してください。」

ウィキペディアの定義を比較してください：

HTTP 403-リクエストは正当なリクエストでしたが、サーバーはそれに応答することを拒否しています。

HTTP 401 - Similar to 403 Forbidden, but specifically for use when authentication is possible but has failed or not yet been provided.

于 2012-03-02T20:22:33.410 に答える
19

What about 419 - it is not standard, but the description on Wikipedia seems to fit:

419 Authentication Timeout

Not a part of the HTTP standard, 419 Authentication Timeout denotes that previously valid authentication has expired. It is used as an alternative to 401 Unauthorized in order to differentiate from otherwise authenticated clients being denied access to specific server resources.

于 2013-06-21T15:16:10.733 に答える
13

適切なコードは403/Forbiddenになると思います。セッションに直接関係するものはありません。

于 2009-10-31T05:35:05.773 に答える
12

As per the Wikipedia link of Http Status Codes provided above by Bobo:

440 Login Timeout (Microsoft)

    A Microsoft extension. Indicates that your session has expired.
于 2014-03-18T15:45:47.620 に答える
12

As you post a link, in that link i found this HTTP status code 440. you can use 440 HTTP status code for session expired.

440 Login Time-out

 The client's session has expired and must log in again.

401 Unauthorized we can use when, user login credential is wrong. or auth token passed in header is invalid.

403 Forbidden we can use this when user does not has specific permission for requested resource.

So in my opinion we should use 440 Login Time-out.

于 2018-09-21T05:47:48.467 に答える
9

真実は、セッションタイムアウトの標準HTTPステータスコードはありません。セッションは、HTTPトランスポート層ではなく、アプリケーション層に実装されます。

Microsoftがセッションタイムアウトに使用しているカスタムステータスコードがあります：599、または単に5xxの範囲で独自のステータスコードを作成します。

ステータスコードWikiから：

599ネットワーク接続タイムアウトエラー（不明）このステータスコードはRFCで指定されていませんが、Microsoft Corp. HTTPプロキシによって使用され、プロキシの背後にあるネットワーク接続タイムアウトをプロキシの前にあるクライアントに通知します。

セッションタイムアウトにカスタムステータスコード599を使用し、AJAX応答で確認します。

于 2012-11-29T19:40:39.860 に答える
4

Technically, the accepted answer is of course correct: If you already know for sure that you are going to be failing the request, and you are asking which failure code to return, then HTTP 401 "Unauthorized (Unauthenticated)" is the appropriate one, so as to prompt re-authentication.

But first of all, ask yourself: should you fail the request?

Consider that the user may simply be visiting a public page of your website, in which case you are going to be slapping them across the face with an "Unauthorized!" message, and requiring them to re-authenticate, in order to see a page that they would normally be able to see without authentication. That's not cool.

My advice is to ignore the fact that the session token is unknown, and simply proceed to generate a new session token and create a new session for it. The initial state of the session will of course be "not-yet-authenticated", so if the user is trying to access a non-public page, then the page will see to it that they receive an HTTP 401 "Unauthorized (Unauthenticated)" and must authenticate. But if the user lands on a public page, they won't notice anything different.

于 2017-04-17T22:08:47.140 に答える
-1

I would use a 302 redirection response, with a "Location" header directing to a resource path like "/auth-required"

The client could route the resource path to a modal with a login/password form, avoiding to tranfer the user to another page.

于 2019-02-11T19:24:30.470 に答える
-2

For non-Ajax requests, I use a 302 redirect.

For Ajax requests, I use 200 for known errors. That way I can take advantage of the data object. I find the data object easier to work with than parsing jqXHR for info. And then I don't need to worry about what HTTP status code to try to re-purpose for my situation.

jQuery Example:

$.ajax({
    //send data to server
})
.done(function(data, textStatus, jqXHR) {
    if (data.success) {
        //then process return data
    }
    else {
        //get error type or message from data object
        //could use custom error codes
    }
})
.fail(function(jqXHR, textStatus, errorThrown) {
    //handle unknown errors
});
于 2013-06-10T05:15:18.893 に答える
-4

コード408。「リクエストタイムアウト」は完璧のようです-RFC2616はそれが意味することを説明しています

サーバーが待機する準備ができている時間内に、クライアントは要求を生成しませんでした。

つまり、必要に応じて、まさに「タイムアウト」になります。

于 2009-10-31T05:27:50.367 に答える