これまで Basic認証を中心として認証方法を解説してきたが
まとめと注意として、Basic認証は最初にユーザー名とパスワードを入力しておけば

• 認証データ( ユーザー名 + パスワード ) は暗号化されて送信される。
• 同じセッション上ではサブミット要求する度に認証データが何度でも内部で付随して送信される。

という特徴があり、Web での基本的な認証として優れている。

これに対して Web開発の経験がまだ浅い開発者がよくやる設計手法として
ユーザー独自のログイン・フォームを HTML で作成して、
さらに System i 上のユーザーとパスワードを対にした認証データ・ベースを作成して
そのファイルを CHAIN してユーザー名とパスワードを検査する、という手法は
断じて行なってはならない。

まずユーザー・フォーム HTML の中にユーザー名、パスワードを入力させて
そのまま SUBMIT したのでは TCP/IP 通信を第三者に傍受された場合に、
USER=KEYRI&PASS=YAM99 ... のように、そのままの形で見えてしまうのだ。
無線LAN を使っていれば表を歩いている歩行者にも見えてしまう。
次にユーザー + パスワードを社内データ・ベースとして保管したのであれば
QUERY400や Ftp 等によって簡単に社内の誰かにも見られてしまうのは必定である。
わが社の社員に限ってそのようなことはない、と断言することよりも
正しい機密保護機能を設定することのほうが社員を信頼することに繋がるであろう。
またこの方法では機密情報が流れるのは最初の一回だけであるので
ログインした後の HTML画面を、そのままローカルPCに保存しておけば
後から成りすましによって機密データ・ベースへのアクセスを行なうことが
できるのである。
つまりユーザー独自の HTML + データ・ベース による検証では
System i の機密保護レベル( QSECURITY )は 20 であるのとほぼ同じか、それ以下である。
ここではせっかく堅牢な System i の機密保護機能も使われていない。

上記を Basic認証に変更するだけで

• 認証データは暗号化されて傍受者に対して機密保護機能を有効にする。
• 毎回、認証データが付随するので成りすましを防ぐことができる。
• System i のユーザー/パスワード管理を使用するので社内の人間からも保護される。

という利点を得ることができる。
データ・ベースによるユーザー認証はゆめゆめ行うようなことはしてはならない。