Submit先について

質問

お世話になります。
よろしくお願いします。

ちょっと表現方法が難しいのですが、
2つのサーバ間（別ドメイン、別サーバ）でデータをやり取りする際において以下のようなことをやりたいと思っています。

Aサーバ：ログイン情報入力　⇒　Bサーバ：Aサーバで入力したデータを受信、認証　⇒　Bサーバでデータ更新（DB登録）⇒　Aサーバにデータを渡してAサーバのDBも更新

この過程で画面上には
A:ログイン画面⇒B:情報変更画面⇒B:確認画面⇒B:完了画面
しか表示できません。

この場合、確認画面から完了画面の遷移の中で、
確認画面でOKボタン押下⇒Bサーバで受けてDB更新⇒リフレッシュ0でAサーバの画面を呼ぶ（表からは見えない）⇒AサーバでDB登録⇒リフレッシュ0で完了画面呼出

と考えているのですが、この方法の考え方ってあってますか？それとも別に何かいい方法ありますか？
タイトルのようにsubmitの先を箇所とかにできない・・ですよね？

というのも少し手順が面倒なのと、表側でリフレッシュ0がどのように反応するのか？などが引っかかっております。

参考になる情報、意見等お願いいたします。

回答No.5

leaz024 · ベストアンサー

> ここでいうAのサーバは自由にいじれるので何でも作成できます。しかし、Bサーバにはほとんど何も出来ません（してくれません）という状況なのですが、今出来ているHTML画面からの値渡しのI/Fしかない状況でこの方法って簡単に出来ますか？

Bサーバのシステム（以下、SysB）に手を入れずにAサーバのシステム（以下、SysA）と協調させたい場合は、「Proxyパターン」（デザインパターンの１つ）を使うとよいでしょう。

SysA を SysB へのインターフェース（Proxy）とし、ユーザと SysB 間のやり取りを中継しつつ独自の処理を行います。つまり、SysA で SysB をカプセル化し、ユーザが SysA 経由で SysB を操作する際に SysA の処理も行うのです。

全体のシーケンス（全て成功時）は次のようになります。

ブラウザ　　　　　　SysA　　　　　　　　　　　SysB
　　　　　アクセス→
　　　　　　　　　　　・ログインページを出力
　　　　　 ←HTML
・ログイン画面
　　　　　　送信→
　　　　　　　　　　　・SysBに中継
　　　　　　　　　　　　　　　　　　　　送信→
　　　　　　　　　　　　　　　　　　　　　　　　　・認証など
　　　　　　　　　　　　　　　　　　　 ←HTML
　　　　　　　　　　　・HTMLを加工して出力
　　　　　 ←HTML
・情報変更画面
　　　　　　送信→
　　　　　　　　　　　・SysBに中継
　　　　　　　　　　　　　　　　　　　　送信→
　　　　　　　　　　　　　　　　　　　　　　　　　・入力チェックなど
　　　　　　　　　　　　　　　　　　　 ←HTML
　　　　　　　　　　　・HTMLを加工して出力
　　　　　 ←HTML
・確認画面
　　　　　　送信→
　　　　　　　　　　　・SysBに中継
　　　　　　　　　　　　　　　　　　　　送信→
　　　　　　　　　　　　　　　　　　　　　　　　　・DB更新
　　　　　　　　　　　　　　　　　　　 ←HTML
　　　　　　　　　　　・DB更新
　　　　　　　　　　　・HTMLを加工して出力
　　　　　 ←HTML
・完了画面

次の点がポイントです。
１．SysB の出力は変えられないので、ユーザは常に SysA を経由して SysB にアクセスします。
２．SysA は必要に応じて SysB に中継します。この時、SysA が受け取った送信データは、そのまま SysB に送信します。
３．SysB から返されたHTMLには SysB へのパスなどが入っているので、それを SysA のものに加工して出力します。
４．SysA のDB更新時にはまず SysB からのHTMLを解析し、SysB のDB更新が成功していたなら行います。

>>「AサーバのDBは故意に操作できる」ということが「セキュリティホールにはならない」と言えるだけの堅牢なシステムであるなら、大丈夫なのではないでしょうか。
> AのサーバはBからは触れない。BのサーバのDBはBのサーバで用意したアプリでしか触れないという意識ですが・・・

先の方法では、
> リフレッシュ0でAサーバの画面を呼ぶ（表からは見えない）⇒AサーバでDB登録
となっていましたので、「AサーバのDB登録URL」は当然ユーザに丸見えです。これは Location を使った場合でも同じで、ちょっと技術に長けた人にはURLを盗られてしまいます。
一度URLが盗れれば加工することなど雑作もないので、操作し放題となるわけです。

お礼

leaz024様
とても分かりやすく細かい説明ありがとうございました。ようやく理解することが出来ました。
これだとやりたいと考えていたこととマッチします。
（クライアントにも中途半端に画面返りませんし）
ただ、残念ながら今回には適用できそうにありません。というのも、Aサーバが設置してあるDMZからはhttp(s)は受信することは出来ても送信することは許してくれないようです。
どちらがセキュリティが高いか説明してみますが、インフラに関しては別担当が構築していて、ポートを空けないと言っているので、当初ご相談した方法でいこうと思います。
本当に分かりやすい説明ありがとうございました。

回答No.4

leaz024

> はい。全ての通信をHTTP（HTTPS）だけで行う必要があります。

何か勘違いされているような気がしますので逆に聞きますが、私が書いた方法のどこにHTTP(S)以外の通信が入るというのでしょうか？

No.2で示したシーケンスのうち、「ブラウザ － B：DB更新Sys」間は言わずもがな、「B：DB更新Sys － A：DB更新Sys」間の直接通信もHTTP(S)でやればいいでしょ？という話なのですが。それ以外に通信する部分はないですよね？

> 逆にこの方法で重要なセキュリティ問題はありますか？

「AサーバのDBは故意に操作できる」ということが「セキュリティホールにはならない」と言えるだけの堅牢なシステムであるなら、大丈夫なのではないでしょうか。

そもそもは方法論の話でしたし、No.2の方法もダメということから他にも様々な制約がおありのようですので、私ではこれ以上アドバイスは難しいです。

補足

>何か勘違いされているような気がしますので逆に聞きますが、私が書いた方法のどこにHTTP(S)以外の通信が入るというのでしょうか？
>No.2で示したシーケンスのうち、「ブラウザ － B：DB更新Sys」間は言わずもがな、「B：DB更新Sys － A：DB更新Sys」間の直接通信もHTTP(S)でやればいいでしょ？という話なのですが。それ以外に通信する部分はないですよね？
はい。思いっきり勘違いしてました。たしかにHTTP(S)でやればいいんですよね。
この方法で再度質問（勉強不足ですいません）なのですが、ここでいうAのサーバは自由にいじれるので何でも作成できます。しかし、Bサーバにはほとんど何も出来ません（してくれません）という状況なのですが、今出来ているHTML画面からの値渡しのI/Fしかない状況でこの方法って簡単に出来ますか？
基本的にはAサーバからはデータ投げっぱなし。エラーは意識しない。データを投げたことだけ確認して、画面をユーザに返す。ということをやりたいのです。

>「AサーバのDBは故意に操作できる」ということが「セキュリティホールにはならない」と言えるだけの堅牢なシステムであるなら、大丈夫なのではないでしょうか。
AのサーバはBからは触れない。BのサーバのDBはBのサーバで用意したアプリでしか触れないという意識ですが・・・

>そもそもは方法論の話でしたし、No.2の方法もダメということから他にも様々な制約がおありのようですので、私ではこれ以上アドバイスは難しいです。
はい。そんな方法ありえないということをお聞きしたので、セキュリティ的にだめなのかと思って聞いてみました。これについては別途検討いたします。

よろしくお願いいたします。

回答No.3

leaz024

> 通信経路はHTTPと決められてしまいましたので、模索してるところです。

だから何か事情があるのだろうと代替案を書いたのですが・・・。BサーバからAサーバへの通信をHTTPで行えば済む話ではないのですか？他にも問題があるのでしょうか。

DBの更新を伴う作業をブラウザからアクセス可能なGET方式で行うなんて、まず有り得ないないですよ？

> 決められてしまいました

というからには上にSEの方がいるのでしょうから、その方にどうすべきか聞いてみてはどうでしょうか。

お礼

文章が簡潔な為、お伝えできないところがあり、鋭い突込みをいただきましたが、回答ありがとうございます。

>だから何か事情があるのだろうと代替案を書いたのですが・・・。BサーバからAサーバへの通信をHTTPで行えば済む話ではないのですか？他にも問題があるのでしょうか。
はい。全ての通信をHTTP（HTTPS）だけで行う必要があります。
>DBの更新を伴う作業をブラウザからアクセス可能なGET方式で行うなんて、まず有り得ないないですよ？
とはいえ、お客様の仕様がそのようになっておりますので・・・
逆にこの方法で重要なセキュリティ問題はありますか？
IPフィルタリングなど、通信は限られた穴しかあけない前提です。

回答No.2

leaz024

Ａ，Ｂどちらのサーバのシステムもいじれるのならば、ＡサーバのDBをＢサーバからはアクセスできるようにしておき、ＢサーバのDB更新時に直接ＡサーバのDBにアクセスして更新してしまえばよいと思います。

まぁ、それができるならそもそもDBは１つで済むわけですから、そういかない事情があるのかもしれませんね。

なので代替案として、BサーバのDB更新システムにAサーバのDB更新システムをキックする処理を組み込んではどうでしょうか？

ブラウザ　　　　　B：DB更新Sys　　　　　A：DB更新Sys
・B：確認画面
　　　　　送信→
　　　　　　　　　　・DB更新処理
　　　　　　　　　　・AのDB更新Sysと通信
　　　　　　　　　　　　　　　　　　　送信→
　　　　　　　　　　　　　　　　　　　　　　　　・DB更新処理
　　　　　　　　　　　　　　　　　　　←結果
　　　　　　　　　　・AのDB更新が失敗していれば
　　　　　　　　　　　BのDB更新をキャンセル
　　　　　　　　　　・結果に応じた画面出力
　　　　　←HTML
・結果に応じた画面

RefreshなりLocationなりでブラウザを通して行う予定だったＡのDB更新を、Socketなどを利用して内部で行ってしまうわけです。
具体的な方法はシステム開発言語に依存するので、そのカテゴリで聞いてみて下さい。

お礼

ご回答ありがとうございます。
そうなんです。そうなんですが・・・
当初そのように設計していたのですが、通信経路はHTTPと決められてしまいましたので、模索してるところです。
＃制限がなければそれがいいんですけどね。セキュリティ面でも・・・

回答No.1

gonagona

こんばんは。

HTMLのリフレッシュタグだと履歴に残っちゃいますよね？

ロケーションを使ってみてはどうでしょう？
PHPですと、
●確認画面でOKボタン押下
　↓
●Bサーバで受けてDB更新
<?php

BサーバDB更新処理

header("Location: http://Aサーバのアドレス");
?>
　↓
●AサーバでDB登録
<?php

AサーバDB更新処理

header("Location: http://Bサーバ完了画面のアドレス");
?>
　↓
●Bサーバ完了画面

このやり方ですと、
Bサーバ完了画面でブラウザの戻るボタンを押しても、戻り先はBサーバ確認画面となるので、多重登録などのトラブルやURLを覗かれたりとかは減らせると思います。

処理の簡略化については、２つのDBを使用するならこのやり方で良いのではないでしょうか。

お礼

回答ありがとうございます。
＃メールが今来たのでせっかく昨夜回答を頂いていたのに遅くなりました。すいません。

なるほど。リフレッシュを使うよりLocationを使えば履歴に残らないということですよね。参考になりました。

方法論は問題なさそうなのでこの方法でいきたいと考えております。
ただし、SSL通信なのでドメインが変わった時にどうなるのか？エラーが発生した場合のハンドリングをどうしようとか別の問題が発生して困ってます・・・