Sessionを利用したForm認証

  • ページ: BugTrack2
  • 投稿者: umorigu
  • 優先順位: 低
  • 状態: 完了
  • カテゴリー: 本体新機能
  • 投稿日: 2016-01-21 (木) 01:41:51
  • バージョン: 1.5.0
  • リリース予定バージョン: 1.5.1

メッセージ

v1.5.0及び標準状態の認証方法はBasic認証のみである。認証方式の拡張性を高めるため、ユーザー名・パスワードをHTML Formで入力するForm認証を導入する。

一度ユーザー名・パスワードでログインした後は、Sessionによってその状態を維持する。

Sessionについて

動作仕様の変更

1.5.0のBasic認証の場合、ログイン状態(有効なユーザー名・パスワードの組み合わせを送信したリクエストの処理中)であっても、そのユーザーのアクセス権のないリソースへのアクセスが必要になったタイミングで 401 Unauthorized を返していた。ブラウザ上では認証情報を再入力するダイアログが表示される。 こうなるとBasic認証サインイン状態が解除されてしまう(アクセス権があったリソースへのアクセスも、再度パスワードの入力が必要になる)

また、Form認証では原理上同じ動作はできないため、この部分の動作を次のように変更する。

Basic認証の場合でも、有効ユーザー名・パスワードの組み合わせが送信されていれば、そのユーザーでのログイン状態を維持し、401 Unauthorized を返すことをしない。そのユーザーでのアクセス権限の無いリソースへアクセスした場合には「アクセス権がない」旨の表示を行う。

セキュリティの考慮

Basic認証ではリクエスト毎にユーザー名とパスワードが送信されるが、Sessionによるログイン状態の保持であればパスワードの送信は一度きりとなる。

Form認証であってもログイン状態でサイト上でできることは変わらないため、ブラウザとSessionを結びつけるキー(PHP session ID)はパスワードと同程度に秘匿する必要がある。セッションハイジャック等の攻撃に注意する。

対応

実行時設定 php.net:manual/ja/session.configuration.php

ini_set('session.use_strict_mode', 1);
ini_set('session.use_cookies', 1);
ini_set('session.use_only_cookies', 1);

$_SESSIONの扱い

  • ログイン時に session_regenerate_id(true)
  • ログアウト時に session_regenerate_id(true), $_SESSION = array(), session_destroy()

session_regenerate_id(true)を利用するため、session機能を使う場合は PHP5.1以降での動作が必要、とする。

Form認証を有効にする手順

  • 1. pukiwiki.ini.php にて
    $auth_type = AUTH_TYPE_FORM;
  • 2. $read_auth, $read_auth_pages, $edit_auth, $edit_auth_pages を適切に設定する(Basic認証時と同じ)
  • 3. WebブラウザでPukiWikiサイトを開き、$read_auth_pages で制限したページを表示する
  • 4. ユーザー名・パスワード入力Formが表示される

実装

osdn.jp:projects/pukiwiki/scm/git/pukiwiki/tree/branch_r1_5/


  • 機能的にはpukiwiki:自作プラグイン/login.inc.phpとほぼ同じ -- umorigu 2016-01-21 (木) 01:45:35
  • 対応しました branch_r1_5 -- umorigu 2016-01-21 (木) 05:58:32
  • このセッション認証が有効時にセッション未対応なブラウザでの動作はどうなっているのでしょう -- [[#rm -rf /]] 2016-01-22 (金) 10:46:05
  • セッション…正確にはCookieに対応していないクライアントでは動作しません。動作しないというのは、Formにパスワード入力してログインボタンを押すと、戻ったページでセッション(認証済み情報)を認識できず、再度パスワード入力Formを表示します。Cookieに対応していないクライアントのサポートが必要な場合はBasic認証を使うことになります。URLパラメータによるセッション維持は危険度が高いのでOFFにしています -- umorigu 2016-01-22 (金) 21:10:14
  • BugTrack2/63 session変数を追加してほしい (2005) -- henoheno 2016-01-24 (日) 22:59:52
  • コードのコミットの際、都度それぞれのBugTrack ページに、diffを気軽に参照するためのリンクを残すことを推奨します。なぜならば、気楽かつ高頻度な参照がし辛いようでは、他人(将来の自分を含む)に対する透明性が下がり、見落としの原因になるからです。強制ではありません。 -- henoheno 2016-01-24 (日) 23:03:54
  • 基本的に、あらゆる名前空間(関数、定数、グローバル変数)は先頭に冠詞 pkwk_ ないし PKWK_ を付けるべきです。なぜならば、他者のコードと名前が衝突する可能性が生じるからです。他者のコードとは、一部のグループウェアのように、PukiWikiを部品としてマージした場合の相手先を含みます。こちらも強制ではありません。 -- henoheno 2016-01-24 (日) 23:04:12
  • diffへのリンク→ご指摘の通りですね。残すようにします -- umorigu 2016-01-25 (月) 21:24:28
  • 接頭語のpkwkについては基本的には同意なのですが、既存コードとのバランスがより重要だと考えています。現状でほぼすべての関数がpkwk_無しのネーミングをされているので、pkwk_付きの関数は周辺コードとの調和がとりにくいです。また、仮に極端な例を考えるとして(カスタマイズ環境との関係で現実的ではないですが)関数すべてにpkwk_を付与するのは冗長になり可読性を損なうような気がしています。今後PukiWikiをモジュールとして取り込むようなプロダクトが現れるのであればそれは接頭語での区別よりもPHPネイティブのnamespaceを使ってくれると期待します -- umorigu 2016-01-25 (月) 22:21:49
  • plugin/loginform.inc.phpで未初期化(配列のキーが存在しない?)のNoticeエラーをキャッチしました。global $get, $post, $vars の初期化過程で設定される"page"以外のパラメータは危なさそうです。(スキンのリンクから飛んでくる場合は"url_after_login"が省略されており、"password"なども来ないはずなので) -- 2016-02-14 (日) 09:13:30
  • ご指摘ありがとうございます。issetでチェックして、未初期化Noticeが発生しないように対策しました -- umorigu 2016-02-15 (月) 21:18:05
  • ログイン失敗時「ユーザー名またはパスワードが違います」を表示するようにしました -- umorigu 2016-02-25 (木) 23:42:49


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2016-02-25 (木) 23:42:49
Site admin: PukiWiki Development Team

PukiWiki 1.5.2+ © 2001-2019 PukiWiki Development Team. Powered by PHP 5.6.40-0+deb8u7. HTML convert time: 0.198 sec.

OSDN