トップページ⇒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の改造
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が気にならないなら、何もしなくていい

これでだいたい皆意見あってるんじゃない
0386nobodyさん2016/08/31(水) 14:18:53.65ID:???
あ、scriptはBOTからの送信ってことかな。失礼。

でもあれってほとんどは正規にアクセスして送ってない？
CSRF対策とは違う気がするんだけど
0387nobodyさん2016/08/31(水) 16:33:49.33ID:???
CSRF対策（セッション管理が必要）は、リクエストを受け付けたら、
個人情報が表示される、決済が完了する、核が発射される
とか重要なことを決定させるような場面で
なりすました第三者がその決定をできてしまうと困るからやるわけで、
たいして重要でもなければ、成りすまし放題の問い合わせフォームでやるのはあまり意味がない。
自サイトに対する、いたずら（攻撃）サイトを作らせないという意味合いはちょっとあるが、
攻撃者の知識次第でワンタイムトークンを適切に処理するロジック（≒BOT）が組めるわけで、
ハッカー気取りの知恵遅れ以外には効果がない。
反外国企業・サイトならともかく、。そもそもそんなことする物好きもいないだろう。
0388nobodyさん2016/08/31(水) 17:18:02.00ID:???
というか、認証がないシステムで>>384みたいなことをするのは、ほぼ無意味。
認証OKになって初めてセッションを作成するから意味がある。
0389nobodyさん2016/08/31(水) 17:30:25.71ID:???
まあそうだわな
GET contact.phpでセッションが開始されて、正しいtokenを取得できるんじゃ意味ないわ
0390nobodyさん2016/08/31(水) 18:21:45.33ID:???
笑える
0391nobodyさん2016/08/31(水) 19:22:07.89ID:???
>>387
問い合わせを送信すると、確認として入力メッセージが入力メールアドレスに対して自動送信される仕組みだったらとても便利そうだよね
0392nobodyさん2016/08/31(水) 19:35:30.08ID:???
それ普通の問い合わせフォームじゃ
入力者のIPとかも付いてきたりするけどあれは意味がわからん
成りすまし問い合わせで多くメールがきて同一IPだったら
こっちは面倒で関与しないからIP情報渡しとくからそっちで警察に相談してね
みたいな無言の圧力でもかけてるんだろうか
0393nobodyさん2016/08/31(水) 22:34:25.58ID:???
>>384のはさ、CSRF対策じゃなくて、通常は送信後のリロード対策でやるんだよ。

てか、こっちは初心者お断りじゃなかったのか？
向こうの質問のほうがレベル高かったりする気がする。
0394nobodyさん2016/08/31(水) 22:46:37.22ID:???
>>384のはさ、CSRF対策じゃなくて、通常は送信後のリロード対策で「やってるんだよ」。

に訂正しとくね。
>>388の言うように、認証システムの場合は>>384の処理の意味合いが変わってくるからね。

そういう意味では、セッション使っとけば、どっちにも転べるのでお手軽ではあるけど、
非認証のお問い合わせフォームなら別のリロード対策のほうがさらに楽だったりするから、
いちいちセッションなんか使う必要ないね。
0395nobodyさん2016/08/31(水) 22:47:51.44ID:???
＞通常は送信後のリロード対策でやるんだよ。
お前の中ではそうなんだろう
レベル低いからお前はこっちのほうがお似合いだな
0396nobodyさん2016/08/31(水) 22:56:54.64ID:???
>>384ってこれでいいの？
hashはsession_idを元にするのではなく乱数で行う
それを$_SESSIONに格納し次のページでhiddenで送られてきたのと比較する
でしょ？
0397nobodyさん2016/08/31(水) 23:09:48.07ID:???
「こっち」　「あっち」　「ワッチョイ」　「IDありなし」
これに拘ってるのがこっちの板を荒らして潰した張本人な
0398nobodyさん2016/09/01(木) 00:25:53.26ID:???
>>396
hiddenで送ったら意味ない
それはそれでやってるんだって

話の元がsessionだからそうしてるだけでしょ（たぶん）
塩かけてからのほうがいいが論点今そこじゃないから
0399nobodyさん2016/09/01(木) 00:29:34.61ID:???
>>398
何に塩かけるかって話なのに、塩かけてからの方がいいってどういうこっちゃ
0400nobodyさん2016/09/01(木) 00:31:41.42ID:???
なんでhiddenで送ったら意味ないの？
サーバの$_SESSIONが改ざんできるわけじゃないのに？
0401nobodyさん2016/09/01(木) 00:47:25.92ID:???
>>384-385で見てたけど>>384はCSRFの話をしてるわけじゃないってことね
0402nobodyさん2016/09/01(木) 06:47:35.91ID:???
やるなら中途半端なコードでなくCSRF対策を兼ねてやるべきだし、
hidden意味ないも意味がわからない。
0403nobodyさん2016/09/01(木) 10:30:14.42ID:???
>>396
> hashはsession_idを元にするのではなく乱数で行う
それでもいいけど、そうやったって何かが改善されるわけではない。
0404nobodyさん2016/09/01(木) 13:11:08.43ID:???
セッションID漏れたら意味がないってのが改善されてんじゃねえか
0405nobodyさん2016/09/01(木) 13:18:56.59ID:???
>>404
基本がわかってなさ過ぎて論外
0406nobodyさん2016/09/01(木) 14:05:18.88ID:???
正しい実装をしてれば問題ないと言いたいだけだろ
そんな当たり前のことを言ってどうする
0407nobodyさん2016/09/01(木) 14:11:30.67ID:???
>>406
何言ってるのかわからん
「意味がない」とは何の意味がなくて、
「問題」とは一体何だ？
0408nobodyさん2016/09/01(木) 14:18:24.12ID:???
httpsを利用して正しい設定をし
セッション発行はログイン後に（再度）行い
セッションを漏らさない実装をするということだ
0409nobodyさん2016/09/01(木) 14:30:29.41ID:???
いや問題点はそこじゃねーよ
推測しやすいから問題なわけで
0410nobodyさん2016/09/01(木) 14:32:18.61ID:???
ちなみにセッションIDは十分推測しにくい
>>384の無駄な点としてはハッシュ関数に通す点だろ
0411nobodyさん2016/09/01(木) 14:34:26.81ID:???
初心者お断りスレじゃないのかよ
■ このスレッドは過去ログ倉庫に格納されています