Q&A
どのような事情で「サーバー側エンジニアのNG」になったのかが気になります（キーなどが必要で、そもそもフロントから使うのが不適当なAPI、ということはありませんか？）。
WebAPIをたたくWeb画面を作成しています。
ajax通信でAPIを叩くjsのプログラムなのですが、そのままではクロスドメイン制約に引っかかるので、本番利用のときはサーバーと同一ドメインに配置させてもらう予定でした。
が、サーバー側エンジニアのNGがでたためAPIと同じサーバーにはおけず、別サーバーをたてることになりました。
サーバー側のCORS対応もNGとのことです・・・。
そこで質問です。
１．別サーバーを立てた場合、メインドメインが同じならサブドメインが異なっていてもクロスドメイン制約にはひっかからないでしょうか？下記のようなイメージです。
- サーバー側ドメイン：api.xxxx.com
- クライアント側ドメイン：www.xxxx.com
2.もし１．がだめな場合、クライアントサイドをajax通信以外で開発し直す必要があります。
他にどのような言語、フレームワークを使うことが考えられるでしょうか？
クライアントサイドの開発知識がほぼないので、html,css,jsだけの単純な作りしか思いつかず。
ASP.net（C#)あたりならできるのかなと思いますが、開発コストが増えそうなので他に手段がないか調べています。
機能的にはAPIをたたいてレスポンスをキレイに加工して出す単純なものです。
１．で問題なければプログラムは変更しなくていいのですが、だめな場合他の方法を考えなければなりません。
WebサーバーとAPIサーバーが異なることはよくあると思うので、一般的にはどう解決しているのだろう？と疑問に思い質問させていただきました。
顧客要望でAPIをASPサービスのように画面で使えるようにしたいという対応になったのですが、
その方針に反対で一切協力しない姿勢です。。。
デモ用につくったswiftのアプリでは問題なくAPIがたたけていたので、同じようにjsで作ったのですが
クロスドメイン制約にハマってしまっています。
回答5件
0
ベストアンサー
１．別サーバーを立てた場合、メインドメインが同じならサブドメインが異なっていてもクロスドメイン制約にはひっかからないでしょうか？下記のようなイメージです。
「サーバー側のCORS対応もNG」ならクロスドメイン制約にひっかかります。
2.もし１．がだめな場合、クライアントサイドをajax通信以外で開発し直す必要があります。
jsonp使うしかないのでは？
セキュリティのレベルは落ちますがね。。。
サーバーサイドのAPIでのjsonp対応も必須になります。
というか、APIでjsonp対応できるのなら、「サーバー側のCORS対応」(APIでAccess-Control-Allow-Origin ヘッダー適切に返すことができると思います。
WebサーバーとAPIサーバーが異なることはよくあると思うので、一般的にはどう解決しているのだろう？と疑問に思い
一般的には「サーバー側のCORS対応」を行います。
投稿2019/10/04 00:25
総合スコア7918
> サーバー側エンジニアのNGがでたためAPIと同じサーバーにはおけず、別サーバーをたてることになりました。サーバー側のCORS対応もNGとのことです・・・。
もし、サーバー側(APIの持ち主・開発者)だということだとすると、どこからも使えないAPIを置いて何したいんだろう？？？という疑問が・・・
サーバー側のエンジニアが難しい方なので私の理解が間違っているのかもしれません。。
CORS対応をしないというより、今の仕様は変えないソース等は開示しない！という主義なのです。
ajax通信しようとすると制約に引っかかるのでCORS対応されていないのだと私が解釈していました。
APIはブラウザに直接URLいれれば使えますし、swiftアプリを作って叩いたときも使えました。
これはCORS対応されているということなんでしょうか・・？
理解ができてなくて申し訳ないです。
> ブラウザに直接URL
これはCORSとは何の関係もなくリクエスト可能です。
>swiftアプリを作って叩いた
これも「ブラウザに直接URL」と全く同じです。
CORSはブラウザがスクリプトで行う XMLHttpRequestなどによるリクエストに適用されます。
詳しくは以下をお読みください。
https://developer.mozilla.org/ja/docs/Web/HTTP/CORS
>ブラウザーは、スクリプトによって開始されるオリジン間 HTTP リクエストを制限しています。
>例えば、 XMLHttpRequestや Fetch API は同一オリジンポリシーsame-origin policyに従います。
>つまり、これらの API を使用するウェブアプリケーションは、そのアプリケーションが読み込まれた
>のと同じオリジンからのみ HTTP リソースのリクエストを行うことができ、それ以外のオリジンから
>の場合は正しい CORS ヘッダーを含んでいることが必要です。
ありがとうございます。
なかなか難しくて頭から煙出そうですが、なんとかサーバー側のエンジニアと会話できるまで理解度をあげようと思います。
本APIはすでに運用されているので、今のユーザーはサーバープログラムのなかでAPI通信して問題なく動いているのだとおもいます。
ただブラウザでも見れるようにするにはCORS対応をしてもらうべきというのが一般的な対応、という理解です。
もし間違っていたらご指摘ください。
apiのサーバーサイドの変更を一切なしで対応することはできません。（もしできたらCORSの意味がなくなります。）（最後の手段としてはtanatさんの回答にある「踏み台プログラムを作ってサーバサイド通信をさせる」がありますが・・・）
apiのレスポンスをjsonpに変更する。または、Access-Control-Allow-Origin ヘッダーを適切に返すように変更する。のどちらかです。
ありがとうございます。他の方の回答からも正攻法で行けばサーバー側の変更をするべきということ、すでに運用されているAPIなので仕様変更するのは難しく、リスクも高いということがわかってきました。
GUI化すること自体を軽く考えていたフシがあるので、皆さんからのレスポンスをしっかり理解してチーム全体で再検討してみます。
0
その方針に反対で一切協力しない姿勢です。。。
まずはそれを解決するのが先決です。技術的に無理やり突破したところで、本来不必要な技術的負債を抱え込むことになりますし、最悪の場合はサーバサイドの変更で動かなくなる、という危険もあります。
投稿2019/10/04 01:02
総合スコア145977
ありがとうございます。おっしゃるとおりですね。
王道の手段はサーバー側で対応することだと皆さんの回答でもわかったので、もう一度相談してみることにします。
>不必要な技術的負債
ここが発生した際に「どこがコストを担保するか」まで考えておかないと最悪の事態になりかねません。
(なので、maisumkunさんがコメントしているように今解決すべき)
そうですよね。正直そこまで考えておらず、ブラウザで直接叩いたものをキレイに加工する程度でしょ、という要望だったので、見解をだしてチームで再検討するように促してみようと思います。
そもそも、同一ドメイン（サーバー）内にプログラムを置いてもらえればそれで解決するのではないかと思い至りました。まずはそこを再度検討して、説得してみようと思います。
0
CORS も JSONP もダメと言うことですと、ブラウザから AJAX で別ドメインの API にアクセスするのは無理と思います（少なくとも自分は解決策は分かりません）。
なので質問 2 の、
ASP.net（C#)あたりならできるのかなと思いますが、
機能的にはAPIをたたいてレスポンスをキレイに加工して出す単純なものです。
についてレスします。
ASP.NET でもクライアントが使うのはブラウザなので、それからクロスドメインの API に AJAX で要求を出すことは、CORS も JSONP もダメならできません。
なので、ブラウザからクロスドメインの API に AJAX で要求を出すのではなく、サーバー側で HttpWebRequest / HttpWebResponse などを使って API に要求を出して情報を取得し、その情報を元に「レスポンスをキレイに加工して」クライアント（ブラウザ）に返してやるという方法が考えられます。
具体的には以下のような構成にするということです。
クライアント（ブラウザ）⇔ ASP.NET Web ページ ⇔ コードビハインドの HttpWebRequest ⇔ クロスドメインの API
同等のことができる Web アプリであれば ASP.NET である必要はないです。
投稿2019/10/04 01:44
退会済みユーザー
総合スコア0
ありがとうございます。やはり王道はサーバー側の変更なんですね。。
ASP.NETは５年以上前ですが扱ったことがあるので、できるのではないかと思って書きました。
ただサーバープログラムも作るとなるとやはり開発コストは増えそうなので、一旦見解をまとめて方針をチームに共有してみます。
0
開発者が手軽にやるなら、
ブラウザ側のセキュリティ設定で対応
(ブラウザごとに)
出来ますが、本番で別サーバで別ドメインにAPIがあるなら
jsと同じドメインのサーバに簡単な踏み台プログラムを作ってサーバサイド通信をさせる。
jsからは踏み台をAPIのエンドポイントにする
かなあ。
そもそもフロントから叩くAPIとして作られてないとかだとこういうケースはありますね。。。
投稿2019/10/04 00:29
編集2019/10/04 00:37
総合スコア18727
ありがとうございます。そうですよね。
開発時にはブラウザ側の設定を変えて対応できていたのですが、本番では難しそうです・・・
APIの仕様を変更できるならjsonpで対応、出来ないなら踏み台を作るしかない状況ですね。。
踏み台を作るという実装も興味ありますが、他の方の回答をみてまずは王道でサーバー側のエンジニアを説得するほうがよいという結論になりました。
APIをjsのプログラムで叩くだけなら簡単だと思っていたのですが、難しい問題があるものなんですね。。。
勉強になりました。
既に動いているAPIという事であれば、
その仕様を変更するというのは必ずしも王道とは言えないかと思います。
（API管理者の責任範囲拡大とコストが発生することなので、本来的には設計時に伝えて予算を確保しないといけない）
ので、そのあたりを相談するにしても、誰がどうコストと責任を負担するかまで根回ししておかないと難しい様に思いますよ。
CORSを許可する＝セキュリティ的には弱くなる
なので、APIの管理者としては
・セキュリティ要件の見直し
・場合によっては脆弱性診断の再度実行
等など、設定自体の作業以外のコストが山の様に発生することになります。
よって、然るべき手続きと予算措置を持って依頼されない限りは「その方針に反対で一切協力しない姿勢です。。。」というのは（組織としては）正しい対応の様に思います。
ベストはこの辺を全てクリアしてAPI側で対応できるかを検討してもらって、対応する。
何らかの理由（例えば、外部ドメインからアクセスしてはいけない性質のAPIであるということはあり得ると思います。この場合、CORSを設定するのは不適当です）
でそれが無理なら、新しく建てたサーバで踏み台を設置して、踏み台からのアクセスに関するコストと責任は全て踏み台サーバ管理者側の責任範囲とする
あたりが落としどころになるのかなとは思います。
たしかにそうですね！APIとしては運用されているので、変更は難しいかもしれません。
根本的な問題なのだという認識がチーム全体になかったので、改めて見解を共有する必要がありそうです。
返信が入れ違いました。サーバーエンジニアはセキュリティ対策にかなり厳しいので、、、、完全NGを出した理由がやっとわかってきました。確かに簡単に考えてはいけないところですね。
むしろAPIを使わずにクライアント用のWebアプリを最初から作るのがベストなのではないかと思えてきました。
> むしろAPIを使わずにクライアント用のWebアプリを最初から作るのがベストなのではないかと思えてきました。
これ、管理主管が変わるだけで根本的に何も解決しないですよ。
すみません、そうなんですか？
今あるAPIを叩きたいというのが根本ではなく、APIのレスポンスの一部（８割程度）をWeb画面で表示したいというのが最終的にやりたいことでした。
今あるAPIをたたいてブラウザに表示するだけ、と思っていたのですが今回の問題に直面した次第です。
APIの仕様を変えるのはリスクが高そうなので、最初からWeb画面用にプログラムを作成するほうがよいのではとおもったのですが…。
0
JSONP APIで解決すればよいでしょう
投稿2019/10/04 00:25
総合スコア116694
ありがとうございます。JSONPもサーバー側になんらかの対応が必要そうなので諦めていました。
あとAPIのレスポンスがjsonではなくxmlなので、できないのではないかと思い読み飛ばしていました。
レスポンスがjsonでなくても使えるのでしょうか。
根本的なハードルはサーバー側のエンジニアの説得のような気がしてきました・・・
> JSONPもサーバー側になんらかの対応が必要そうなので諦めていました
本当はhttpヘッダの設定をしたほうが良いのですが、
基本的にはサーバー機能に依存せずに提供できるのがJSONPです
> レスポンスがjsonでなくても使える
レスポンスはjsonではなく引数付きのコールバック関数になります
ありがとうございます。そうなんですね。
コールバック関数も使ったことがないのでハードル高そうですが、JSONPについて改めて調べてみます。
あなたの回答
tips
プレビュー
