#66 BASIC認証下での「ログインしないとアクセス不可」設定の挙動について

icon written by Takashi Sugiyama at Feb 24, 2018 3:10 AM
  Edit(Sign in)
  Stock
  Answer survey   Answer survey

  TOC

いつもお世話になっております。

システム設定->システムの公開設定から、
「全ての機能には、ログインしないとアクセス不可」
をチェックした場合、ログインページを表示したとき(もちろん未ログイン状態)は、
HTTP応答コード401(認証エラー)が返る仕様かと存じます。

Chromeなどのブラウザではこの401の応答を受けると、
以前に保存したBASIC認証の情報が破棄される仕様となっているようで、この結果、

ログインページ要求->BASIC認証->OK->ログインページ(401)->
(ブラウザ保存認証情報クリア)->ログイン要求->BASIC認証 -> OK -> リストページ

というように、複数回BASIC認証を要求される事態を確認しています。
あまりニーズは無いと思いますが「全ての機能には、ログインしないとアクセス不可」
としたときのアクセス不可時HTTP応答を、200に変更する仕様・機能を考えています。

こちらの都合で改修に時間がかかりそうなので、何かの折に含めて頂けると助かるのですが、
そもそもこういう機能を標準に含めるかどうかいうところがあるので、
ご意見いただきたく存じます。

 Attach Files     - [0]


 Comment
[Registration] Feb 25, 2018 9:23 AM [Koda]
icon

こんにちは。
認証がエラー時に401を返すのは普通に思うので、それを200に変更するのはおかしいと感じます。
そして、認証の仕組みを持つシステムに、さらにその上にBasic認証をかけるのも変と感じます。
Knowledgeを修正するのではなく、その前のBasic認証をかける仕組みを解除するほうが良いのではないでしょうか?
たぶん、組織上の制約で、「それはわかっているけど、、、」という状況なのかもしれませんが、、、


 Like! × 0  
Collapsed
[Registration] Feb 26, 2018 2:00 AM [Takashi Sugiyama]
[Update] Feb 26, 2018 2:06 AM [Takashi Sugiyama]
icon

早速のご意見ありがとうございます。
認証エラー時の401動作については全くその通りで私も賛成です。

「それはわかっているけど、、、」という状況

そうなんですよね~・・・
共感して頂けて、開発者としてとても嬉しく思います。。。
BASIC認証と2段階あれば安心、と思っていても、
.htpasswdなんてほとんど更新しないから類推されやすいパスワードが
ずっと残ってて問題になったりするんですね・・・

フロント(Nginx)側でどうにかしようと色々試してみましたが、
応答コードを差し替えるのは可能なんですが、BASIC認証が返す401と
Knowledgeが返す401が絡み合ってしまうのでちょっと難しい感じでした。
(個別の静的サインインページも作ってみたんですがね・・・)

403 Forbiddenならブラウザも認証情報破棄しないでくれる気もしますが、
テストしてみないとわからない感じですね・・・403も意味がちょっと違いますし。

とりあえずこちらの環境では定数まわりのところ変えて対応しちゃうつもりですが、
うまいことしっくりくる実装が考えついたら見てもらおうかなと思っています。


 Like! × 0  
Collapsed
[Registration] Feb 26, 2018 11:27 PM [Koda]
icon

事情は、、、わかります :sweat:
自分の考える通りに自由に環境を構成できるのであれば、私もKowledgeを作らず、外部のSaaSを利用したでしょうし、、、

そんなわけで、開発の本流に上記の認証エラー時のステータスコードの変更をいれることは、しないほうが良いかなとは思いますが、
Kowledgeのソースを取得し、以下のように変更すれば、利用イメージに沿うのではと思います。

org.support.project.knowledge.filter.CloseAbleAuthenticationFilter

public void doFilter(ServletRequest servletrequest, ServletResponse servletresponse, FilterChain filterchain)
            throws IOException, ServletException {
        HttpServletResponse response = (HttpServletResponse) servletresponse;
        HttpServletResponseWrapper res = new HttpServletResponseWrapper(response) {
            @Override
            public void setStatus(int arg0) {
                if (arg0 == HttpStatus.SC_401_UNAUTHORIZED) {
                    super.setStatus(HttpStatus.SC_200_OK);
                } else {
                    super.setStatus(arg0);
                }
            }
        };
      :
      :

Knowledgeは勉強のために、フレームワークまで自作してみたので、コードは読みづらいかもしれません。
業務では車輪の再発明になるのでやらないことを、趣味なので試してみて理解を深めてみました。


 Like! × 0  
Collapsed
[Registration] Mar 2, 2018 1:25 AM [Takashi Sugiyama]
icon

なるほど・・・これならどこで401放り込まれても大丈夫ですね。。。

おかげさまで無事ビルド・テストできました。
403 Forbiddenならブラウザの認証情報破棄が発生しないことが確認できたので、
認証・認可のつじつまを合わせる意味で403にしました。
システム設定的な意味合いでweb.xmlに書いても良いかなとも思いました。

昔Strutsの拡張をしていましたが、このくらいの画面数のWebサービスだと
Strutsでもちょっとおおげさですよね。
voはちょっと懐かしい感じがしました(w

今回せっかく専用の環境作ったので、そのうち何かできたらいいなと思っています。


 Like! × 0  
Collapsed



 Add Comment