回答編集履歴
1
追記部分を追加
answer
CHANGED
@@ -51,4 +51,28 @@
|
|
51
51
|
|
52
52
|
インターネット上に広く公開されているならば、
|
53
53
|
HTTPではなくHTTPSにすればパスワードの部分は暗号化されるので安全になります。
|
54
|
-
GitHubはHTTPS+ベーシック認証を推奨していますね。
|
54
|
+
GitHubはHTTPS+ベーシック認証を推奨していますね。
|
55
|
+
|
56
|
+
---
|
57
|
+
|
58
|
+
【追記】 Webサービスに於けるページ遷移に関して
|
59
|
+
|
60
|
+
そもそもHTTPサーバの構造上、1回1回のHTTP通信は全て1度の通信が終わると完結してしまいます。
|
61
|
+
なのでログインしたか否かの情報も次の画面へ行くと消えてしまいます。
|
62
|
+
もちろんJavaScriptの変数の値も次の画面には持っていけません。
|
63
|
+
|
64
|
+
なので対策は大きく分けて下記になります
|
65
|
+
|
66
|
+
- クッキーにログイン者の情報を持たせる(多くのWebサービスがこれ)
|
67
|
+
- 毎ページ払い出すHTML内にログイン者の情報を含めて使いまわす(docomoのフィーチャーフォン用サイトで採用)
|
68
|
+
|
69
|
+
クッキーを使った認証はセッションと呼ばれ、
|
70
|
+
Webサーバで一時的に使えるトークンを吐き出してWebサーバとクッキーが各々で保持
|
71
|
+
それを突き合わせて、こいつは最後の利用から1時間以上経過してるからセッション切れ扱いでログインさせなおす……みたいな事が一般的です。
|
72
|
+
|
73
|
+
内部で閉じているならば
|
74
|
+
そんな厳密なものでなくても問題ありません。
|
75
|
+
クッキーにIDとパスワードをぶち込んでしまって、ページ遷移の度にクッキーを取り出して認証チェックすれば問題ありません。
|
76
|
+
|
77
|
+
後者の方法は主にベーシック認証で利用されるやり方です。
|
78
|
+
各種リンクやフォームにベーシック認証用のコードを都度貼り付ける事で実現出来るでしょう。
|