XServer のバグが原因で以下が正常に機能しない。
問題が発生する要件
・アクセス制限IDを２つ以上設定してある場合の2個目およびそれ以降
・アクセス制限を複数パスに設定している場合のID設定すべて
・iFrame で画面を分割している環境
この時、1個目の設定ID以外は、エラーし、複数登録の設定数まではID・PWの再入力を求めてくる、ID個数全てが終わるとエラーでアクセス不能
iFrame を使わなければ、何個目のIDを利用しても問題はない。
XServer は iFrame のアクセス制限機能のテストをしていない
iFrameの組み合わせが原因のようですが、アクセス制限の仕様上、仰せのような運用には適してはいないかもですね。。
公式マニュアル含め、iFrame利用時の動作保証などは見つからなかったので、iFrameを利用しない形にするか、認証方式を切り替えるなどの対策を講じるしかないかもです。
なお、こういった運用に対応してほしい、という意見をサポートに伝えておけば、将来的に改善される可能性もあるかとは思います。
XServerのアクセス制限はベーシック認証をかける機能ですが、
ブラウザのベーシック認証の仕様で、ベーシック認証は、設定ごとに一つの認証しか保持できない制約があります。
iframeの場合は、1つ目の認証が使い回されるので、2つ目から表示できなくなる問題は考えられそうです。
iframeで分けられたディレクトリごとにアクセス制限設定を複数(同じユーザー情報で)かけてみて回避できないかや、
・エラー文
・どのようなディレクトリ構成
・iframeの中身はどのような記述
かを伝えてみるとよさそうに思います。
ありがとうございます。
・表面的なエラーはありません。設定したIDとPWですが、２個目、３個目は受け付けられず、複数IDが登録されているためか、登録数分を繰り返しID/PW入力ダイアログが表示され、回数分が終わると404になる。
・制限パスは、ルート直下のディレクトリーです。
・iFrame のHTMLは別に置き、フレームは左右２分割、左がメニュー、右がメニューで選ばれたHTMLの表示場所
・左側に制限パスのコンテンツ表示でもNG*1、右側も同様に制限パスのコンテンツ表示でNG*1
iFrame を使わず、「制限パスのコンテンツ表示」は、ID/PWが３個設定されている状態で、3個ともOK
*1：ID/PWが３個設定されている状態で、１個目の設定のみOK、残る２個は無効としてエラーなしに、次のID/PWを求めてくる。１個目でOKとなった場合、２個目、３個目のテストはキャッシュクリアしてからアクセスして、無効として次のID/PWを求めてくる。
私のコンテンツではiFrameは必須です。
左右や上下にボタンを使った選択肢でコンテンツ表示用フレームにコンテンツ表示したり、コンテンツ表示画面でも２つのフレームを作り、左に図を表示し、右に文字情報の説明を付けることもあります。Googleサイトなどはフレームを許可しないため、別のウィンドウで表示する場合もある。
コンテンツは、技術解説で文章の中で何度も同じ図を参照する必要があり、フレームで分けてあり、図を定位置または、説明を定位置に置いて、図中心の読み方、文章中心の読み方で相互参照に適した画面を設計しています。
３分割のフレームでは、上が大項目選択で、下の左右を子供として扱い、子供である左フレームは中項目選択で右フレームにコンテンツを表示、コンテンツに依っては、上記の通り、さらに iFrame で左フレームに図を、右フレームに文章を表示するもの。
英語と日本語のコンテンツを左フレームのボタンで選択できるように設計してあり、フレーム単位にコンテンツ設計・製作しており、iFrame 以外で運用は考えられない。
コンテンツは、HTMLで基本構成され、JavaScript(HTMLコール)で書いていたり、アニメーションコンテンツは JavaScript Canvas で書いています。
メンバーが英語で、日本語でとアクセスできるように上フレーム、または左フレームに言語別ボタンでダイレクト選択できるように設計してあり、iFrame 以外での利用は考えられません。
ありがとうございます。
iframeを利用している場合でも通常は一箇所のみでアクセス制限を利用している場合は、何個IDを利用しても再度認証が聞かれることはないかと思います。
一箇所の場合で起こる時に考えられるのは、サイトが https://でiframeでの指定がhttp://の場合は別のものとして不一致になっているなどがあるかもしれません。
iframeはWordPressも利用していたりするので、他の要因も組み合わさって起こる可能性もありそうです。
ありがとうございます。
誤解されているようです。
これはシステムテストです。
私は契約したUSER１，USER２，，，，USERnnn が利用できるようにするためのシステムを構築しています。
他のユーザーが正しく使えるように割当IDの機能確認のテストしているだけです。
そこで、USER1でログインしたキャッシュをクリアし、USER2でログインして正常に機能することをテストしています。
アクセス制限したエリアのコンテンツをUSER2やUSER3も使用可能を確認するためのLOGINテストで失敗することが問題であると申しています。
＞何個IDを利用しても再度認証が聞かれることはないかと思います。
意味がわかりません。
USER1でログインしている状態では、ログイン行為は発生しません。
再度認証が聞かれることはない＝当然＝ログイン中にログインが求められることなどありえない
キャッシュクリア（唯一のログオフ行為）すれば別
XServerのシステムでは、3アカウント設定していると、3回までのLOGIN失敗に、3回のリトライを許すようです。
経験上、設定アカウント数までリトライ可能、回数を超えると４０４、その後はF5を押せば、また3回
USER2と３の正しいログイン情報を無効とする（iFrame以外でログインはUSER2,3とも正常）
担当者の私個人には管理用USER1だけで充分です。
最初のアカウントなので、iFrame/非iFrame でも常に成功します。問題は USER2 以降のすべてが iFrame で正しいID/PWでも受け付けないこと
iframeを利用しているサイトで社員用の2アカウント目からの利用ができるように動作確認をしたいということですよね。
Basic認証をかけてiframeを使用したときだけ2個目のアカウントでアクセス不能になる場合でよくあるのは、
認証がどこかで2つ掛かっていて、1つ目のアカウントが２つ認証が通っていて、2つめのアカウントが片方しか認証が通っていなくて認証失敗を繰り返してアクセス不能になる。
もしくは、iframeのsrc指定でhttpとhttpsを間違えている時なんです。
内部エラーや設定情報等を見ないとちょっと難しそうです。
お力になれずすみません。
ありがとうございます。
あなたの話から
アクセス制限ディレクトリー AとB
コンテンツがAとB共にアクセスしている。
この場合、テストで確認するのは、AまたはBのアクセス制限を一時的に解除し、マルチ制限環境を回避する。
これでもダメでした。
USER1を削除したら、既存のUSER2が唯一のIDになるという前提でUSER2だけ残しました。
その結果、分からない事態に陥っております。
それでもUSER2はログインできず。
しかし、サーバー設定上でいないUSER1でログインできる
キャッシュクリアでもUSER1が有効
USER2は無効
PCリブートして実験
しかし、サーバー設定上でいないUSER1でログインできる
キャッシュクリアでもUSER1が有効
USER2は無効
違うブラウザで実験
しかし、サーバー設定上でいないUSER1でログインできる
キャッシュクリアでもUSER1が有効
USER2は無効
あり得ないことが起きている。
何なの？
根本的な問題の発見
XServerでアクセス制限の第１IDとPWのセットは、その登録を削除しても永遠に残り、登録済みとして機能する。
前提：（知る限りの状況から）
初めてアクセス制限としてパスAにアクセス制限を掛けて、許可IDとしてUSER1を登録した時、USER1を削除しても永遠に USER1 が有効である。iFrame では、何を設定しても、ID/PWは無効。
どこにも設定されていない USER1 がゴーストアカウントとして有効として稼働するという意味不明な動作をする。
Reboot,Cash clear, 他のブラウザ（計３種）でも同様で摩訶不思議
おかしなこと
・アクセス制限を無効にしてもID/PWを求めてくる
・アクセス制限のメニュー操作でユーザーリストを削除しても、.htpasswd には、削除したID/PWが残っている
・アクセス制限のメニュー操作で最初のユーザーを追加すると、.htpasswd の２行目に挿入される
・アクセス制限をを無効にしてもID/PWを求めてくる
・.htpasswd を削除しても、アクセス制限のメニュー設定画面でID/PWリストが出てくる
・手動で.htpasswd を修正してもNG, Permittion=604でも644(default)でも同じ
・手動で制限パス名を rename し、新規で制限パス名を作成しても同じ
兎に角、論理的な動作・設定・保管ではない。
REBOOT/CASH CLEAR でもNG
FIREFOX, Google Crome, Microfost Edge でも同様
下記を参照して対処も無効
（XServer アクセス制限のメニュー操作での誤った設定によるバグを想定した対策）
https://www.luft.co.jp/cgi/htpasswd.php
https://htaccess.cman.jp/explain/basic.html
はっきり言って XServer はまともな動きをしない。
エックスサーバーのアクセス制限機能（ https://www.xserver.ne.jp/manual/man_server_limit.php ）は、
・Basic認証自体はサーバーに設置された.htaccess、.htpasswdの内容をもとに実行する（一般的なApacheのBasic認証の処理と同じ）
・サーバー上の所定の位置に設置された.htaccess、.htpasswdの内容を読み取り、サーバーパネル上の設定状況に連動させている
・サーバーパネル上でアクセス制限のオンオフの切り替えやユーザーの登録などをした場合、サーバー上の所定の位置の.htaccess、.htpasswdの内容を修正する
といった挙動のようですが、bobさんの最新の発言など（ごめんなさい、それまでの発言をすべて精読したわけではありません）を見る限りでは、
・アクセス制限を無効にしてもID/PWを求めてくる
のあたりから、サーバーパネル側の一連の処理のなかの
・サーバー上に設置された.htaccess、.htpasswdの内容を読み取り、管理画面上の設定状況に連動させている
がそもそもうまくいっていないように見えました。
.htaccessはサーバーパネルの「アクセス制限」だけでなく、さまざまな作業により追記、削除、編集されるものですが、何かしらの処理の結果、.htaccessの記述が「アクセス制限機能の画面に反映させるためのパターンマッチでは認識できないような記述」になってしまって、bobさんが言うところの「サーバーパネルには表示されないゴーストアカウント」になってしまっているのかな、と。
ためしにアクセス制限機能をちょっといじった感じでは、この機能をオンにすると指定した階層の.htaccessに
AuthUserFile "/home/サーバーID/ドメイン名/htpasswd/.htpasswd" AuthName "Member Site" AuthType BASIC require valid-user
といった記述が追加されましたが、例えばこの記述の「AuthName」を変更して
AuthUserFile "/home/サーバーID/ドメイン名/htpasswd/.htpasswd" AuthName "hogehoge" AuthType BASIC require valid-user
などとすると、サーバーパネルの「アクセス制限」では認識されなくなり、その階層のアクセス制限は「OFF」と表示されるようで。なかなか厳密なパターンマッチというべきでしょうか。
例えば以下のような状況だと、「bobさんが認識している.htpasswd（その1側）とは異なる階層の.htpasswd（その2側）」で正誤チェックがされるので、
・その1側の.htpasswdを直接編集しても実際のBasic認証には反映されない（実際のアクセスにはその2側の.htpasswdが参照されるので）
・その1側のBasic認証を無効にしてもその2側のBasic認証は引き続き発生し、ID、パスワードの入力が求められる
といった状況が発生するかもしれません。
ドキュメントルート
┣.htaccess →Basic認証に関する記述その1。サーバーパネルに認識されている。
┗下層ディレクトリ
┣.htaccess →Basic認証に関する記述その2（ただし何かしらの編集が加わっており、サーバーパネルの「アクセス制限」では認識されていない）
┗★実際にアクセスしようとしているファイル
→「★」に実際にアクセスしたときは「Basic認証に関する記述その2」が優先して参照されるため（※）、「その2」側が参照している.htpasswdにてID、パスワードの正誤チェックがされる
※Apacheの一般的な仕様では、複数の階層にBasic認証が設置されている場合、下位ディレクトリの認証が優先され、下位ディレクトリの認証がとおってしまえば上位ディレクトリのBasic認証の設定は無視されるようです（認証ダイアログが開くこともありません）。
エックスサーバーがもっとしっかりして、.htaccessの内容を解析して設定画面に反映させてくれよ、というのはまあそのとおりだと思いますが、現時点でそれを求めても仕方ない感じでもあるので、ファイルマネージャやFTPソフトなどから各階層に設置された.htaccessの実際の内容をチェックし、Basic認証っぽい記述があれば手作業で削除するなどして、Basic認証まわりの記述（特に.htaccess側の記述）をいったんすべてリセットしてしまうとよいかもしれません。
また、Basic認証の際に表示される「AuthName」などを書き換えて運用したいということであれば、サーバーパネル上の表示がちぐはぐになってしまうことを前提にある程度手作業で設定状況を管理する必要がありそうです。
.htpasswdを直接編集できるスキルがあれば、.htaccess側ももちろんチェックしていそうなので、的外れの意見であればごめんなさい。
なにか問題解決の参考になりそうな情報があれば、断片だけでも活用していただけるとうれしいです。
コメントありがとうございます。
AuthUserFile "/home/サーバーID/ドメイン名/htpasswd/.htpasswd" AuthName "hogehoge" AuthType BASIC require valid-user
テストいましたが、何の変化もありませんでした。
この中の
AuthUserFile "/home/サーバーID/ドメイン名/htpasswd/.htpasswd"
サーバーIDとは何を示すのでしょうか？
取得したドメインでシステム運用にて発生おり、この問題を規定で提供するドメインで行なってみました。
提供ドメインでは、同様の運用（極めてシンプルな iFrame でのテスト）では発生しません。
取得ドメイン上のみで発生する点から
AuthUserFile "/home/サーバーID/ドメイン名/htpasswd/.htpasswd"
のサーバーIDの指定が無効である可能性を感じます。
取得したドメイン名が abcd.com で、アクセス制限パスが TestPash なら
AuthType Basic
AuthName "Input your ID and Password."
AuthUserFile /home/abcd/abcd.com/TestPath/.htpasswd
require valid-user
というものとして.htaccess がパネル操作で生成されます。
保管データが知的財産価値が高いため、ロボットによるデータ収集の対象にならないためにも
アクセス制限は有効と考え対策として採用する目的でもあります。
よろしくお願いいたします。
この中の
AuthUserFile "/home/サーバーID/ドメイン名/htpasswd/.htpasswd"サーバーIDとは何を示すのでしょうか？
取得したドメインでシステム運用にて発生おり、この問題を規定で提供するドメインで行なってみました。
提供ドメインでは、同様の運用（極めてシンプルな iFrame でのテスト）では発生しません。
取得ドメイン上のみで発生する点からAuthUserFile "/home/サーバーID/ドメイン名/htpasswd/.htpasswd"
のサーバーIDの指定が無効である可能性を感じます。
サーバーIDについてはこのマニュアルページで説明されています。
▼各種IDについて
https://www.xserver.ne.jp/manual/man_order_about_id.php
https://support.xserver.ne.jp/manual/man_order_about_id.php
今回の質問において、質問投稿フォームにある「対象サービス」が選択されておらず、bobさんが使用しているサーバーサービスを推測する手がかりは
XServer のバグが原因で以下が正常に機能しない。
あたりの「XServer」ぐらいしかなさそうですが、「エックスサーバー（ https://www.xserver.ne.jp/ ）」を利用している場合も「XServerビジネス（ https://business.xserver.ne.jp/ ）」を利用している場合も、
・サーバーIDというものが存在すること
・サーバーIDの役割
・サーバーIDの確認場所
といったものは同じです。
サーバーIDはエックスサーバーなどを申し込むときに自分で決めるものではありますが、「サーバーIDをすぐには思いつかない人用」なのか、「xs＋数字」などの文字列が申し込み画面の入力フォームに初期状態で入っているので、自分で決めたという感覚ではないことも多いかもしれません。
エックスサーバー、XServerビジネスを利用している場合、FTP接続をしたときの最上位のディレクトリは「 /home/サーバーID/ 」であり、
サーバー上の本来の位置・・・ /home/サーバーID/
FTPソフトから見えるディレクトリ・・・ /
となることから認識しづらいことではありますが、.htaccessからPHPプログラムなどからファイルを指定する場合のフルパスには「/home/サーバーID/」から始まるパスを指定する必要があります（サーバーパネルの「サーバー情報」ページにも「ホームディレクトリ」としてこのパスが記載されています）。
また、「サーバーID」はサーバー契約ごとに固定の値です。そのサーバー契約のなかで、
・サーバー契約時についてくる無料の初期ドメイン（ サーバーID.xsrv.jp などの形式のアドレス）
・ご自身が追加した独自ドメイン
などを並行して運用している場合も、/home/サーバーID/ の部分は同じです。
ちなみに
のサーバーIDの指定が無効である可能性を感じます。
この「サーバーIDの指定が無効」のニュアンスはわかりませんでしたが、仮に「サーバーID」の部分が「bobさんの契約サーバーのIDとは異なる文字列」などになっていて、.htpasswdファイルが読み込めなかった可能性があるのでは、ということなら、その可能性は低そうです。
Basic認証が求められたとき、.htaccessファイルで指定している.htpasswdファイルがなければ、
・初回のアクセス（認証情報を含まないアクセス）・・・ステータスコード401を返す（ブラウザにID、パスワードを入力するダイアログが表示される）
┣ブラウザ側でID、パスワードの入力をキャンセルする→ブラウザに401エラーが表示される
┗ID、パスパスワードを入力する（＝認証情報が含まれた状態でアクセスしなおす）→.htpasswdが存在しない場合、「500エラー」を返す
といった挙動を示します。
ID、パスを入力したときに再度聞き返されたり、意図していないID／パスワードであれ、その入力で認証がとおってしまったりするのであれば、少なくとも指.htaccessファイルで指定したディレクトリに.htpasswdが存在し、指定した.htpasswd自体は読み込めている可能性がとても高いです。
取得したドメイン名が abcd.com で、アクセス制限パスが TestPash なら
AuthType Basic
AuthName "Input your ID and Password."
AuthUserFile /home/abcd/abcd.com/TestPath/.htpasswd
require valid-user
というものとして.htaccess がパネル操作で生成されます。
念のために確認しますが、エックスサーバー、もしくはXServerビジネスの管理ツールである「サーバーパネル」からの操作でしょうか。
私はエックスサーバーの、かなり古いサーバー（10年以上前に申し込んだサーバーで、sv番号でいうと3桁の、200番台ぐらいです…）を使っていますが、私の契約の場合、サーバーパネルのアクセス制限機能を有効にすると、すでに回答したとおりの記述が.htaccessに追加されました。
■ 「example.com」ドメインの「 https://example.com/TestPash/」に対してBasic認証をかけた場合
1)サーバー上の /home/サーバーID/example.com/publid_html/TestPash/.htaccess に対して以下の記述が追加される
▼私のサーバー契約で.htaccess追加された記述
AuthUserFile "/home/サーバーID/example.com/htpasswd/TestPash/.htpasswd" AuthName "Member Site" AuthType BASIC require valid-user
※FTP接続時は「/example.com/」が最上位のディレクトリになる。
2)サーバー上の /home/サーバーID/example.com/htpasswd/TestPash/.htpasswd にID、暗号化されたパスワードが記述される
※bobさんがどこかで指摘していたとおり、.htpasswdファイルの「2行目」に追加されていました。ただしこれは何行目にあっても動作には支障はありません。
私が契約しているエックスサーバーが古すぎるからbobさんの契約サーバーとは.htaccess上に記載される内容が異なる、といった可能性はほぼないと思うんですが（サーバー契約時期によってサーバーパネルから提供する機能で生成される記述内容を変える意味が特にないので）、bobさんの契約しているエックスサーバーまたはXServerビジネスでは、サーバーパネルのアクセス制限を有効にしたときに
AuthType Basic AuthName "Input your ID and Password." AuthUserFile /home/abcd/abcd.com/TestPath/.htpasswd require valid-user
という記述が追加されましたか。
・ 「.htaccessに追加される4行記述」について、順序が異なる
・AuthTypeの「BASIC」について、大文字／小文字が異なる
・AuthNameで指定されている内容が異なる
・.htpasswdのパスが異なる
※私の契約サーバーの場合、「ドメイン名ディレクトリ」の直下に「htpasswd」ディレクトリが生成され、その下に「アクセス制限を指定したディレクトリ名と同じディレクトリ」が生成されたうえで、そこに.htpasswdが生成される
など、大きく違いがあり、
パネル操作で生成されます。
の「パネル操作」について、ご自身で作ったシステムなどの管理パネルからの操作なのかな、とも思った次第です。
いずれにせよ、すでに回答した通り、
ファイルマネージャやFTPソフトなどから各階層に設置された.htaccessの実際の内容をチェックし、Basic認証っぽい記述があれば手作業で削除するなどして、Basic認証まわりの記述（特に.htaccess側の記述）をいったんすべてリセットしてしまうとよいかもしれません。
といった作業をし、一度すべてをリセットしたうえで、
・エックスサーバー／XServerビジネスのサーバーパネルですべての作業をする
・ご自身が用意したシステムですべての作業をする、または、FTPなどを用いて手動で.htaccess、.htpasswdを設置する
のどちらかに統一してみるのが良いかもしれません。
私に回答できそうなこととしては以上です。私の回答が的外れな場合にも、断片的な部分であれ、何かしらの問題解決に役に立てば幸いです。
質問・回答いただきありがとうございました。
■質問者様へ
質問が解決した際には、回答者の方へお礼をお伝えいただくとともに、質問のステータスを「解決済み」に変更してください。