- ベストアンサー
WordPressでのファイルアップロードの選択肢
- WordPressでFetch APIを利用してファイルをアップロードする方法が困難であることに悩んでいる。
- Ajaxを使ったファイルアップロード方法は多く存在するが、データベース保存が見つからず、サーバーディレクトリ保存が推奨される。
- 適切なアップロード方法を選定する際に、Fetch APIの利用可能性が判断基準となる。
- みんなの回答 (39)
- 専門家の回答
質問者が選んだベストアンサー
・ローカルストレージなどに保存しないと入力内容が消えるのではないかというアドバイス これは私は疑問に感じています。 消えるのかどうかわからないです。 どちらかと言うと消えないと思っています。 必ず消えるとかでないのなら、消えた場合に入力画面に戻るようにして、再入力してもらえばいいと思います。 消えないと言うか消えてもいいと言うか、セッションならこれは問題になりません。 私が想像しているセッションを使う場合の補足ですが、セッションは確定した登録用のものです。 表示切り替えはクライアント側のデータをそのまま使いまわします。 なのでサーバー側(セッション内容)とクライアント側のデータに相違があることがあるかもしれません。 それは確認画面まで進んでクライアント側のデータが改ざんされた場合ですが、それは無視します。 安全で確定したセッション内容を優先するからです。 そうすれば、確認画面から結果画面へ行く時は、「確認画面から結果画面へ行くよ」と言う情報しか(改ざんされたデータがない)サーバーに送信しないので安全です。
その他の回答 (38)
- dell_OK
- ベストアンサー率13% (766/5720)
・(クライアント側で保存するか、入力内容をそのまま残しておくかです。) 入力内容を保持する場合にセッションを使うということでしょうか? いいえ。 blobかIndexedDBでクライアント側で保持するか、 入力画面のフォームを非表示にするだけ(入力内容やアップロードファイルの情報はそのまま残る)ということです。 ・blob を使う方法と IndexedDB を使う方法どちらもコードを書いてみたいと思っております。 そうですね。 これは私にも勉強になるので、使い方は調べておきたいと思います。 ただ、セッションを使うのであれば、これらは必要ありません。 画面の行き来の間にデータを保持する方法は大きく分けるとふたつです。 サーバー側:セッション(データ送信およびバリデート1回) クライアント側:blob、IndexedDB、フォーム非表示(データ送信およびバリデート2回) 方法はいろいろあると思いますが、私が想像する方法としてはこんな感じです。 セッションの補足ですが、画面遷移する版と同じで、名前もコメントもスタンプもアップロードファイルもすべてセッションに保持します。
補足
説明ありがとうございます、理解することが出来ました。 セッションで保持する方法のみバリデート1回なんですね。
- dell_OK
- ベストアンサー率13% (766/5720)
・プライバシーモードでは使えない 使えなくてもいいと思います。 プライバシーモードに対応する必要があるとは思えません。 どのような場合のプライバシーモードを想定されていますか。 ・一旦サーバー側にファイルとして保存してやれば~~~想像がつきますでしょうか? 想像はつきます。 私が最初に一時ファイルと言ったのもこれのことです。 ごみファイルが残るのでこの案はなしでいいと思います。 ・こちらの対策につきましては window.addEventListener('beforeunload',~) これはブラウザが正常に終了した場合のことだと思います。 OSからタスクを強制終了した場合は動作しません。 他にもどのような状況で終了するか想定できないので、期待しない方がいいと思います。 とは言っても、やらないよりはやった方がいいです。 ・掲示板の起動時にも一時ファイルをチェックして、有ったら削除 一時ファイルはクライアントごとに作る必要があります。 一時ファイルがだれのものなのかを把握しておく必要があります。 正式なファイルにする時にはその人のものとして登録します。 削除の時にもその人のものとして削除します。 そのためクライアントのキーとなる情報が必要になってきます。 想像ですが、このような場合には、セッションを使ってセッションIDで識別することができると思います。 ただし、Chromeで確認する限り、複数タブでは同じセッションIDになるので、複数タブで別々の内容を送信するとどうなるかわかりません。 それと、その人が二度とアクセスしなかったら、ごみファイルが残ります。 一時ファイルの削除は、そのタイミングでもするうえに、サーバーでcronを使って定期的に削除した方がいいでしょう。 一日かけて質問や回答を投稿する人はいないでしょうから、一日より前のものは削除でいいと思います。 と説明はしましたが、一時ファイルはこのような手間が増えるのでやめておいた方がいいと思います。 それに、WordPressの記事表示方法の質問をされていた最初のころ、サーバーの容量が少ないことをとても気にされていた覚えがあります。 一時ファイルにしなくてもですが、今回の掲示板で画像のみならず動画もアップロードされるのですよね。 サーバーの容量は問題ないのでしょうか。 ・上記とは別に2つアドバイスを頂いたのですが~ そうですね。 ふたつの案はほぼ同じもののような気がします。 入力画面から確認画面へはサーバーはバリデートのためだけの処理です。 サーバーにはなにも保存しません。 クライアント側で保存するか、入力内容をそのまま残しておくかです。 確認画面から結果画面でもサーバーはバリデートする必要があります。 なぜなら、クライアント側に保存したものや、そのまま残しておいたものが、変更や改ざんされているかもしれないからです。 問題がなければ、サーバーのデータベースやファイルに保存することになります。 問題があれば、エラーを表示して入力画面に戻すことになります。 クライアント側でファイルが削除されることはあまり考えなくてもいいと思います。 送信したがっている人がファイルを削除することはないと思うからです。 質問や回答したい人なら削除しないでしょうし、攻撃しようとする人もそれを送信したいのだから削除はしないでしょう。 試しに、ファイルを削除して送信してみましたが、送信時(前)にJavaScriptでエラーになるようです。 なのでこのあたりで処理することになると思います。 ---- fetch() .then() .then() .catch(error => { /* ここでエラー処理 */ }); ---- ・ページ移動しないのであれば、blobでファイルを所持しておくのはどうだろうか。 blobがどのようなものかわかりませんが、できるのであればそれでもいいと思います。 IndexedDBでもいいと思っています。 入力画面をそのまま再送信でもいいと思っています。 どれが正解と言うことはないので、理解できて作りやすくて問題が起こりにくいもの、を選んでください。 私からも考えて欲しいことがあります。 それはデータ送信量です。 入力画面から確認画面へ行く時も、確認画面から結果画面へ行く時も、ほぼ同じ量のデータが送信されます。 アップロードファイルが大きければ大きいほどにその量は大きくなります。 携帯端末から送信する人がいるかどうかわかりませんが、もしいたら「ギガを食う」ことになります。 みなさん無制限の契約かどうかわかりませんが、ユーザーへの負担になります。 それはおいておいても。 サーバーにもクライアントにも2倍の負担がかかることは間違いありません。 送信が一回なら負担を増やさずにすみます。 それが、サーバー側でのセッションや一時ファイルになってきます。 サーバーで保持するのは入力画面から確認画面へ行く時だけです。 確認画面から結果画面へ行く時は保持したデータを使うので送信データはないに等しいです。 「確認画面から結果画面へ行くよ」と言う情報だけです。 この時はバリデーションも不要です。 一回目の送信で安全なデータであると確定しているからです。 なので非同期の応答がかなり早くなると思います。 二回送信した場合は、二回目が問題ないかもバリデーションが必要になります。 私から迷わすようなことを言うのもよくないですが、同じようなことをしているサイトとかはどのように作られているのでしょうね。 探せば似たようなことをしているサイトはいくらでもあると思うのです。 とは言っても、結局どちらかの方法だとは思いますが。 一時ファイルはないにしても、すでに作っている質問画面ではセッションを使っているので、セッションでならそのコードをなんとなく少しでも利用できそうな気はします。
補足
Q.プライバシーモードに対応する必要があるとは思えません。 どのような場合のプライバシーモードを想定されていますか。 A.回答ありがとうございます、プライバシーモードは現在使われていない機能だと思うのですが、今後未来の事を考えるとやや不安になっております。 Q.私が最初に一時ファイルと言ったのもこれのことです。 ごみファイルが残るのでこの案はなしでいいと思います。 A.回答ありがとうございます、一時ファイルの事だったんですね理解できました。 Q.こちらの対策につきましては window.addEventListener('beforeunload',~) これはブラウザが正常に終了した場合のことだと思います。 OSからタスクを強制終了した場合は動作しません。 A.説明ありがとうございます、スマートフォンでは対応できないとのことで覚えておきます。 Q.ただし、Chromeで確認する限り、複数タブでは同じセッションIDになるので、複数タブで別々の内容を送信するとどうなるかわかりません。 A.説明ありがとうございます、 dell_ok さんのアドバイスをお聞きしたところ実装するのは問題がありそうですね… Q.一時ファイルにしなくてもですが、今回の掲示板で画像のみならず動画もアップロードされるのですよね。 サーバーの容量は問題ないのでしょうか。 A.回答ありがとうございます申し訳ありません、データベースの使用量を確認したところかなり余裕があるようで、容量は問題ないようでした。 MySQL® ディスク使用量 36.64 MB / 142.13 GB Q.クライアント側で保存するか、入力内容をそのまま残しておくかです。 A.アドバイスありがとうございます、ファイル削除について勉強になりました。確かに途中で削除するパターンはなさそうです。 入力内容を保持する場合にセッションを使うということでしょうか? Q.blobがどのようなものかわかりませんが、できるのであればそれでもいいと思います。 IndexedDBでもいいと思っています。 入力画面をそのまま再送信でもいいと思っています。 A.回答ありがとうございます、blob を使う方法と IndexedDB を使う方法どちらもコードを書いてみたいと思っております。 Q.入力画面から確認画面へ行く時も、確認画面から結果画面へ行く時も、ほぼ同じ量のデータが送信されます。 携帯端末から送信する人がいるかどうかわかりませんが、もしいたら「ギガを食う」ことになります。 サーバーにもクライアントにも2倍の負担がかかることは間違いありません。 送信が一回なら負担を増やさずにすみます。 A.アドバイスありがとうございます、仕組みをやっと理解することが出来ました。セッションの場合は負担を半分に出来るんですね、メリットがよくわからず別の方法を模索しておりました。 Q.私から迷わすようなことを言うのもよくないですが、同じようなことをしているサイトとかはどのように作られているのでしょうね。 探せば似たようなことをしているサイトはいくらでもあると思うのです。 とは言っても、結局どちらかの方法だとは思いますが。 一時ファイルはないにしても、すでに作っている質問画面ではセッションを使っているので、セッションでならそのコードをなんとなく少しでも利用できそうな気はします。 A.アドバイスありがとうございます、頂いたアドバイスを統合すると大きく分けて2つあるようです。 一番初めにヤフー知恵袋がどのように作られているのか質問したときに Javascript で表示と非表示を切り替えているとの回答を頂きました。 dell_ok さんにアドバイスを頂きながらセッションで作成している際に、セッションでアップロードファイルをどのようにして非同期通信で送るのか心配だったので goo で質問致しました。 それから JavaScript で確認画面を出す場合、ローカルストレージなどに保存しないと入力内容が消えるのではないかというアドバイスを頂いたためdell_ok さんに教えて頂いたローカルストレージを使う方向で考えておりました。 上記のことを踏まえるとセッションを使い名前やメッセージを保存して、ファイルサイズの問題からローカルストレージ(IndexedDB)を使いファイルアップロードする方法が1つ分かりました。 2つめの方法になるのですが、 テラテイルでブラウザ標準データ保管機能 LocalStorage が容量不足のため代用できる方法について質問をした際に、プログラマーの方からページ移動しないのであれば blob でファイルを所持する方法もあるのではないかとアイデアを頂きそちらも可能ではないかと考えております。
- dell_OK
- ベストアンサー率13% (766/5720)
・専用のコードは書かないのでしょうか? ファイル入出力に関するコードはありません。 単純に値を設定したり参照したりするだけです。 localStorage.setItem("namae", document.getElementBy("namae").value); document.getElementBy("namae").value = localStorage.getItem("namae"); ・ファイルサイズが5MBから10MBと少なく可能であれば別の方法を取りたいと考えております… そうですね。 容量に問題がありそうですね。 ・IndexedDBというサービスを代用できないかと考えているのですが、Local Storage を使わずに非同期通信は行えないでしょうか…? できると思います。 上記のような簡単なコードにはならないとは思いますが、やってみてください。
補足
回答ありがとうございます。 IndexedDB を詳しく調べたところブラウザのプライバシーモードでは使えないという事が分かり、ブラウザシェア率を見ると画像と動画で分ける必要が出てきてしまいました… 2019年1月現在、主要ブラウザでプライバシーモードでも使えるのはChromeのみとのことで、Safariユーザーが使えない現象も出てくる可能性もあり動画と画像で掲示板を分けるのが最善ではないかと考えております。 ※ブラウザシェア率 https://ohdo.at21.jp/web/browser-market-share/ その他の方法について再度見直してみたところ、ぺージが遷移しないなら、最初の入力画面で「<input type="file" >」からローカルのアドレスを取得して、 一旦サーバー側にファイルとして保存してやれば、そのURLをクライアント側に渡せば良いとのアドバイスを頂いておりました。 上記のアドバイスの意味がよく理解できていないのですが、dell_okさんには想像がつきますでしょうか? >キャンセルボタンを押さずにブラウザを閉じられたり、不慮の終了があると削除する指示をクライアントから送信するのが難しくなるのではないかと考えております。 こちらの対策につきましては window.addEventListener('beforeunload',~) でブラウザを閉じる際のイベントで対策が可能ではないかとのご指摘を頂きました。 掲示板の起動時にも一時ファイルをチェックして、有ったら削除すればもっと確実に対策できるとのことでした。 ファイルからURLを取得してページに表示する https://gray-code.com/javascript/get-url-object-from-file-object/ _______________________________ 上記とは別に2つアドバイスを頂いたのですが、どの方法が良いか決めかねております… ①バリデートを非同期でおくってエラーがなければ本番送信すればファイルは消えない。 ②非同期でサーバにファイルを送信してバリデーションし、サーバ側の一時ファイルなどを使わずに、ローカルの同じファイルを送信する。 その間にユーザがファイルを消したらエラーメッセージをだす。 ページ移動しないのであれば、blobでファイルを所持しておくのはどうだろうか。
- dell_OK
- ベストアンサー率13% (766/5720)
なのでローカルストレージがいいと思います。
補足
回答ありがとうございます、ローカルストレージで考えていたのですが、アップロードできるファイルサイズが5MBから10MBと少なく可能であれば別の方法を取りたいと考えております… IndexedDBというサービスを代用できないかと考えているのですが、Local Storage を使わずに非同期通信は行えないでしょうか…? ※IndexedDB https://zenn.dev/tm35/articles/584ece2d771a4b ※XSS対策について https://techracho.bpsinc.jp/hachi8833/2019_10_09/80851
- dell_OK
- ベストアンサー率13% (766/5720)
過去の回答を見返していました。 一時ファイルについては、私が最初に言ったようですね。 セッションに保存するのとほぼ同じ意味で使いました。 先日話した通り、削除するタイミングが得られない場合があるためこの案はなしです。
- dell_OK
- ベストアンサー率13% (766/5720)
・「JavaScriptで確認画面を出すとなると、ローカルストレージなどに保存しないと入力内容が消えるかと思います。」とのアドバイスを以前いただいたのですが、一時ファイルだと消えてしまわないでしょうか? 私が勘違いしていたらすみません。 私が思っている一時ファイルとはJavaScriptのローカルストレージのことです。 ローカルストレージはファイルに対するオープンクローズや読み書きのJavaScriptコードはありません。 それは、localStorage.setItem()やlocalStorage.getItem()が内部的にやっているため、プログラマがファイルを意識する必要がないだけで、実際はファイルに保存されています。 そのため、このローカルストレージを一時ファイルと言っている人がいて、質問者さまもそれにならってそう言っているのかと思っていました。 ローカルストレージはブラウザのサイトデータとして保存されています。 Chromeでは、設定、プライバシーとセキュリティ、サイトの設定、すべてのサイトに保存されている権限とデータを表示、で確認できます。 ファイルに保存されているので、ブラウザを閉じても保存されたままですし、開きなおしたブラウザで復元もできます。 ・1点心配なことがあるのですが、IPアドレスはデータベースに保存せずに取得可能なのでしょうか?一時ファイルを介するためIPが取得できないのではないかと考えております。 ・base64で保存する方法の代わりに File API を使う方法も良いとアドバイスを頂いているためIPアドレスの取得が一時ファイルで出来ない場合こちらの方法で考えております。 IPアドレスはサーバーへ送信された時にサーバー側でサーバー変数($_SERVER['REMOTE_ADDR'])で取得するので、一時ファイルやbase64やFile APIとは関係ありません。 $_SERVERはプログラムやユーザーが意識して送信や設定しているものではありません。 インターネットはサーバーとクライアントが通信しているわけですが、通信相手と相互に接続しているためお互いの接続情報が確立していてお互いが把握しています。 その情報をApacheなどのWebサーバーが持っていて、それを$_SERVERで確認できるのです。 クライアントのIPアドレスはその通信接続上の情報として$_SERVERにあるのです。 人間はこれを意識する必要がないので、「よくわからないパソコンやスマートフォンから、よくわからないサーバーへ接続しているのだろうなあ」って感じだと思いますが、実際は1対1で通信していると思っていただいてもいいと思います。 とは言ってもうのみにはしないでくださいね。 実際は、間にアクセスポイントだのルーターだのスイッチングハブだのファイアウォール機器だのあったりで、どの程度の情報で接続されているのか、接続情報のどこまでが$_SERVERにあるのかと言うのは私もわかっていませんので。
お礼
補足
Q.私が思っている一時ファイルとはJavaScriptのローカルストレージのことです。 ローカルストレージはファイルに対するオープンクローズや読み書きのJavaScriptコードはありません。 A.回答ありがとうございます、送信内容を JavaScript のローカルストレージに保存する方法を調べてみたのですが、専用のコードは書かないのでしょうか? Q.ローカルストレージはブラウザのサイトデータとして保存されています。 Chromeでは、設定、プライバシーとセキュリティ、サイトの設定、すべてのサイトに保存されている権限とデータを表示、で確認できます。 ファイルに保存されているので、ブラウザを閉じても保存されたままですし、開きなおしたブラウザで復元もできます。 A.説明ありがとうございます、理解することが出来ました。 Q.IPアドレスはサーバーへ送信された時にサーバー側でサーバー変数($_SERVER['REMOTE_ADDR'])で取得するので、一時ファイルやbase64やFile APIとは関係ありません。 A.$_SERVERについての説明ありがとうございます、サーバーへ送信された時に取得可能ということで覚えておきます。
- dell_OK
- ベストアンサー率13% (766/5720)
私も一時ファイルにbase64で保存する方法が一番いいと思います。
お礼
申し訳ありません、ファイル名(temporary.php)をつけ忘れておりました。よろしくお願い致します。 https://wandbox.org/permlink/6EK9sbiY6BM5U8HD
補足
※現在のコード( temporary.php に追加コードのみを書きました。) https://wandbox.org/permlink/YHzudNo6BTRQdP2u 回答ありがとうございます、以下の流れで作成してみたのですが、3.の入力画面に戻る場合非表示ではなく要素削除する機能をどのように書けばよいのか分からずアドバイス頂きたいです。 1.入力画面(フォーム) 2.一時ファイルにbase64で保存する(サーバーへは送信しない) 3.確認画面(入力画面に戻る場合非表示ではなく要素削除) 4.サーバーへ送信 5.結果画面 ※戻る場合名前やメッセージは上記の方法を使い、アップロードファイルはbase64で表示する 1点心配なことがあるのですが、IPアドレスはデータベースに保存せずに取得可能なのでしょうか?一時ファイルを介するためIPが取得できないのではないかと考えております。 ※IPアドレス保存コード(functions.phpの32行目) 「JavaScriptで確認画面を出すとなると、ローカルストレージなどに保存しないと入力内容が消えるかと思います。」とのアドバイスを以前いただいたのですが、一時ファイルだと消えてしまわないでしょうか? base64で保存する方法の代わりに File API を使う方法も良いとアドバイスを頂いているためIPアドレスの取得が一時ファイルで出来ない場合こちらの方法で考えております。 JavaScriptでローカルファイルを自在に操る - File API https://thinkit.co.jp/story/2013/02/06/3953?nopaging=1&page=0%2C1 ※csvについて https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q13249041388 ※フォームから送信されたデータをcsvファイルに保存 https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q12190122502?__ysp=5YWl5Yqb44OV44Kp44O844Og44GL44KJ6YCB5L%2Bh44GX44Gf44KC44Gu44KSY3N244Gr5L%2Bd5a2Y ※issetの代わりにfilter_input を使う https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q13178308348?__ysp=aWYgKGlzc2V0KCRfUE9TVFsnYW5zd2VyJ10pKSB7IGNzdg%3D%3D https://qiita.com/mpyw/items/2f9955db1c02eeef43ea https://agohack.com/php-filter-input/
- dell_OK
- ベストアンサー率13% (766/5720)
ファイルのアップロードは以下のどちらかで大丈夫だと思います。 1.入力画面から確認画面に行く時にサーバーのセッションに保存する 2.一時ファイルにbase64で保存する 1でセッションに保存する理由を説明しておきます。 もしファイルに保存するとしたら、確認画面でキャンセルされた時にそのファイルを削除しないとサーバーに不要なファイルが残ってしまいます。 キャンセルされたら削除すればいい、と思うかも知れませんが、キャンセルボタンを押すでもなく、ブラウザを閉じられたり、不慮の終了があると、削除する指示をクライアントから送信するのが難しくなります。 実はセッションもサーバー上のファイルなので不要なファイルとして残ることがありますが、たいていの場合、PHPの設定などでその寿命が決められているので、いつの間にか消えていると思います。 それはそれでどのように設定されているか調査しておくのと、設定する方法を勉強しておいた方がいいと思います。 2はローカルファイルが削除されても問題ありません。 ファイルのURLを覚える方法も、実際のローカルファイルではなく、ブラウザのキャッシュファイルの場所だと思うので、たぶん大丈夫だと思います。 ただ、そのURLからファイルを送信する方法はわかりませんが、ややこしい方法より、base64でいいかなと思います。
お礼
いくつか疑問な点があり質問をしてアドバイス頂きました。ファイルに保存する、一時ファイルにbase64で保存する、URLからファイルを送信する?方法すべて可能なようです。 アドバイス頂いたことも含めて考えてみて一時ファイルにbase64で保存する方法が一番良いと思ったのですが dell_OK さんはどう思われますでしょうか? どれもセキュリティ対策を行うことでウイルスの対策はできるようです。 Q.ファイルに保存する場合に確認画面でキャンセルされた際そのファイルを削除しないとサーバーに不要なファイルが残ってしまう可能性はありますでしょうか? A.当然、有ります。 注意点としてはサイズが大きなファイルは制限したりして、エラーメッセージを出すようにするのが一般的です。 入力画面でも画像のファイルサイズの制限を書いておく。 Q.キャンセルボタンを押さずにブラウザを閉じられたり、不慮の終了があると削除する指示をクライアントから送信するのが難しくなるのではないかと考えております。 A.試したことは無いですがブラウザを閉じる際のイベントが使えると思います(下記)。 window.addEventListener('beforeunload',~) 掲示板の起動時にも、一時ファイルをチェックして、有ったら削除すれば、もっと確実でしょう。 Q.入力画面から確認画面に行く時にサーバーのセッションに保存する方法はセキュリティ上問題ないでしょうか? セッションでもファイルのアップロードは可能なようで、名前やメッセージ等あわせて送信する場合にまとめるのに便利だと思ったのですが… A.セッションを使わなかったとしても、掲示板自体のデータがハッキングされたらパスワードのデータも抜かれる訳で、通常は気にしても意味無いです。 とりあえず、パスワードのデータは暗号化しておけば、素人ハッカーだけなら対応できるでしょう(素人がハッキングツールを持ってる場合)。 Q.上記の理由からローカルファイルが削除されても問題ない一時ファイルにbase64で保存する方法が最適ではないかと考えているのですがいかがでしょうか? A.相手が素人なら有効でしょうが、base64で保存ぐらいでは本物のハッカーには全く無意味です。 Q.ファイルのURLを覚える方法もあるようで実際のローカルファイルではなく、ブラウザのキャッシュファイルの場所になると思われるため恐らく大丈夫だと思うのですが、URLからファイルを送信する方法が分からないのでbase64で保存する方法で作成する予定です。 A.JavaScriptでローカルファイルを自在に操る - File API https://thinkit.co.jp/story/2013/02/06/3953?nopaging=1&page=0%2C1
補足
A.説明ありがとうございます、理解出来ました。ファイルに保存する方法は適してないようですね。 セッションの場合は自然消滅させることも可能なんですね、2の base64 で考えようと思います。
- dell_OK
- ベストアンサー率13% (766/5720)
・一時ファイルを使わない場合の流れはどのような形になるのか分かりますでしょうか? ・入力画面をフォームにしないという構想 確認画面をフォームにしない話しでしょうか。 1.入力画面(フォーム) 2.サーバーへ送信 チェックして問題があればエラーメッセージを返し入力画面のまま そうでなければセッションに保存し、確認画面へ表示するデータを返す 3.確認画面(表示のみ、フォームなし、入力画面へ戻るのは要素の表示非表示切り替え) 4.サーバーへ送信 セッション内容をデータベースとファイルに保存する 5.結果画面
補足
回答ありがとうございます、下記のようにアドバイスを頂いたのですが、一時ファイルでも問題があるようです。 セッションを使う方法については触れられる方がおられないため、使うことも可能ではないかと思っております。ファイルアップロードでエラーが発生しないことが最優先になりそうです。 ※頂いたアドバイス Q.アップロードファイルを戻したい場合input要素として戻せないため A.ぺージが遷移しないなら、最初の入力画面で「<input type="file">」からローカルのアドレスを取得しておけば良いでしょう。 ファイルからURLを取得してページに表示する https://gray-code.com/javascript/get-url-object-from-file-object/ Q.確認画面を出す場合一時ファイル等に保存しないと入力内容が消える可能性がある A.上記の手法でも、ユーザーがファイルを消してしまった場合は使え無いですね。 一旦サーバー側にファイルとして保存してやれば、そのURLをクライアント側に渡せば良いだけですよ。
- dell_OK
- ベストアンサー率13% (766/5720)
・入力フォームから送信したものを一時ファイルに保存するような形になるのでしょうか?… たぶんそうです。 ですが、サーバーに送信してもチェックのみを実行するだけになると思うので、非同期送信の役割が半減するような気がして、正直言うと、一時ファイルを使うメリットがわからないでいます。 以下のような流れなら、まだわかるような気はします。 1.入力画面 2.一時ファイルへ保存(サーバーへは送信しない) 3.確認画面 4.サーバーへ送信 5.結果画面 3から1へ戻る時には一時ファイルから復元。
補足
回答ありがとうございます、一時ファイルを使わない場合の流れはどのような形になるのか分かりますでしょうか? 入力画面をフォームにしないという構想の話から理解が追いついておらず比較するためにもどのような形になるのか教えて頂きたいです。
補足
Q.ローカルストレージなどに保存しないと入力内容が消えるのではないかというアドバイス 必ず消えるとかでないのなら、消えた場合に入力画面に戻るようにして、再入力してもらえばいいと思います。 消えないと言うか消えてもいいと言うか、セッションならこれは問題になりません。 確認画面から結果画面へ行く時は、「確認画面から結果画面へ行くよ」と言う情報しか(改ざんされたデータがない)サーバーに送信しないので安全です。 A.回答ありがとうございます、dell_ok さんと同じように考えている方もおられるようで消えないかもしれません… 条件で消えるようであれば再入力してもらう方法がよさそうですね。 非同期通信という事で画面が還移する場合と違うのではないかと心配になっておりました。データをチェックして対策すれば問題ということでコードを考えていきます。