fetch(POST)で送った同時に次のページに遷移させたい

実現したいこと

以下のようなコードが2つあります。
送ったら、SESSIONの中身と「postできましたよ」がconnect.phpのページで表示したい

送る側

html
1<!DOCTYPE html>
2<html>
3    <head>
4        <title>POST Request on Button Click</title>
5    </head>
6    <body>
7        <button id="postButton">Post it</button>
8
9        <script>
10            document.getElementById("postButton").addEventListener("click", function() {
11                const myHeaders = new Headers();
12                // myHeaders.append("Cookie", "PHPSESSID=itjgsbmsjf5sk87oh25rijhsn6");
13            
14                const formdata = new FormData();
15                formdata.append("user_nane", "dummy");
16                formdata.append("compay_code", "Z100");
17                formdata.append("employe_code", "7878787888");
18                formdata.append("user_type", "0");
19            
20                const requestOptions = {
21                  method: "POST",
22                  headers: myHeaders,
23                  body: formdata,
24                  redirect: "follow"
25                };
26            
27                fetch("http://*.*.*.*/conect.php", requestOptions)
28                  .then((response) => response.text())
29                  .then((result) => console.log(result))
30                  .catch((error) => console.error(error));
31            });
32        </script>
33    </body>
34</html>
35

遷移先のコード(connect.php)

php
1<?php
2header("Access-Control-Allow-Origin: *");
3header("Access-Control-Allow-Headers: Content-Type, Authorization");
4
5$method = $_SERVER['REQUEST_METHOD'];
6session_start();
7if ($method == "POST") {  
8$_SESSION['usr_name'] = $_POST['user_name'];
9$_SESSION['company_code'] = $_POST['company_code'];
10$_SESSION['employe_code'] = $_POST['employee_code'];
11$_SESSION['user_type'] = $_POST['user_type'];
12
13// header('Location: conect.php');
14// exit;
15}
16
17echo '<pre>';
18var_dump($_SESSION);
19echo '</pre>';
20
21echo "postできましたよ";
22exit;

発生している問題・分からないこと

connect.phpに遷移(表示)はできず、送る側にレスポンスとして表示したい内容が返ってきてしまう

該当のソースコード

特になし

試したこと・調べたこと

teratailやGoogle等で検索した
ソースコードを自分なりに変更した
知人に聞いた
その他

上記の詳細・結果

成功して
.then((result) => console.log(result))に以下のコードを追記してもSESSIONの中身はない。

window.location.href = 'http://localhost/connect.php';

補足

まずは同ホストないですが
最終的には別ホストで実現したい

yambejp

2024/03/26 03:05 編集

質問がぶれてます fetchするなら遷移しません。先にfetchでpostして同じファイルに遷移したときにセッションが残っていないということですかね？（セッションが残っていれば遷移先はおなじファイルである必要はないですが）

eisaku123

2024/03/26 03:09

同じファイルにーー＞別ファイル(connenct.php)です。

eisaku123

2024/03/26 04:13

遷移するにはどうずれば良いのでしょうか

行動規範の内容に同意します

回答2件

ベストアンサー

ベストプラクティスでいうと下記のように作り変えましょう。

connect.phpは2通りの入口を作る
- POST: 入力値をセッションに保存するだけ
- GET: セッションの値を表示する
fetchでconnect.phpへ向かってPOST通信を一度投げて、.then((result) => console.log(result))を.then(=> window.location.href = 'http://localhost/connect.php';)に書き換える

んで、なんでこれが最善なのか？に関して判断材料を共有していきます。

JavaScriptのコードで使用しているfetchはFetchAPIのことです。
今閲覧中のページはそのまんま開きっぱなしにした状態のまま、裏でこっそりHTTP通信を発射して情報を持ち帰る機能を指します。

「fetchを使ったけどページ遷移できません！」と言われても至極当然の話で、
ページ遷移したくないからページ遷移せずに情報を追加で持って帰ってくる機能に何を期待してるんだ？って話になるわけですよ。

次、connect.phpはPOSTメソッドでリクエストを待ち構えてますが、
ChromeやFirefox等のブラウザで扱う場合成約があります。
(この辺の知識はRESTfulで勉強してください)

普段我々がWebブラウザを開いてWebサイト・Webページを表示する時って
情報を受け取りたいからWebサイトへアクセスしてるわけですよ。
つまり基本的には全てGET。

SNSや掲示板、後はAmazon等のショッピング等でこちらから情報を送信して保存してもらいたい。
そういう時に使う通信がPOSTになります。

JavaScriptからWebブラウザを操ってPOST通信する方法は基本的には以下の2パターンしかありません。

FetchAPI (Ajax) を利用して、裏で勝手にPOST通信を行う方法
CSSで非表示にしたダミーのフォームをDOM上に展開しておき、そのフォームをJavaScriptの機能でsubmitする

実際Webブラウザで単にPOST通信するって事はできないんですよね、
アドレス欄に入力してページ遷移した時は絶対にGETです。
window.location.href = 'http://localhost/connect.php';はブラウザのアドレス欄を弄ってるのと同じでGET。

POST通信してないんだから結果が得られるわけないですね。
connect.phpはPOST通信を受け取ったら情報を保存&画面表示するけど、GET通信だったら何も保存しないし表示もしない作りになってるんだから。

じゃあ裏でフォーム部品作って<form style="display: none;">みたいなの作って
JavaScriptのDOM操作機能を使ってサブミットすりゃええやん。

これもWebエンジニアとしては推奨できません。
理由はF5キーでページをリロードした時や、ブラウザバック・フォワード機能を使った時に不整合が出るためです。

POST通信しますよーという状態になっているフォーム部品をサブミットしてページ遷移した場合、
遷移後のページはPOST通信で受け取ったものになります。
その状態でページをリロードすると、再度同じPOST通信を発射しながらページリロードを試みることになります。

これがSNSや掲示板サイトでは同じ投稿内容を2重送信しようとした、
ショッピングサイトでは同じものを2度購入しようとしたという風に受け取れるわけですね。
もしAmazonで注文した商品が2個届いて、2倍の値段請求されたらどうします？私だったらブチギレますね。

なので、POST通信を受け取ったら、そのままHTMLを返すなんてしません。
fetch前提ならば、受け取ったよー保存したよーというメッセージを返して終わり。
フォームでページ遷移する時は、connect.phpのような受ける側で保存した後に、リダイレクト機能を使ってGETでブラウザに別の表示専用のURLに強制送還してそっちでHTMLや結果のメッセージを表示する。

こういう風にすると、リロードやブラウザバック等の機能を使われても2重送信が発生してしまう可能性がなくなります。

投稿2024/03/26 08:02

miyabi-sun

総合スコア21553

eisaku123

2024/03/26 08:50 編集

miyabi-sun　多くのアドバイスありがとうございます。とても説明わかりやすく参考になりました。ただ、別ホスト間の場合、「CSSで非表示にしたダミーのフォームをDOM上に展開しておき、そのフォームをJavaScriptの機能でsubmitする」じゃないと上手くいかない。けど、この手段でなんとかなってよかった思ってます。汗この場合、ブラウザーバックの対策は必要なさそうな感じですが、いかがでしょうか？

miyabi-sun

2024/03/26 10:41

> 別ホスト間の場合はfetchが使えないありますね。クロスオリジンリソース共有 (CORS) で調査してみてください。 HTTPリクエストのメソッドはGET、POST、PUT、DELETE、PATCHの5種類くらいしかないように思われがちですが、実はOPTIONというメソッドが存在してこのホストは許可してるのかな〜？みたいな事をチェックしているようです。外部サービスでもちゃんとしているWebAPIはfetch前提の作りになっててCORSの制限もゆるく作ってくれていたりします。ダメな場合は一度自分のホスト内でfetchのリクエストを受けて、そのまま受け流すリバースプロキシ作戦(PHPならfile_get_contentsとか)が使いやすいかと思います。 > この場合、ブラウザーバックの対策は必要なさそうな感じですが、いかがでしょうか？大丈夫そうですが、念の為、対応表を下記に記載しました。 fetch -> ブラウザーバックの対策は必要ない、好きなようにJavaScriptを動かして制御してねフォームのPOSTを伴うサブミットによるページ遷移 -> ブラウザーバックの対策が必要フォームのGETを伴うサブミットによるページ遷移 -> ブラウザーバックの対策は不要

eisaku123

2024/03/27 22:14

回答ありがとうございます。大変助かります。

行動規範の内容に同意します

location.hrefをどこに書いたかによるんですが（非同期で処理順もあるし）、

fetchのURL指定は
http://192.168.124.198/connect.php
一方location.hrefの指定は
http://localhost/connect.php

とドメイン部分が違ってます。
同じサーバ内の話でもドメインが違えば別セッションになるのではと思います（未検証ですが）。
もしfetchを実行しているHTMLが同じサーバなら
/connect.phpだけで良いのではと。

補足確認しました。

最終的には別ホストで実現したい

別ホストだとやはりセッションは別です。
遷移時にURLパラメータ（クエリストリング）つけて渡すしかないのではと。

投稿2024/03/26 04:28

編集2024/03/26 04:29

m.ts10806

総合スコア80890

eisaku123

2024/03/26 04:52

m.ts10806さんアドバイスありがとうございます。指定の方は、ご指導していただき、解決しました。本題は実は別ホストの場合です！！！。 >遷移時にURLパラメータ（クエリストリング）つけて渡すしかないのではと GETで送信するとできるということは、認識済みです。機密情報が見えてしまうのでセキュリティーに問題があるので、　POSTで送りたいのです。泣

m.ts10806

2024/03/26 05:01 編集

「画面遷移」はGETです。別途画面上に出ないformをJavaScriptで構成して（type=hiddenを一時的に作る） POSTでSUBMITする方法になりますかね。それでもブラウザのデバッグでデータを確認することは可能。 JavaScriptを経由する以上、クライアント側なので情報を見る手段は幾らでもあります。

m.ts10806

2024/03/26 05:02

要件次第にも思います。コードからしてあくまでサンプルで試しているようですが、本来の目的次第・要件次第では別角度からのアプローチも可能になるかもしれません。

eisaku123

2024/03/26 05:24

はいサンプルで試してます。最終的にはホスト１:Reactベースの認証画面(AWS Amplify)を通ると、ボタンが発生し、ボタンを押すとユーザー情報が一緒に今(GETのクエリーパラメーター)で送信されるホスト２：phpのwebアプリに辿りつくとGETからデータを受け取る。GETだと一緒に遷移する。これをPOSTにしたい。なお、Reactは超初心者。

m.ts10806

2024/03/26 06:37

2024/03/26 14:01のコメントに記載しています。再掲：別途画面上に出ないformをJavaScriptで構成して（type=hiddenを一時的に作る） POSTでSUBMITする方法になりますかね。それでもブラウザのデバッグでデータを確認することは可能。 JavaScriptを経由する以上、クライアント側なので情報を見る手段は幾らでもあります。

eisaku123

2024/03/26 08:24

はい、今、上記の内容で試してます。以下の様な記述をしました。上手く遷移はしました。なぜこれだと遷移するのでしょうか？ <form id="myForm" method="POST"></form> onClick={() => { const user_name = userData["custom:user_name"]; const company_code = userData["custom:company_code"]; const employee_code = userData["custom:employee_code"]; const user_type = 0; const array = [user_name, company_code, employee_code, user_type]; const myForm = document.getElementById("myForm"); const input = document.createElement("input"); input.setAttribute("type", "hidden"); input.setAttribute("name", "user_info"); input.setAttribute("value", array); myForm.appendChild(input); myForm.action = 'http://***.***.***.***/connect.php'; myForm.submit(); }}

m.ts10806

2024/03/26 08:25

formサブミットは遷移ではなくactionに指定した先への送信です。

m.ts10806

2024/03/26 08:28

今のところ別ホストにしなければならない理由が今一つ赤の他人には分からないので、別回答のような内容でのアドバイスがついてます。

eisaku123

2024/03/26 08:37

別ホストに作ってしまった理由は、知識不足の状態でAWSのAmplifyからcognitoを使用した認証画面を作成し、アプリはphpで作ってしまい、途中で戻れなくなってしまったからです。

m.ts10806

2024/03/27 02:33

ちょっと状況と全体像が分かりませんが、AWS上でPHP動かせるようにしたら良いのではないでしょうか。無理やり整合性を取ろうとするとどこかで綻びや問題点（特にセキュリティ問題）があとからあとから出てきて、より面倒な状況になると思います。

eisaku123

2024/03/27 22:33 編集

AWSのfargateでwebコンテナとしてPHPとして動かしています。 >問題点（特にセキュリティ問題）があとからあとから出てきて、より面倒な状況になると思います。 →はい、webコンテナの方はフルスクラッチで記述しているので非常に心配です。質問ですが、フレームワーク、例えばLaravelを使用した方が良いでしょうか？これでフルスクラッチと比べるとどれくらい解消できるのでしょうか？また工数はどれくらい削減できるのでしょうか？

m.ts10806

2024/04/01 02:21

「Laravel」に限定するなら、学習コストが高めのフレームワークと言う印象なので（「Web職人のための」という触れ込み）そのコストをきちんと出せるかどうかで違ってくると思います。が、一度覚えると他でも使えるようになるので、コストが許すなら覚えてプラスは大きいと思います。 ※ただ、別ドメイン間でのやりとりが解消するわけではないので、そこはあくまで設計レベルで解消してから取り組む必要があります

行動規範の内容に同意します

あなたの回答