- ベストアンサー
カード決済WebAPIへのSSL送信
・カード決済代行のWebAPIにカード番号や料金などを送信する ・送信する際の画面はSSL このときJavaScriptでセキュアにWebAPIに情報を送信する方法はどのようにすれば よいのでしょうか?
- みんなの回答 (3)
- 専門家の回答
質問者が選んだベストアンサー
先ず、[ANo.2] へのお礼の中の質問にたいする回答ね。 「それが可能だったとしても、XmlHttpRequestの通信が暗号化された処理にできるのでしょうか...?」 暗号化通信(今回は SSL のことね) は、通信経路の安全性の話だから、XmlHttpRequest とは関連がない技術だよ。 つまり http: で出来るなら、https: でもできるということ。 XmlHttpRequest のリクエスト url が https:// からはじまるときのことを考えれば、納得できるかな? ここからは、いま思考実験中?の 「決済側のWebサービスが」クロスドメインの XmlHttpRequest でサービスを提供しているとしたら?の話ね。 一瞬、いい方式かなとおもったけど、一日落ち着いて考えたら、やっぱりだめだね。 一つ穴が見つかるとドンドン見つかる。 説明が一番簡単な部分を一つ指摘するよ。 1) SSL の安全性の確保は、最終的にユーザの目視に頼っている。 具体的にいうと、 ユーザがロケーションバーに表示されている URL のドメインをみて、「ああ、きちんと目的のサイトにきているな。」と確認することが必要だよ。 理由については、暗号化技術の理解が必要だから気が向いたら調べてみてね。 2) クロスドメインの XmlHttpRequest は、ユーザにクロスドメインへの通信を意識させない。 1) と 2) は同時に成り立たないよね。これだけでも、大きなセキュリティに対する脆弱性につならるから、たとえ出来たとしても止めた方がいいよ。
その他の回答 (2)
- dscripty
- ベストアンサー率51% (166/325)
通常はの手順は、リダイレクトで決済代行会社のウェブサイトへ転送して決済処理をさせるけど、転送じゃなくて、自分のウェブサイトのまま、xmlhttprequest で決済処理をしたい。という意味? もしそうなら、まず、ほかのドメインへの xmlhttprequest は制限されているからできないよ。 その制限を回避するのが Cross site resource sharering https://developer.mozilla.org/En/HTTP_Access_Control で、これはどのサイトからのクロスドメインリクエストを許可するか設定できるものみたいだけど、今回のケースだと、許可設定はカード決済代行会社のウェブサイト側がする必要がありそうだよ。 つまり、カード決済代行会社がこの Cross site resource sharering の Access Control を提供しているかどうかだけど、 もし、決済代行会社のめどをつけてるなら問い合わせてみたほうが早いかもね。 でも、この cross site resource sharering って対応しているかどうかはウェブブラウザ依存だから、ユーザの使うウェブブラウザを制限させることになるし、実用上どうなんだろうね。
お礼
ありがとうございます。 以下のURLの接続方式を検討しています。 http://www.cardservice.co.jp/service/connection/securelink.html 決済側のWebサービスがjsonでレスポンスしてくれる仕様であればクロスドメインで通信ができるのかと思いました。 それが可能だったとしても、 XmlHttpRequestの通信が暗号化された処理にできるのでしょうか...?
- 0909union
- ベストアンサー率39% (325/818)
>JavaScriptでセキュアにWebAPI 状況が説明されていません。 使用場所はどこなんですか? サーバーサイド、クライアントサイド? JavaScriptにWebAPIを直接呼び出す機能なんてありませんよ。 しかもWebAPIてなんですか? どこの言語?フレームワーク ECMA262 で検索しましょう。できるのはJScript
補足
HTTPSで通信されている入力フォームからクライアントサイドの JavaScriptで、 カード決済機能を提供している外部ドメインのWebサービスのURLにAJAX通信をしようとしています。
お礼
とても親切なご説明ありがとうございました。 非常に助かりました。