* Sessionを利用したForm認証 [#xdced4f0] - ページ: [[BugTrack2]] - 投稿者: [[umorigu]] - 優先順位: 低 - 状態: 完了 - カテゴリー: 本体新機能 - 投稿日: 2016-01-21 (木) 01:41:51 - バージョン: 1.5.0 - リリース予定バージョン: 1.5.1 ** メッセージ [#s4122278] v1.5.0及び標準状態の認証方法はBasic認証のみである。認証方式の拡張性を高めるため、ユーザー名・パスワードをHTML Formで入力するForm認証を導入する。 一度ユーザー名・パスワードでログインした後は、Sessionによってその状態を維持する。 ** Sessionについて [#e00a207c] - [[php.net:manual/ja/book.session.php]] ** 動作仕様の変更 [#h42b2786] 1.5.0のBasic認証の場合、ログイン状態(有効なユーザー名・パスワードの組み合わせを送信したリクエストの処理中)であっても、そのユーザーのアクセス権のないリソースへのアクセスが必要になったタイミングで 401 Unauthorized を返していた。ブラウザ上では認証情報を再入力するダイアログが表示される。 こうなるとBasic認証サインイン状態が解除されてしまう(アクセス権があったリソースへのアクセスも、再度パスワードの入力が必要になる) また、Form認証では原理上同じ動作はできないため、この部分の動作を次のように変更する。 Basic認証の場合でも、有効ユーザー名・パスワードの組み合わせが送信されていれば、そのユーザーでのログイン状態を維持し、401 Unauthorized を返すことをしない。そのユーザーでのアクセス権限の無いリソースへアクセスした場合には「アクセス権がない」旨の表示を行う。 **セキュリティの考慮 [#i5452f18] Basic認証ではリクエスト毎にユーザー名とパスワードが送信されるが、Sessionによるログイン状態の保持であればパスワードの送信は一度きりとなる。 Form認証であってもログイン状態でサイト上でできることは変わらないため、ブラウザとSessionを結びつけるキー(PHP session ID)はパスワードと同程度に秘匿する必要がある。セッションハイジャック等の攻撃に注意する。 *** 対応 [#u36bad7a] 実行時設定 [[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以降での動作が必要、とする。 ** 実装済みの仕様(2016-01-21) [#zce97e58] - Commits: branch_r1_5 osdn.jp/projects/pukiwiki/scm/git/pukiwiki/tree/branch_r1_5/ -- osdn.jp/projects/pukiwiki/scm/git/pukiwiki/commits/4008b5eccc3a6f05c0e4492e356b2f736ad157a5 -- osdn.jp/projects/pukiwiki/scm/git/pukiwiki/commits/34bff8e8505e5d22e7ecc6a66102c7a3d8cd4cd0 -- osdn.jp/projects/pukiwiki/scm/git/pukiwiki/commits/0bd51fe0d8228da33fd312fcb0813781d2f54034 -- osdn.jp/projects/pukiwiki/scm/git/pukiwiki/commits/82ba8d3bec0c1338dc0d1533afbd9134fdce3ef6 pukiwiki.ini.php にて $auth_type = AUTH_TYPE_FORM; -------- - 機能的には[[pukiwiki:自作プラグイン/login.inc.php]]とほぼ同じ -- [[umorigu]] &new{2016-01-21 (木) 01:45:35}; - 対応しました [[branch_r1_5>osdn.jp:projects/pukiwiki/scm/git/pukiwiki/commits?branch=branch_r1_5]] -- [[umorigu]] &new{2016-01-21 (木) 05:58:32}; - このセッション認証が有効時にセッション未対応なブラウザでの動作はどうなっているのでしょう -- [[#rm -rf /]] &new{2016-01-22 (金) 10:46:05}; - セッション…正確にはCookieに対応していないクライアントでは動作しません。動作しないというのは、Formにパスワード入力してログインボタンを押すと、戻ったページでセッション(認証済み情報)を認識できず、再度パスワード入力Formを表示します。Cookieに対応していないクライアントのサポートが必要な場合はBasic認証を使うことになります。URLパラメータによるセッション維持は危険度が高いのでOFFにしています -- [[umorigu]] &new{2016-01-22 (金) 21:10:14}; - [[BugTrack2/63]] session変数を追加してほしい (2005) -- [[henoheno]] &new{2016-01-24 (日) 22:59:52}; - コードのコミットの際、都度それぞれのBugTrack ページに、diffを気軽に参照するためのリンクを残すことを推奨します。なぜならば、気楽かつ高頻度な参照がし辛いようでは、他人(将来の自分を含む)に対する透明性が下がり、見落としの原因になるからです。強制ではありません。 -- [[henoheno]] &new{2016-01-24 (日) 23:03:54}; - 基本的に、あらゆる名前空間(関数、定数、グローバル変数)は先頭に冠詞 pkwk_ ないし PKWK_ を付けるべきです。なぜならば、他者のコードと名前が衝突する可能性が生じるからです。他者のコードとは、一部のグループウェアのように、PukiWikiを部品としてマージした場合の相手先を含みます。こちらも強制ではありません。 -- [[henoheno]] &new{2016-01-24 (日) 23:04:12}; - diffへのリンク→ご指摘の通りですね。残すようにします -- [[umorigu]] &new{2016-01-25 (月) 21:24:28}; - 接頭語のpkwkについては基本的には同意なのですが、既存コードとのバランスがより重要だと考えています。現状でほぼすべての関数がpkwk_無しのネーミングをされているので、pkwk_付きの関数は周辺コードとの調和がとりにくいです。また、仮に極端な例を考えるとして(カスタマイズ環境との関係で現実的ではないですが)関数すべてにpkwk_を付与するのは冗長になり可読性を損なうような気がしています。今後PukiWikiをモジュールとして取り込むようなプロダクトが現れるのであればそれは接頭語での区別よりもPHPネイティブのnamespaceを使ってくれると期待します -- [[umorigu]] &new{2016-01-25 (月) 22:21:49}; #comment