Bug(バグ) #1977
Web API の認証エラー時のHTTPレスポンスヘッダーが200となっている
Start date:
2011-03-26
Due date:
% Done:
100%
3.6 で発生するか:
Yes (はい)
3.8 で発生するか:
Unknown (未調査)
Description
現象¶
認証が通っていない環境から以下のようなコマンドを叩くと
本来はレスポンスで 401 もしくは 403 のHTTPヘッダが一行目に返ってくるはずが
200 のレスポンスが返ってきている
$ curl -I http://sns.example.com/api.php/feeds/member/1 HTTP/1.1 200 OK Date: Fri, 25 Mar 2011 19:53:38 GMT
原因¶
認証失敗時のHTTPヘッダの一行目の記述がない
修正内容¶
lib/filter/opAPISecurityFilter.class.php の 51行目にてステータスコード等を出力しているが
ヘッダー出力ではないため、上記の記述を他のヘッダー出力の前に「ヘッダー」出力する
Related issues
Associated revisions
(fixes #1977) added send status code before send other httpHeaders in opAPISecurityFilter
(fixes #1977) use sfWebResponse::sendHttpHeaders() instead of header() and undo remove response body
History
#1
Updated by Shingo Yamada over 9 years ago
- Assignee set to Shingo Yamada
#2
Updated by Maki Takahashi almost 9 years ago
- Status changed from New(新規) to Pending Review(レビュー待ち)
- % Done changed from 0 to 50
更新履歴 c50557e901d77633db2b1812b2c7041a3ca045c5 で適用されました。
#3
Updated by Maki Takahashi almost 9 years ago
- Assignee changed from Shingo Yamada to Maki Takahashi
- 3.6 で発生するか set to Unknown (未調査)
- 3.4 で発生するか set to Unknown (未調査)
#4
Updated by Maki Takahashi almost 9 years ago
- 3.6 で発生するか changed from Unknown (未調査) to Yes (はい)
- 3.4 で発生するか changed from Unknown (未調査) to Yes (はい)
curlコマンドではなぜか404エラーとなってしまうため、telnetにて確認しました。
telnet sns.example.com 80 GET /api.php/feeds/member/1 HTTP/1.1 Host: sns.example.com
HTTP/1.1 200 OK === (省略) === 401 Unauthorized
#5
Updated by Maki Takahashi almost 9 years ago
- Description updated (diff)
#6
Updated by Kousuke Ebihara almost 9 years ago
- Status changed from Pending Review(レビュー待ち) to Rejected(差し戻し)
- 修正前のコードにも言えることですが、自前で
header()
関数をコールするよりもsfWebResponse::sendHttpHeaders()
をコールする形にするのが望ましいです。- その場合、
Content-Type
ヘッダが新たに出力されるようになると思われます。この値はtext/html
がデフォルトです。 OpenPNE Web API、 Google Data API、 Atom Publishing Protocol (RFC 5023) の仕様書のいずれにもエラー時のレスポンスの Content-Type についての記述がありません。text/plain
を採用するのが妥当かもしれませんね。
- その場合、
- レスポンスボディへのステータスコードの出力が削除されていますが、これはなぜでしょうか。 RFC 5023 の "5.5. Use of HTTP Response Codes" http://tools.ietf.org/html/rfc5023#section-5.5 には、以下のような記述があります。
Implementers are asked to note that according to the HTTP specification, HTTP 4xx and 5xx response entities SHOULD include a human-readable explanation of the error. (拙訳)HTTP 仕様に基づき、 HTTP 4xx と 5xx のレスポンスエンティティは human-readable なエラーの説明を含むべき (SHOULD) であることに注意することが実装者に求められている。
要求レベルが RFC 2119 で定められた SHOULD であるので、この仕様に反した実装をするからには、仕様を退けるべき妥当な理由が必要だと考えます。- また、この変更は、仕様に反しているだけでなく、互換性の観点からも問題があると考えています。この修正以前はステータスコードからエラーであるかどうかの判断がおこなえなかったわけですから、レスポンスボディからステータスコードを得て、エラーについての判別をおこなっていた可能性が充分に考えられます。これのレスポンスボディは利便のための配慮で、 RFC 5023 においてさえも明示された仕様ではないため、この変更をおこなうことにより意図した挙動をおこなわなくなるようなアプリケーションは、そのアプリケーション側で修正をおこなうべきと言えるとは思います。とはいえ、特段理由がないのならば後方互換性を保つような実装を維持するのが妥当だと考えます
#7
Updated by Maki Takahashi almost 9 years ago
- Status changed from Rejected(差し戻し) to Pending Review(レビュー待ち)
更新履歴 6a717dbea7857a13095033077f68f6416d180ec3 で適用されました。
#8
Updated by Kousuke Ebihara almost 9 years ago
- Status changed from Pending Review(レビュー待ち) to Pending Testing(テスト待ち)
- % Done changed from 50 to 70
#9
Updated by Yuma Sakata almost 9 years ago
- Status changed from Pending Testing(テスト待ち) to Fixed(完了)
- % Done changed from 70 to 100
テストOKです。
#10
Updated by kaoru n over 5 years ago
- 3.8 で発生するか set to Unknown (未調査)