>>342
これだけでいい。
危険おじ「jsonは危険」
疑問おじ「どう危険なの？」
危険おじ「…」
危険おじ「jsonは危険」
疑問おじ「日本語わかる？」

J危おじはjson使わないなら何使ってるんだろう

SIP2プロトコルでも使ってるんじゃないかｗｗ

>>352
素人にはわからないかもしれないが、サーバ側で不特定の相手からjson形式でデータを受けるときは、セキュリティ上考慮すべきことが増えるんだよ。

まあLaravelでjson使おうとするやつはlaravelについて勉強しなおしたほうがいいと思う
これがsymfonyでjsonだったらわかるんだけど

>>355
まさか今どきJSONくんもだけどどうして理由を添えて書けないかなぁ

>>355
マジ？
俺はどこから勉強しなおしたほうがいいですか？
教えてください師匠

>>357
脆弱性とは何か、セキュリティの基本から

でもLaravelってsymfonyのラッパーみたいなもんだよね
内部的にはsymfony関連クラスのサブクラスみたいな感じで
作られているわけだし

>>358
でも「Laravelについて」、って言ってましたよね？
え、ってことはLaravelの脆弱性って今何か報告されてるんですか？
セキュリティサポートが続いている 7.x、6.x、5.5.x で何かありましたっけ？
issue探してみたんですが、JSON関連は特にありませんでした！

>>360
そいつもはや荒らしだから触らないほうがいいぞ

>>361
おっさんを邪険に扱わないでよ！

確かにLaravelでjsonを扱うのは結構難しいよね　考慮することが多い気がする
その点symfonyだと考慮するべきことのほとんどがフレームワーク側でチェックが入るので安心して使える
ただ細かい制御をしたいんだったらLaravel一択

フロントエンドからのリクエストに対してJson形式でレスポンスで返すバックエンドを仕事で構築したことがあるけど
laravel制アプリは脆弱性のテストツールで唯一jsonハイジャック対策が不合格になったのに対してsymfony制アプリはすべて合格だった
まあlaravel制アプリも結局設定変更レベルで合格になったけどsymfonyは確かにデフォルト設定のセキュリティレベルがlaravelより高いような感じ

>>364
> Json形式でレスポンスで返すバックエンド

あれ、結局サーバー→クライアントの通信の話なの？
ユーザー入力をサーバーサイドでパースするのが問題だっていう設定どこに消えたのw

>>364
> jsonハイジャック

急にクライアントの話になってて草
それとも>>364が作ったアプリではphpからjavascriptを動かしていたのだろうか

>>364
laravelとsymfonyで全く同じアプリ作ったの？
同じアプリ作る意味が分からんけど、フレームワークが異なれば実装も異なるんじゃないの？
実装が異なるのにフレームワークの責務と言い切れるの？
すっごくシンプルなアプリならともかく、php製のjavascriptクライアント作っちゃうくらいだからやっぱりフレームワーク関係ないのでは？

しかもツールによる診断項目ってポートスキャンとかに限られてるだろうし、せいぜいインフラ構成くらいしか診断できないでしょ。

ここまでほぼエビデンスなし。

>>363
考慮することって何だよ

JSON危険おじさん、嘘を見破られてまたまた論破されてしまう。

>>365
すまん俺はその人ではない

>>366
phpのv8js使って色々やってます

>>367
自分の所は毎回laravelとsymfonyの２種類で同じアプリを作成し、その時点で
一番脆弱性が少ないフレームワークを本番環境にリリースする形です
まあ会社の方針ではなく顧客の入札仕様に入っているのでしょうがないんです（；ω；）
チェックツールについてはポートスキャンだけじゃなく画面で自動入力したり不正なリクエスト送ったりする
テストツールがあるんでそれ使ってました富士通製とNTTデータ製の２ツールで毎回テストやってます

v8jsってなんだよｗｗｗって思ったらマジであるのかｗ

ここまでの結論としてはjsonに脆弱性はないけどcsvにはあるということでＯＫ？

v8ってChrome系のjsの事だろ

phpの拡張としてあるみたいですね
http://www.php.net/manual/ja/book.v8js.php

正直jsonよりもxmlのほうが扱いやすいと思ってるの俺だけ？

>>373
脆弱性を一番産みやすいのは人間だから、
だめな人間はプログラムするなという結論だな。

ブラウザアプリに限った話だけど、
SPA作る場合って、特殊な事情を除けばサーバーへのリクエストはほぼ Content-Type: application/json 一択になる。
SPAの時点でクライアントがjavascript一択なのでjsonが一番ラクというのは非職業エンジニア（少しだけコードを書く素人）でも分かるだろう。

それで、一昔前の非SPAでよくあったHTMLフォームから直接サーバーへのPOSTリクエストを行う場合、Content-Type は自動的に application/x-www-form-urlencode または multipart/form-data になる。自動的に設定されるのでそれ以外の選択肢は無いし、そもそも Content-type を意識することすら無いだろう。
（代表的なアプリでいうとWordPressだろうか）

もしかしてJSON危険説を提唱する彼（ら）は非SPAを作ることだけを想定して「jsonはありえない」と否定していたのだろうか。

しかしそうすると「まさかいまどきJSONでやり取りしてるの？」というレスにひっかかる。
どちらかと言えば非SPAアプリのほうが前時代的なので「いまどき」という枕詞が付くのはむしろ x-www-form-urlencode のほうではないだろうか。

すまんもっとわかりやすく書いてくれ

いつからcontents typeの話が出てきたんだ？クライアント→サーバでjsonがどうこうの話じゃないんだっけ？

>>380
「クライアント→サーバーでjsonがどうこう」ってのが曖昧な表現で、正確に書くとcontent-typeを何を指定する？って話になるよ。

要約してやるよ
jsonおじさんは名前がジェイソンだから危険って言ってるんだよ

ずっと静観してたけど、ひとつだけ。
俺はおっさんじゃなくおばさんだよ。失礼な！

>>382
13日の金曜日は危険だからジェイソンに気を付けろって話だろ

外注選定でここ数年Laravelばかりやってる奴はまずNGにする。
Laravelでしか物を作れないから。

Laravelでしか物を作れないってどういうこと？

>>385
throttleエラーも直せなかったおじさんまだ生きてたの？
>>56と>>58への返信早く書いてよ。

>>385
めちゃわかる symfonyやってる人ってLaravelやCodeigniterとかもいけるけど
Laravelやってる人って他のフレームワークは使えないこと多い

このフレームワークは比較するならsymfonyじゃね？
Eloquentとか言うORMまがいの機能持った最強フレームワークが中身がスカスカなORM機能に
無意味に好かれまくってグダグダな機能を実装するご都合主義のフレームワークだし
DB要素あり認証要素もふんだんに盛り込み何でPHPフレームワーク界で人気なのか笑いの種になるその出来の悪さと
色々と重なり合う点が多いと思うけどｗ

今度はSpringおじさんか
外注選定するときにフレームワークも指定しろよ
phpならLaravelのシェアがトップなんだから指定しなきゃLaravel製になることくらい想像できるだろ

>>390
だからLaravelばっかりやってるやつは除外していると言ってるだろ

>>391
このスレの人たち技術レベル低いからあまり相手にしないほうがいいですよ

すまん誰か>>389について解説してくれ
さっきから何度も読み直しているが理解できない

ベトナムに開発を任せると、漏れなくLaravelで作るのでつらい。
保守段階になってLaravelのソースなんぞ見たくない。

そこまでLaravelを嫌う理由ってなんだ
具体的にどこのどういう部分がダメでどういう形だったらいいと思ってるのよ

>>394
なんでLaravel嫌いなの？理由は？

やっぱり外注にLaravel頼んでるじゃん
↓
33 nobodyさん sage 2020/01/24(金) 13:35:52.65 ID:???
>>32

結局、429出なくなった。
file_get_contentsしていた箇所をcurlに置き換えただけで。
しかし、Laravelには関わりたくねーな。
ベトナム辺りに流すとLaravel使いたがるので困る。

>>385
なんでわざわざLaravelスレに来たの？

親にlaravelを殺されたんじゃないかと思うくらいの執着心

>>396
スレを遡って読んでみた限りだと、ThrotlleRequestsクラスが出すエラー（時間内最大リクエスト数の制限）の直し方が分からなかったのがトラウマらしい。