トップページ⇒php
1002コメント362KB

PHP質問・雑談スレ【初心者お断り(ROM歓迎)】©5ch.net

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん 転載ダメ©2ch.net2016/04/22(金) 08:58:11.47ID:???
PHP関する質問や雑談をするスレです。
初心者お断り(ROM歓迎)と書いてますが、初心者用のスレが用意されているからで、
難しい質問や話題をしなければいけないわけではありません。
PHPマニュアルの読み方を概ね理解していて、関数リファレンスが正しく読める方用のスレです。

PHP未導入の方や、手取り足取りが必要な初心者の方はくだスレへどうぞ。
【PHP】下らねぇ質問はここに書き込みやがれ 4
http://echo.2ch.net/test/read.cgi/tech/1457792733/

その他リンク
・PHPマニュアル
　https://secure.php.net/manual/ja/index.php
・コードテスト・貼り付け用
　http://ideone.com/
・プログラミングのお題スレ Part8　（求PHPer参戦）
　http://echo.2ch.net/test/read.cgi/tech/1444216746/

このスレで扱う話題
・PHPのコード，設定や設定値に関する質問
・常識的範囲内でのコードレビュー依頼・改良相談
・PECL，PEARに関する質問
・PHP新機能やPHP関連トレンドの話題
　（FWや非公式ライブラリの話題や特徴比較は良いが使い方から先の話題は専スレへ）
・PHPのバグ発見報告・公式に報告する前の検証依頼

このスレで扱わない話題
・直接関係ない○○特有の質問（専スレへ）
　（HH，エディタ，IDE，サーバ，OS，DB，SQL，FW，テンプレート，非公式ライブラリ・アプリケーション等）
・PHPの改造
0286nobodyさん2016/08/21(日) 01:38:08.27ID:???
http://php.net/manual/ja/class.errorexception.php
ここの例を参考にしてErrorExceptionを補足すればいい
0287nobodyさん2016/08/21(日) 01:42:37.43ID:???
>>285
お前はこのスレにいちゃいけない
なぜならこのスレに不満を持っているからだ
わかるか？さっさと出ていけばチンパン？ｗｗｗｗ
しかしお前PHP馬鹿にしつつPHP大好きなんだなｗｗｗｗ
Quitaとか自己主張強いオタ野郎丸出してマジ引くわーｗｗｗｗ
0288nobodyさん2016/08/21(日) 01:45:15.68ID:???
頭でっかちで社会から相手されない典型
ずっと高地で引きこもってろよチンパンｗｗｗ
0289nobodyさん2016/08/21(日) 01:47:08.78ID:???
>>287
>お前はこのスレにいちゃいけない

お前がこのスレにいたらお前が困るだけだろｗ

>しかしお前PHP馬鹿にしつつPHP大好きなんだなｗｗｗｗ

PHPを馬鹿にしたことは一度もないけど、なんか天から声が聴こえるタイプかな？

>Quitaとか自己主張強いオタ野郎丸出してマジ引くわーｗｗｗｗ

匿名で2chに落書きする事しかしたことないカニ味噌くんにはわからないだろう。
キータは君みたいなおサルさんが進化するアイテムとしては、とても良く出来ている。
本当にゴミクズ記事ばかりだが、それらを集めたら結構な資産になるから不思議だ。

だからググッてキータが上位に来ても、別にイラッとしない。
それらを合わせて解をだせばいいだけだ。

カニ味噌では理解できないのもわかるけどな。
0290nobodyさん2016/08/21(日) 01:48:38.53ID:???
>>288
> ずっと高地で引きこもってろよチンパンｗｗｗ

低地にいる猿もいるんだが、知らないのかい？
で、引きこもってるのはどう見ても君だろう。
0291nobodyさん2016/08/21(日) 02:40:57.09ID:???
>>283,284,286
ありがとうございます。おかげですっきりしてきました。
>>ここの例を参考にしてErrorExceptionを補足すればいい
set_error_handlerとかは、クラスライブラリを作成する側で使ってはいけませんよね？
クラスライブラリの利用者やアプリの開発者側で使うものですよね？？
ということで、クラスライブラリの方では、先ほどのpreg_matchの例だと
if (preg_match( ) === false) {
　$detail = error_get_last();
　throw new ErrorException($detail['message'], 0, $detail['code'], $detail['line'], $detail['file']);
}
で、こんな感じで例外に全部変換しておきます。
0292nobodyさん2016/08/21(日) 12:09:24.42ID:???
>>291

> if (preg_match( ) === false) {
> 　$detail = error_get_last();
> 　throw new ErrorException($detail['message'], 0, $detail['code'], $detail['line'], $detail['file']);
> }
> で、こんな感じで例外に全部変換しておきます。

いや、投げるのはErrorExceptionじゃない方が良いと思うよ。
ErrorExceptionはPHP側のWarningやNoticeが発生した場合に投げる。

自分で判定して投げる例外と、言語的なエラーで投げられる例外の区別つかなくなっちゃうから、
自分で判定して投げる例外は単にExceptionにするか、
Exceptionを継承した独自例外クラスを作ってそれのオブジェクトを投げるようにした方が良いと思う。

そうすると、catchする例外で処理が分けられるから随分エラーハンドリングとデバックが楽になるはずだ。
0293nobodyさん2016/08/22(月) 10:30:09.61ID:???
>>194から始まった話題ということがわかってない奴おおすぎ。
それに絡めて、>>196から「自動ログイン」の話も始まってる。

で、>>201（妥当）なんだが、>>202から話の流れがわかってない奴が発狂という流れ。
0294nobodyさん2016/08/22(月) 10:32:20.54ID:???
で、>>228がアホの極みで、いつのまにかサーバで保持しているセッション情報が全て流出するとか、
システムで管理しているユーザID・パスワードが全部流出するとかいう話に勝手にして沸騰。

そんなのそれより上の流れと違うに決まってるでしょ。
0295nobodyさん2016/08/22(月) 10:53:53.94ID:???
まぁ、何するにせよ、coockieはhttponlyでsecureにしてSSL使えというのがFA。
0296nobodyさん2016/08/22(月) 14:08:56.99ID:???
俺が見る限り>>203=>>201がアホな発言したからこんなに荒れたように見えるが。

ユーザーのパスワードが漏れるのと一時的なパスワード以外のセッション情報が
漏れるのを完全に同一視した>>203の発言が発端。
0297nobodyさん2016/08/22(月) 14:48:13.83ID:???
>>296
> ユーザーのパスワードが漏れるのと一時的なパスワード以外のセッション情報が
> 漏れる
正しくは違う。

cookieに保存されているなにかが漏れたときに話で、それがユーザID+パスワードだろうが
PHPSESSIDだろうが、その他の（自動）ログインに必要な情報だろうが、漏れたら一緒だろってこと。

まぁ、一緒というのは言いすぎで、もちろんセッションが無効になってたりしたら事情は違うが。
0298nobodyさん2016/08/22(月) 14:49:23.98ID:???
で、PHPSESSIDだって漏れたら困るわけで、だからみんな漏れないようにしてる。
0299nobodyさん2016/08/22(月) 14:58:43.11ID:???
>>297
一緒の「主語」がはっきりしてないけどさ(俺もだったけど)。
被害が一緒じゃないから>>228は１人のケースじゃわかりづらいから規模を10000人にして、
10000人のパスワードが漏れるのと10000人のセッションIDが漏れるのとで、
システム管理者の対策が同じなのかよ？？って疑問を投げかけたんじゃないの？？
もちろん、セッションID漏れるのもまずいけど、

パスワード漏れると、パスワード変えられてアカウントハックされるし、
セッションID漏れても、パスワード変更するときに再ログイン強制させてれば、多少大丈夫だし
完全に一緒じゃないじゃんって話をみんなしてたんじゃないの？？
0300nobodyさん2016/08/22(月) 15:00:12.17ID:???
だから、事の発端は

>>203=>>201が完全に一緒みたいな事を言ったのが事の発端で、

それに対して他が完全に一緒じゃないって反論してたんだろ
0301nobodyさん2016/08/22(月) 15:05:35.05ID:???
>>まぁ、一緒というのは言いすぎで、もちろんセッションが無効になってたりしたら事情は違うが。
自分で同一じゃないって言ってんじゃん。
パスワード漏れるのとセッションID漏れるのとでは、「「完全」」に一緒じゃないから、
クッキーにセッションID格納するのと同じ感覚でパスワードも格納なんかしないよって他はいってんでしょ。

だから、事の発端は>>203のパスワード漏れるのとセッションIDが漏れるのを「「「完全に同一」」みたいな
発言をしたことなんだよ。
それに対して他が「「完全に同一」」じゃないって反論してるんだよ。
0302nobodyさん2016/08/22(月) 15:07:10.79ID:???
>>299
> 10000人のパスワードが漏れるのと10000人のセッションIDが漏れるのとで、
> システム管理者の対策が同じなのかよ？？って疑問を投げかけたんじゃないの？？
それ、サーバ側で情報が漏れたときの話じゃないの？

> パスワード漏れると、パスワード変えられてアカウントハックされるし、
普通変えないでしょ。

>>300
> それに対して他が完全に一緒じゃないって反論してたんだろ
反論のポイントが見当違いだってこと。
0303nobodyさん2016/08/22(月) 15:11:45.28ID:???
>>301
> クッキーにセッションID格納するのと同じ感覚でパスワードも格納なんかしないよって他はいってんでしょ。
俺は>>203じゃないから違ってるかもしれないけど、>>203は、自動ログインを実現するためにセッションIDや
ユーザID+パスワードじゃない何かを使ったとしても、もしそれが漏れたら一緒だろと言ってると思う。

パスワードを格納するよと言ってる奴は誰もいなくて、多分>>194もそのユーザIDとパスワードを保存するような
困ったちゃんがいるんだが、って報告なんだと思う（想像）。
0304nobodyさん2016/08/22(月) 15:11:45.95ID:???
>>302
>反論のポイントが見当違いだってこと。
見当違いとは思わんけど、みんなそこ(>>203=>>201)に反論してるんだよ。

話の流れ理解できないで騒いでたのか・・・
0305nobodyさん2016/08/22(月) 15:18:52.99ID:???
はあ、そうですか。
完全一致じゃないことなんか自明なんで、そこにこだわってるなんて想像できなかったわ。

あと蛇足だけど、ブラウザにパスワード覚えさせろって人がいたけど、PCにログインされちゃえば
Chromeなんかは生パスワードが全見えなんで気をつけろよ。
0306nobodyさん2016/08/22(月) 15:40:10.81ID:???
>>305
そもそもOSのユーザパスワードが漏れたら生パスワードが見られるのは当然だろう
0307nobodyさん2016/08/22(月) 15:46:37.72ID:???
PC使われたら基本アウト
0308nobodyさん2016/08/22(月) 15:49:19.67ID:???
漏れなければ、ユーザIDとパスワードをcookieに保存して自動ログインに使っても問題ない
0309nobodyさん2016/08/22(月) 15:49:20.94ID:???
君がどの発言したか知るよしもないが、
>>完全一致じゃないことなんか自明
とかいっておきながら>>296で
>>>201（妥当）
>>201つまり>>203が妥当とか言ってるのがようわからん・・

>>217の人だって
>（例えばセッション情報等の）ログインに必要な情報 =（結局password同様）
>という等号が成り立つと思ってるところが
>お前がアホ極まれリなところ。
要するにセッションIDが漏れるのとパスワードが漏れるのが「完全に同一か？」
どうかを問題にしてて、みんなそこにこだわってそこ(>>203=>>201)を議論してるんじゃね？
0310nobodyさん2016/08/22(月) 15:57:25.91ID:???
>>309
これ以上議論する意味はほぼないと思うが、本意が伝わってないと思われるのでもう一度書く。

>>201が言ってるのは（俺の想像にすぎないが）
> 要するにセッションIDが漏れるのとパスワードが漏れるのが
という対立構造じゃなくて、自動ログインを実現する場合に、いずれにせよ何らかの情報を
cookieに保存せざるを得ず、それが漏れるのとcookieに保存したユーザID+パスワードが
漏れるのは同じでしょ言ってるんだと思う。

で、俺もそう思う。
何が一緒なのかというのは、「漏れたら第三者にそれを使ってログインされるというセキュリティリスク」。
セッションが有効な間のPHPSESSIDも同じ。
0311nobodyさん2016/08/22(月) 16:03:10.87ID:???
>>310
「漏れたら第三者にそれを使ってログインされるというセキュリティリスク」に限っては同一かもしれないが, セキュリティリスク全体として見ればパスワードの漏えいの方が遥かに重大
その上で「漏れたら一緒でしょ」って言ったらそりゃ反論されるでしょうよ
パスワードをCookieにせよSessionにせよ生で保存するのがあり得ない, という前提が文脈から判断出来れば, 経緯は変わってたと思うけども
0312nobodyさん2016/08/22(月) 16:09:34.37ID:???
>>311
> パスワードをCookieにせよSessionにせよ生で保存するのがあり得ない, という前提が文脈から判断出来れば, 経緯は変わってたと思うけども
>>201はそれが前提だと俺は読んだんだが。

> password以外のログインに必要な情報はクライアントが持ってるんだし
つまり、passowrdを保存しない場合でも、という前提の話。
0313nobodyさん2016/08/22(月) 16:11:39.32ID:???
つか、>>201出てこいや
0314nobodyさん2016/08/22(月) 16:14:33.21ID:???
>>194があって, >>195-200まで(>>197を除いて)「保存しないでしょ」って流れがあった上で>>201でしょ？
「パスワードをCookieにせよSessionにせよ生で保存するのがあり得ない」の流れを否定するように読めこそすれ, その逆にはちょっと読めないなぁ

まぁ本人居ないからあんまり有意義ではないけど(居ても有意義でないだろうけども)
0315nobodyさん2016/08/22(月) 16:17:31.68ID:???
>>200
> cookieが安全かどうかはブラウザがhttponlyに対応しているかとXSSを封じているかが関与してくる。
> そんなとこにpasswordを入れるかどうか議論したい馬鹿がいるのか？
> もっと言うと、自動再ログインにpassword利用する猿がいるのか？

>>201
> password以外のログインに必要な情報はクライアントが持ってるんだし
> それが漏れたら一緒でしょ

の流れで、201の「それ」がpassowrdだとは読めないんですが・・・。
0316nobodyさん2016/08/22(月) 16:21:15.74ID:???
>>315
「それが漏れたら一緒でしょ」というのは話の流れとして「[password以外のログインに必要な情報]が漏れたら[passwordが漏れるのと]一緒でしょ」と読めるわけだ
0317nobodyさん2016/08/22(月) 16:28:18.43ID:???
>>316
え、一緒でしょ（ループ）
0318nobodyさん2016/08/22(月) 16:30:49.43ID:???
この話もういいんじゃねww
0319nobodyさん2016/08/22(月) 16:33:00.44ID:???
まあ俺からすれば、「話の流れ理解できない」奴は>>204以降の奴でしょといいたいだけなんだがね。
もう止めとくかｗ
03202222016/08/22(月) 18:00:31.26ID:???
…
0321nobodyさん2016/08/22(月) 18:56:15.46ID:???
まだチンパンいたのか？向こうのスレでもケンカしてるようだがお前暇人でいいな
ニートにゃ台風もくそもないかｗｗ
0322nobodyさん2016/08/22(月) 20:04:51.91ID:???
>>313

>>321　←　こいつがその馬鹿みたいだよ。
0323nobodyさん2016/08/22(月) 20:13:10.95ID:???
なんか今日は向こうもこっちもアホばっかで、2chじゃ話の流れがよくわからん。
つーか、お前ら月曜日の真っ昼間に何やってんだよ。仕事ねーのか？
0324nobodyさん2016/08/22(月) 21:22:49.99ID:???
ワッチョイの有り難みがよくわかったね。やったね。
0325nobodyさん2016/08/22(月) 21:41:01.14ID:???
向こう？ってどこ？？
プログラム版に似たスレあったっけ？
0326nobodyさん2016/08/23(火) 18:06:29.08ID:???
ワッチョイあろうがなかろうが>>324みたいな馬鹿が1人で暴れてるってのがよくわかるだろ・・・
0327nobodyさん2016/08/23(火) 18:11:06.61ID:???
結局暴れるだけ暴れてID表示しないとこうなるとんだぞ！って自作自演して
板移動して優等生ぶってみたけど化けの皮が剥がれてこの有り様
0328nobodyさん2016/08/25(木) 16:23:53.31ID:???
化沿った
0329nobodyさん2016/08/25(木) 20:58:08.84ID:???
はりぼてのパンダじゃ、客は呼べないのさ。
誰も嘘や虚勢なんか求めてないからな。
知識のない馬鹿が市民権もてると思うことがそもそもの間違いだ。
0330nobodyさん2016/08/26(金) 01:01:58.37ID:???
きも
0331nobodyさん2016/08/26(金) 15:48:45.90ID:6NKaLduj
「ファイルがあったらインクルード」
という処理をするとき、file_exists()を使うべきか
@include("unko.php"); は行儀が悪いか

file_exists()を使用するメリット・デメリットは
パスが明確でインクルードパスを辿らせない？

あとはどこまで適当に済ましてよいか
ソースレビューないなら@includeでいっか
0332nobodyさん2016/08/26(金) 16:25:09.91ID:???
きも
0333nobodyさん2016/08/26(金) 17:10:56.60ID:???
>>329
何こいつ頭おかｃ
0334nobodyさん2016/08/26(金) 17:38:55.05ID:???
>>331
file_exists はディレクトリを見つけたときも真
0335nobodyさん2016/08/26(金) 18:11:24.75ID:???
初心者お断りとは一体何だったのか
0336nobodyさん2016/08/26(金) 19:34:58.65ID:???
ワッチョイがいやでいやで仕方なくてスレ立てたんでしょう。
推して知るべし
0337nobodyさん2016/08/27(土) 11:36:24.63ID:???
ワッチョイとかいってる池沼がきも
0338nobodyさん2016/08/27(土) 18:47:42.29ID:???
formで入力画面→送信画面と、$_POSTでsession_id()値渡ししてますが
session_destroy()やクッキー削除はCSRFなどに対して、以下それぞれで
した方が安全でしょうか？しないほうが無難でしょうか？

(1)ページ遷移時session違いで強制終了時。
(2)正常にメール送信完了時。
(3)メール送信でエラー時。
0339nobodyさん2016/08/27(土) 19:11:44.97ID:???
会員登録系？
1はまぁ放棄するのは妥当として
2は閉じてサヨウナラならそれでもいいけどブラウザ閉じたらきれるしあえてやる必要は感じない
正常に事が済んでるならセッション乗っ取ったところで何もできないし
トップに戻ってログイン済みセッションで何か続きやらせるようならだめだろう
3はクライアント側の入力ミスなんかで前の画面に戻してやる必要があるかもしれない
まぁユーザビリティ考慮しつつケースバイケースだな
0340nobodyさん2016/08/27(土) 20:03:44.76ID:???
>>339
詳しくありがとうございます。
ただの問い合わせフォームです。

補足ですが他にsession使う所はなく
このform入力画面でstartさせています。
エラーでない限り入力画面に戻ることもないと想定しています。

正常完了時はできれば他のページにアクセスしていただき
（関係ないかもしれませんが）google検索などを設置しています。

1の放棄とはdestroyなどするということでしょうか？
0341nobodyさん2016/08/28(日) 01:44:55.03ID:???
問い合わせが終わったらどっか行けってひどくね？ｗ
ていうか問い合わせフォームでセッション開始ってことは
会員制サイトでログインとか必要なわけじゃないんでしょう？
ただの問い合わせフォームでセッションなんて普通使わんよ
0342nobodyさん2016/08/28(日) 03:15:06.03ID:???
>>339
制度の悪いエスパーほどひどいものはないなぁ
0343nobodyさん2016/08/28(日) 11:18:22.05ID:???
サイトのＣＧＩコードをユーザーが読む方法ってないのですか？
0344nobodyさん2016/08/28(日) 15:11:38.82ID:???
>>343
あるよ。

header('Content-type: text/plain; charset=utf-8');
echo file_get_contents($path);

こんな感じでいいんじゃない？ｗ
0345nobodyさん2016/08/28(日) 17:09:51.26ID:???
phpsでぐぐれ
0346nobodyさん2016/08/28(日) 17:13:56.91ID:???
phpsでぐぐったけど普通すぎて有益な情報がぱっとは出て来なかった
とりあえずphpのコードをいつものphpではなくphpsっていう拡張子にしてそれにアクセスしてみれ
0347nobodyさん2016/08/29(月) 00:34:15.93ID:???
>>341
>問い合わせフォームでセッションなんて普通使わんよ

えっ
0348nobodyさん2016/08/29(月) 01:17:12.44ID:???
いやhiddenで十分だろ
0349nobodyさん2016/08/29(月) 15:13:29.84ID:???
個人情報管理が緩いとこならな
0350nobodyさん2016/08/29(月) 15:17:00.41ID:???
＞個人情報管理が緩いとこならな
問題点をまったく理解していない
0351nobodyさん2016/08/29(月) 17:00:19.62ID:???
>>347
複数ページに渡る大フォームでもなければ、セッションはいらんぞなもし。
0352nobodyさん2016/08/29(月) 17:53:51.04ID:???
またこの流れか・・・
0353nobodyさん2016/08/29(月) 22:10:38.13ID:???
>>341
どっか行けとは書いてないと思うが・・・
サイト内誘導はしてるでしょ
0354nobodyさん2016/08/29(月) 23:10:45.82ID:???
>>351
質問者です。入力画面の各チェックが訳あってjsのみなのですが
それでも仕掛けられる心配は全くないということでしょうか？
根本なところですみません。
0355nobodyさん2016/08/29(月) 23:27:30.61ID:???
php使えるのになんでjsのみなんだ？
送信されてきた時点でサーバでもチェックを行わないと
フォーム外からだってpostできるんだしjsをあてにしてはだめ
まあ別にその入力値チェックとかCSRFとは関係ないんだけど
0356nobodyさん2016/08/30(火) 00:09:57.94ID:???
クライアントサイドでの入力チェックはおまけでしかない
0357nobodyさん2016/08/30(火) 00:50:18.93ID:???
JSでチェックとかHTML5の制約で制限とかはサーバー負荷を減らすためのものなので、
製作者が楽するために使うと痛い目みるよ。

つい先日も、フォームの<select/>タグを完全に信じているせいで、
DBを完全に自由に操作できるクソシステム見たばかりだ。
「ああ、こいつら、本当に馬鹿だったんだ」と思った。
0358nobodyさん2016/08/30(火) 01:29:43.68ID:???
hiddenに入れたIDを完全に信じてるシステムとかの話見たの、このスレだったかな？
向こうだったかな？
0359nobodyさん2016/08/30(火) 01:49:31.40ID:???
唐突に意味不明なことを言い出すアスペ
0360nobodyさん2016/08/30(火) 03:14:01.35ID:???
> サーバー負荷を減らすためのもの
今となってはこれもまた十分な目的になってしまったなぁと、おっさんは思う
0361nobodyさん2016/08/30(火) 06:32:20.77ID:???
どうか真剣に聞いてほしい
秋、大変が起きる
本当なんだ、本当なんだ、本当なんだ
命の危険が迫っている
皆救われて欲しい
どうか皆頼む

http://hirohifumiyamato.blog.fc2.com/
0362nobodyさん2016/08/30(火) 10:49:05.84ID:???
>>357
> JSでチェックとかHTML5の制約で制限とかはサーバー負荷を減らすためのものなので、
> 製作者が楽するために使うと痛い目みるよ。
JSでチェックするからサーバではチェックしないという意味なら、痛い目見るよ。
0363nobodyさん2016/08/30(火) 11:43:14.15ID:???
>>362
ちょっとした入力ミスなどがあるままサーバに来るなよ
という意味じゃないの？
クライアントでやってるチェック以上のチェックを
サーバ側でも普通にやるっしょ
0364nobodyさん2016/08/30(火) 12:21:33.20ID:???
>>362
そう書いてあるじゃん。日本語読めないの？
0365nobodyさん2016/08/30(火) 13:48:55.67ID:???
またこの流れか・・・
0366nobodyさん2016/08/30(火) 15:04:31.45ID:???
お前アホなの？系のレスはもうやめて欲しい
0367nobodyさん2016/08/30(火) 15:24:42.28ID:???
初心者の超基本的な質問にドヤレスするか、他人を罵倒するレスをするためのスレ。
0368nobodyさん2016/08/30(火) 17:13:54.73ID:???
「ゴミクズ」って書いてる奴がいなくなればかなりましになるはず
0369nobodyさん2016/08/30(火) 17:38:42.21ID:???
見るのが嫌ならこのスレに来なくてええんやで
0370nobodyさん2016/08/30(火) 17:40:27.40ID:???
ワッチョイ野郎が癌
さっさと向こうへお帰りいただいてえんやで
0371nobodyさん2016/08/30(火) 20:54:10.63ID:???
>>357
入力画面でのjs使用は各要素を簡単に多彩に操作できて
入力するごとにリアルタイムでメッセージ出せたりできるからです。
（PHPでもできるのかもしれませんが私がそっちの方が詳しくて楽なので）

かつ最終画面のサーバ側でもPHPでチェックします。

ｊｓは無効にされて簡単に成りすまされるからと
PHPと、受け渡しは厳重にと、他スレで忠告されまして。
0372nobodyさん2016/08/30(火) 21:11:53.45ID:???
＞ｊｓは無効にされて簡単に成りすまされるからと
ちょっと何を言ってるかわからないですね。
＝で結ぶものじゃないでしょうに。
0373nobodyさん2016/08/30(火) 21:14:18.97ID:???
>>358
そもそもhiddenでも信用できないと聞いてsessionに至ったのですが間違ってますか？

>>363
>ちょっとした入力ミスなどがあるままサーバに来るなよ

楽もありますがそれもあります。メール送信直前でも最終チェックしてます。

あるサンプルが、入力画面jsと確認画面phpとで同じチェックをしてて疑問に思い
調べていくうちに今に至ってます。
0374nobodyさん2016/08/30(火) 22:25:08.33ID:???
>入力画面の各チェックが訳あってjsのみなのですが
これ間違いでPHPでも同じチェックしてるんだよね？
同じチェックしてる疑問はもう解決してるんだよね？(上の方で答え出てるけど)

>そもそもhiddenでも信用できないと聞いてsessionに至ったのですが
hiddenは信用できないはあってるけど、POSTで渡してるなら外部から渡せるからそれだけじゃだいたい一緒
0375nobodyさん2016/08/30(火) 22:29:28.83ID:???
問い合わせフォームってただクライアントが入力した内容を確認画面に渡すだけだろ
hiddenは危険って記事をipaが出してるばかりにとりあえずhiddenは使っちゃだめと誤解してるやつがいるが
そんなただやばいものならhiddenなんて仕組みがあるわけないだろ
危険かどうかは内容によるって話だ
今回の件は完全に杞憂
0376nobodyさん2016/08/30(火) 22:44:14.60ID:???
いやhiddenには渡さん
フォームに渡すけど
hiddenなんて問い合わせフォームじゃ使わないってのが正解
セッションもいらない
0377nobodyさん2016/08/30(火) 22:48:36.85ID:???
そのへんは好みかもしれないが
確認画面で編集可能にするのか？readonlyとかもできるけど
0378nobodyさん2016/08/30(火) 22:56:07.71ID:???
他人のメールアドレスを有効と認識してしまう問い合わせフォームで
信用云々ってのがそもそもナンセンスなんだが
下らないとこで躓くより自動返信に心当たりのない方はメールを無視して下さいの文言追加しとけな
0379nobodyさん2016/08/31(水) 01:58:35.77ID:???
単なる問い合わせフォームなんだろ？
間違ったメールアドレスを、書いた奴が悪いだけ

仮に、他人のメアドを書いても、それを君は判別できるのか？
0380nobodyさん2016/08/31(水) 03:55:45.55ID:???
3行目みて判別できると思ったのなら洞察力が足りない
0381nobodyさん2016/08/31(水) 12:57:45.83ID:???
>>375
そんなこと誰も言ってないので話ややこしくしないように
0382nobodyさん2016/08/31(水) 12:58:50.24ID:???
>>379
scriptとかあるだろ
0383nobodyさん2016/08/31(水) 13:12:46.20ID:???
問い合わせフォームでセッションは不要
0384nobodyさん2016/08/31(水) 13:29:10.25ID:???
問い合わせページからのみ問い合わせを受け付けたい場合は、次のようにやればいい。

問い合わせページ：
* session_start()
* 何らかのロジックでトークンを生成
　　$token = hash('sha256', session_id());
　　 => FORMにhiddenで埋め込む

POSTを受け取るページ：
* session_start()
* $token = hash('sha256', session_id())
* $_POST['token']と$tokenを比較
0385nobodyさん2016/08/31(水) 14:15:47.29ID:???
#大前提
・PHP側でもちゃんとチェックしような。値改変だけじゃなくscriptもあるぞ

#hiddenうんぬん
・CSRFが気になるなら384
・簡単な問い合わせだしCSRFが気にならないなら、何もしなくていい

これでだいたい皆意見あってるんじゃない
■ このスレッドは過去ログ倉庫に格納されています