【PHP】Laravel【フレームワーク】 Part.3 ->画像>6枚

テンプレ追加修正お願いします

Laravel
ウェブ職人のためのPHPフレームワーク

本家
https://laravel.com/

git
https://github.com/laravel

動画チュートリアル(英語)
https://laracasts.com/

日本語
http://laravel.jp/

書籍
Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク

Laravelエキスパート養成読本[モダンな開発を実現するPHPフレームワーク！] (Software Design plus)

※前スレ
【PHP】Laravel【フレームワーク】
http://2chb.net/r/php/1503683914/
【PHP】Laravel【フレームワーク】 Part.2
http://2chb.net/r/php/1556417229/

amazonへのリンクが邪魔をしてスレッドを建てられなかったので外しました。

amaz,on(カンマ抜き)がNGワードらしいな、補足
※アマゾンURLは@をaへ置換

Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク
https://www.am@zon.co.jp/dp/4844339451

Laravelエキスパート養成読本[モダンな開発を実現するPHPフレームワーク！] (Software Design plus)
https://www.am@zon.co.jp/dp/4774173134
書籍、今はこれらが良いと思う

PHPフレームワーク Laravel Webアプリケーション開発 バージョン5.5 LTS対応
https://www.am@zon.co.jp/dp/4802611846

Laravel: Up & Running: A Framework for Building Modern PHP Apps - Second Edition
https://www.am@zon.co.jp/dp/1492041211
※英語
※Laravel 5.8までカバー

補完情報

5.5から5.6.0へのアップグレード & 5.6から5.6.30へのアップグレード
https://readouble.com/laravel/5.6/ja/upgrade.html
5.6から5.7.0へのアップグレード
https://readouble.com/laravel/5.7/ja/upgrade.html
5.7から5.8.0へのアップグレード
https://readouble.com/laravel/5.8/ja/upgrade.html
5.8から6.0へのアップグレード
https://readouble.com/laravel/6.x/ja/upgrade.html

あちゃー、@より,とかの方が良かったか、Chromeで開いた時に@から前が消えるのが手間だ

上の二つの本はもう古すぎるから別のに買えた方が良いね
新しいのも出ているし

アーチサン無しでDBテーブル作るにはどうすれば良い。

アーチサン使えよ

素直にcreate tableすりゃええやん

あーちね

レイアウト部分を共通化しようと思って@includeしてるんだけど
読み込んだファイルの@section~@endsection部分が
表示されないんだけど、何で？？？

使い方間違ってるからだろ
なんでそんな質問が沸くのか逆に聞きたい

>>9
マニュアル読んだ？

詳しい人教えてほしい。
view composerでサイドバーに表示する情報を一括でデータベースから取得してviewに渡してるんだけど、
例えばおんなじ情報を一部のコントローラーの処理でも使いたい時がある。
このときってサイドバー用にDBたたく処理と、コントローラー用にDBたたく処理が2つになって冗長になってしまうはずだけど、
どうやって対処すればいいんだろう？
そもそもview composerの使いどころを間違っているのか…？

>>12
モデルにおけばいいじゃん

むしろモデルで処理しない理由を聞きたい

>>13
>>14
せっかく教えてもらってもよくわからん。モデルてEloquentのことよな。
もうすこし詳しく教えてくれないか
Eloquentにそういう処理を書いても何度もその処理を呼ぶならその都度DBアクセスが発生するんじゃ？

1. モデルに目的の処理を書いたメソッドを定義する
2. コントローラーからもview composerからもどこからでもそのメソッドを呼べば良いだけ
これでコードの重複は無くなるから冗長では無い
って思ったけどクエリの発行も一回にまとめたいってことか
1. Cacheを使う
例えばそのメソッド内で、サイドバーに表示する内容がキャッシュに存在していればキャッシュから取得、存在していなければDBから取得してキャッシュにも保存。
2. モデルの静的メンバに保存
考え方は1とほとんど同じだけど、cacheではなくモデルの静的メンバ変数に保存する。

例えばHogeモデルの場合

class Hoge
{
public static $menu = null;

public static function getMenu() {
if (!self::$menu) {
echo "initialize\n";
self::$menu = "side menu here\n";
}
return self::$menu;
}
}

echo Hoge::getMenu();
echo Hoge::getMenu();

出力結果：
initialize
side menu here
side menu here

>>16
>>17
冗長って言い方が悪かったんだな。補ってくれた通り、クエリ発行数を減らしたかった。
サンプルコードまでありがとう。こんなやり方があるのか。メンバ変数もつみたいな感じか
laravelしてるといつの間にインスタンス化したのかわからんし、ここらへんの知識を押さえないとなー

>>18
laravel以前にphpの言語仕様を理解していないだけでは？

HTTPステータス429に悩まされている。
LaravelのAPI回数規制で429を返すらしいのだが、そのパラメータを緩和しても429だ。

>>20
緩和してもまだリクエスト数が上回っているのではなく？
ログ取るとかしてリクエスト数調べて見れば？

>>19
phpの言語仕様のどの部分の話よ

blade分かりにくすぎない？
親ファイル基準で考えればいいのか子ファイル基準で考えればいいのかイマイチ分からないんだけど

日本語化が出来ない...
公式からjaフォルダー事持ってきたのに何故かenの方のエラーメッセージが表示される

>>24
これちゃんと読んだか？
https://readouble.com/laravel/6.x/ja/localization.html

>>25
読んだけど理解できてないのかな
これhttps://github.com/investigator1092/Development

>>26
どうおかしいんだ？


You should fill the name field. は
ContactRequestで指定しているから違うよな

この画面で正しいのか知らんけど、artisanでviewとconfigのキャッシュクリアしてみたら？

>>27
✕ 指定しているから違うよな
○ 指定しているから意図したメッセージだよな

>>28
,27
,25
すまんphp artisan config:clearをしたら表示された！！

cacheはクリアーしてたけど違うのもクリアしないといけないんだな...
不慣れだから手こずったわ
thanks

ドンマイ

>>21

kernel.phpのデフォルト 'throttle:60,1', （1分間60リクエスト）を
9999にしても429エラーが出るのだ。
Laravel関係なくて、nginxが出してんのかね。

いやさすがにLaravelが出してるのかnginxが出してるのかくらい分かるだろ、てか分かれよｗ

ちなみにthrottleが有効だとレスポンスヘッダに
x-ratelimit-limit, x-ratelimit-remaining, x-ratelimit-reset を出してくれるからそこ見たらなにか分かるかもね。

あとLaravelがエラー吐く時はapp/Exceptions/Hander の render() メソッド通るからそこで例外だしたりログとってみれば？

>>32

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

いやー俺もSpringBoot軽く齧ってlaravelに逃げてきたけどマジで分かりやすい
一々フォームの検証でエラーがあった時に元のページにリターンするアトリビュートを指定したりしなくていいとか便利

>>33
何なら良いんだ？

>>33
いや、apiにfile_get_contentsは無いだろw
つうかfile_get_contentsだとまだ429が出るってことかよw

>>36

出る。
curlでkeep aliveしてるって訳でもないので、Laravelのthrottleは関係ねえな。

それもうlaravelすら関係ないだろ

>>33
じゃあcakeがいい？そんなの使うの老害くらいでしょ

>>31
laravelがエラー出してるのかそうでないのかなんてログ取れば一瞬で分かるだろうに…
その程度の頭でlaravelとは関わりたくないと。
こういう人がオレオレフレームワークとか書いたりしてるのかな。

>>40
自己紹介お疲れ様です＾＾；

外注選定でここ数年Laravelばかりやってる奴はまずNGにする。
Laravelでしか物を作れないから。
とか書くと「俺は違う」という奴が出てくるが、とにかく問答無用でNG。

ふーん

なんでLaravelあかんのん？

簡単すぎるからでは？昔っから初心者はRailsから入るなCをやれみたいな原理主義者は居たし

それ言ったらフレームワーク全般に言えない？
laravelであることを特定できない

>>44
Laravelでしか物を作れないって言っただろ？
こういう外注はLaravelをやりこんでいるので他の技術がおろそかになっている
例えば組み込みのファームウェア製作とかできないだろ？

やっぱCじゃん

なんだただの老害か

phpじゃなくてjavaで作れってこと？

>>50
javaも駄目
こういう外注はどうせSpring Bootばっかりやっていて
いざSpring Framework案件になったら全く何もできなくなる
今までこいつらができていたのは開発者が設定すべき内容を
Spring Bootが自動でやってくれていたからに過ぎない

じゃSpring bootでやればよくね？

SpringBootとSpringって似て非なるものじゃないっけ？

SpringBootで思い出したけど
LaravelBootって開発中止しちゃったのかな
SpringBootと同じような感じでコーディングできるLaravelを作るって
意気込んでいたけど

とりあえずこういう人とは一緒に働きたくないてのはわかる
外注さんにも選ぶ権利はある

LaravelやSpringBootは駄目でSpringは良いの？
自動でやってくれるってのは駄目ってのを突き詰めていくと、
apacheやnginxを使わないでサーバーソフトウェアは自作しろとはならないのかな？
CentOS使わないで自作しろとか、高級言語使わないでアセンブラで作れとはならないのかな？

Laravel信者ホイホイか、ここは。
まぁ、どこぞのエージェント経由の面談で「Laravelなら任せてください！」と張り切ると
逆効果な場合もあるってことだ。

あほなの？
なんで組み込み任せるやつ探すのに、webのフルスタックエンジニア紹介させるんだよｗ
組み込みやってるやつ紹介するように依頼しろ。

で、そんなやつはスレチだわ。

職人は意識高い系嫌いだろうけどどっちもプライドはクソほど高いよね

今、掌田本の実践開発編読んでるけど意外と知らない事も多いな

>>60
例えば？

ストレージ関係の細かい事やらサービスとファザードの事やらイベント、スケジューラーやら
あとDBまわりだとついついrawで書いちゃうところを実はもっとちゃんとした書き方あったのかっていうのとか

知らなくても代替でどうにかなるような事だけどこれ使った方がスマートなつくりにできるんだろうなって感じ
まぁ公式ドキュメント全部読めば済む話ではあるんだけど使う機能の部分しかちゃんと読んでなかったんだよね

現状PHPはLaravel使うかSymfony使うの２択だな
CodeIgniterはいいのかね？

Laravelって部分的にSymfonyが使われてるとかよく言われてるけどSymfonyを知っておいた方がLaravelの深い部分を知る上で有利な事って何かある？

ないね

>>63
CodeIgniterはMVC的に管理はしたいけど、学習コストかけたくないって時期に便利に使ってた。
ほとんど素のphpで動くんで、学習は楽だったけど、いまさら使おうとは思わんかなぁ。
4が開発中みたいだけど、どうなんだろ。

Laravelを勉強するにあたって2020年現在一番おすすめの
チュートリアルってありますか？

>>67
Railsチュートリアル

🙄

Laravel界隈殺伐としてんな

Laravel界隈っていうかここだけだと思うけどね

でもPHPフレームワークはLaravelが最強だよ

PHP7.4で爆速になるとかほんとなん？

古いマイグレーションファイルって消していいの？まだよく分かってないんだけどphp artisan magrateしたら最深のマイグレーションファイルが実行されるの？

最新

>>74
いや消さないだろ
用途考えろよ

消しちゃいかん
なんのためにup()とは別にdown()があるのか考えよう

え？みんな消さないのか？

君のように趣味で一人でやってる分には消していいかもね。
普通は消さないけど。

マニュアルにも書いてあるから、疑問に思うならまずマニュアルを読んだほうがいいと思うよ。

https://readouble.com/laravel/6.x/ja/migrations.html

> マイグレーションとはデータベースのバージョンコントロールのような機能です。アプリケーションデータベースのスキーマの更新をチームで共有できるようにしてくれます。

> もしあなたが今まで、チームメイトに彼らのローカルデータベーススキーマに手作業でカラムを追加するよう依頼したことがあるなら、データベースマイグレーションは、そうした問題を解決してくれます。

やるとしたら枯れたとこまでをリファクタリング目的で整理するくらいだな
ただまあスキーマ確認ならDBをプロットする方が確実だし普通は放置

マイグレーション機能をなくすなくさないで頻繁に
Laravelコミッターが議論してるし将来的にはなくなるかもね

俺もマイグレーションファイル消す派だったけどお前ら残してるの？

リポジトリに残してあるなら消してもいいけど
環境再構築とかするときにないと困ることもあるかと思うぞ

マイグレーションファイルを消してる人は環境の再構築や共有をどうやってるの？

カラムぐらい自分で作れ。
フレームワークごときにDBを支配させるな。

>>86
定義書見ながら環境構築用のクエリを自分で書けって意味？

コードの履歴とDBの履歴は一致させておきたい
別々に管理するとDB変更のデプロイ漏れ多いんだよ

いきなりリソースコントローラーでstoreしてredirectで同じクラス内のindexメソッドに移行してview表示すると404になるようになった
デバッグ環境構築してやってみるとuncaughtなfatal errorで流れ掴めん
controllerがMyResourceCntrollerのextends Controllerされてる行で見つからないと表示される
どうすればいいですか

うわごめんredirectで違うアクションメソッドに行けると思ってたw
解決です

アクションメソッドからアクションメソッドにwith()で指定出来るようなセッションを持たせて推移させるにはどうすればいい？
出来ない？
storeからindexに移らせたいんだけど
web.phpに書かないといけないのかね
そもそも再利用性と過疎結合の丁度いい塩梅が分からない

何言ってるか分からん

>>92
コントローラーからコントローラーにセッションを持って移行したい場合一々web.php通らないといけないの？

>>91
めっちゃ頭悪そう
まずアクションメソッドって何だよ、コントローラーアクションだろ。
storeとかindexってなんだよ、コントローラーのメソッドAとメソッドBだろ。
web.phpってなんだよ、ルーティング定義ファイルだろ。

つーか設計がおかしいんじゃ？って点に触れなければ、普通にそのstoreメソッドのしかるべきタイミングで$this->index()でメソッド呼べばいいんじゃないか？

Sessionファサード使えばコントローラー云々とかルーター云々とか一切気にする必要ないけど

>>94
煽り抜きで聞くがアスペか？

>>95
これだわ
flash関数を使えば良いんだな
助かる

ファサード全否定してるけどファサードって駄目なの？

https://www.slideshare.net/mobile/KenjiroKubota/laravelfacade

Facade警察の話はもう語り尽くされただろ
使い方次第で良薬にも劇薬にもなる

過去スレ見とくわ

まぁ寧ろbladeが要らん気もするけどね
表示部は全部フロントフレームワークでいい気がする

俺も最近はもうblade使わなくなったな

俺もLaravelはapiサーバにしておいて
描画はVueだな

Laradockでプロジェクト作りたいんだけどgit cloneでLaradockを持ってくるパターンとLaravel学習帳のようにgit submoduleで持ってくるパターンがある
gitについては基本的なことしか分かってなくてどっちがいいのか分からない

スレチだが教えてあげると
まず、「git clone とは何か」「git submoduleとは何か」を理解することから始めろ
この話においてLaradockは関係ない

Laravel Framework 6.16.0 です。
class SampleController extends Controller
{
protected $componentService;
public function __construct(ComponentService $componentService)
{
$this->componentService = $componentService;
}

と書いただけで、ComponentService がインジェクションされてます。
サービスプロバイダを作成したり、app.phpに登録とかしなくても、です。
デフォルトでコンストラクタインジェクションされるんですか？
サービスプロバイダの意味がいまいち分からなくなってます。

そもそもComponentServiceクラスって何よ？

>>106
コントローラーの引数で依存注入する機能は「サービスコンテナ」と言って「サービスプロバイダ」とは関係ない。
サービスコンテナはコントローラーをインスタンス化するときに注入したいクラスをインスタンス化する仕組みのこと。大体はモデルルートバインディングのためにEloquentが呼ばれる。
ちなみにそのコードの __construct はこう書くのと結果は同じ。
__construct()
{
$this->componentService = new ComponentService();
}
対してサービスプロバイダはアプリケーション全体で起動されるクラス群のことを言う。
ちなみにサービスプロバイダは必ずlluminate/Support/ServiceProviderを継承してconfig/app.phpのproviderに登録する。
気になるならマニュアル読むかソース辿ってみれば分かるよ。

>>108
どうもありがとうございます。理解度5割ってとこですが、
__construct の説明は助かりました。

>>103
見映えというか、好みの問題ですね。

もうバージョン７か

でもハーメルの悲劇呪いだよ？

Laravelのおすすめチュートリアル晒せ

MVCとオブジェクト指向の基本さえ理解してたら都度マニュアル読むだけで十分な気がする
逆にまだそっちを理解していないなら先にそっちのチュートリアルをしたほうがいいと思う

例えばredirect()がいちいち何を返すとか把握しとかないといけないもんなの？

>>115
必要になったら把握するで十分だよ

>>116
面接でポートフォリオ提出してここ何リターンしてるか分かる？って言われて分からなかったからそれじゃコピペと同じだと言われた

あとソースコードがフレームワークのルール完全に無視しているとも言われた

Laravelを使うという仕様だったのになぜLumenを使用したのかとも聞かれた

>>118こいつは>>117じゃない

ソースコードのルールは完全に守ってた

因みにその会社ではSymfonyを使っていた
だからSymfonyとLaravelでは向き合い方が違う可能性も考えた

Symfony使う会社なのになんでLaravelで提出したの？

>>122
素人だから

(´^台台^`)・・・・・・

Lumenって事はREST特化だから redirect() はURLミスで404用json返す時くらいかな
異常系も例外投げてHandlerでjson構築して返すし
Viewあるならリクエスト成功後にTopやログイン後のユーザページに飛ばすとかあるけども
Lumenで正常系に redirect() 使用してると違和感を覚えるかも

いやLumenなんて使ってないよ
それ偽レスだよ
成り済ましをやる様な腐った人間がプログラマーには多いよな
たらこみたいなナルシストが多過ぎて自分は何をやっても許されるんだと思ってる目が細いのが多い

ごめん>>126だけどちょっとイラッとしてしまったすまない

Symfonyの会社でLaravelで提出したのも偽レス？

>>128
いやそれは本当
未経験採用枠

とりあえず質問者はsage消してID出したらどうだ？

うんちぶりぶり

俺ララベルマスターだからなんでも聞いてくれよな！

有識者の皆様方、下のGitHubのプロジェクトをLinuxでまともに動くように手伝ってくれ。
2人くらいで実装がんばってるようだが、俺も同じ部分で躓く…

OSS Calendar
https://github.com/thinkingreed-inc/oss-calendar

土日ちょっと見てみるか

これgoogleカレンダーとどう差別化するんだ？

laravelのセキュリティー勧告やCVEって公式にWEBで発表してますか？
もしくはセキュリティー情報の公式のメーリングリストなどあったら教えてください

そういや似たようなカレンダーReactで作ったな…

>>133
dockerコンテナ化されてるんだからOS関係無くない？

LaravelはMariadbってサポートしてますか？
PostgreSQLやsqliteは接続できるのに
Mariadbとの接続がうまくいかないです

中身はMySQLだぞ
繋がらないわけがない

>>140
Laravelの中身がMySQLということですか？

もっと基本的な事から学んだ方が良いと思う

さすがにネタだろw
あと質問者はID出したほうがいいぞ

色々試したんですがMariadbとやっぱりつながらないです。
動作確認用モデルと動作確認用コントローラを作成して
以下を行いました。

・artisan tinkerでモデルのall()を実行→DBから取得できる
・artisan serveでWEBサーバを立ち上げてコントローラ内でモデルのall()を実行→DBから取得できる
・アプリをapacheに配備してコントローラ内でモデルのall()を実行→DBから取得できない

上記を行ったのですがapacheに配備するとDBから取得できなくなってしまいます。
.envファイルを書き換えてPostgreSQLやsqliteに変更してみるとこちらは
apache経由でもDBの情報を取得できるようです。
SELinuxも疑いましたがこちらはdisabledになっておりSELinuxに邪魔されているという
こともなさそうです

後はフレームワークを一切使用しないsample.phpみたいなものを作って
SELECTした結果を表示するようにしてapacheに配備してみましたが
これは正常にDBから情報を取得できていました。
pdoを使用したDB操作バージョンも作ってみましたがそれも正常に動作しており
やはりLaravel経由+apacheだとうまくいかないようです

とにかく不具合あったらログ見る癖をつけろ
DB側、Laravel側両方見て原因探ればだいたい解決できる

聞くならせめてstacktrace張りなよ

artisan serveで実行した状態でDB接続できるなら
DBへの接続設定等は間違っていないはず
にも拘わらずapache配備で実行できないというのは
SELinuxが邪魔しているとしか思えないんだが

お前らって色々フレームワークを検討してLaravelを採用したと思うけど
他のフレームワークではなくLaravelを選択した理由って何？

楽に作りたい時はLaravel
速度が欲しい時はGo + gRPC & Vue

>>133
やっぱりまともに動かんねぇ…
何が悪いんだか…

>>151
stacktrace張りなよ

共和国編終わったらさすがに最終章やってくれ
これ以上他の国に寄り道してほしくない

>>151
https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E8%B6%85%E4%BA%BA%E3%81%AE%E7%A5%9E%E8%A9%B1/

俺のavastが反応したんだが

何に反応したの？

>>156
kwsk

>>157
？
聞いたのは俺だが？

>>141
MariaDB=MySQLってことだよググれば分かるだろ

いやイコールではないが
フォークされた以上時間が経つにつれ差分は増えていく

俺のavastも反応してワラッタ
カスペルスキー入れたノートPCは反応しないから誤検知だろうな

>>160
そんなことを質問してるやつに言っても意味がない
イコールでいいんだよ

■ 創価学会の敵対者対策マニュアル


a）創価学会への反対者に対しては、将来的に考えても その子息子女を落とす必要がある。
　 子息子女の不幸により折れる可能性も高い。
　 子息子女へは、創価学会へ反発しないよう躾ける。
　 反対者の子息子女の結婚は潰す必要がある。
　 会員の子息子女の敵であってはならない。

b）会員の商売敵を排除する事は資金確保の上で重要である。
　 商売敵の子息子女も、将来を見据え落とす必要がある。
　 会員の子息子女の商売敵にならぬよう落とし躾ける。

c）反対者が地域で高評を受けぬよう計らう。

d）各会員が確認し連帯し、自然と不幸になったように落とす必要がある。
　くれぐれも会員が疑われてはいけない。

e）反対者の言に信頼が集まらないよう計らう。

f）反対者の安定に繋がる者らも落とす必要がある。

g）常に経済的/心理的に圧迫させる必要がある。

h）会員はお互いを目の合図で確認の上で仲間を集め,戦う時には常に3人以上一組で攻撃し精神疾患に追い込む。

i) 反対者を会のネットにブラックリスト登録し全国何処へ行っても追及の手を緩めない。

j) このマニュアルは会員の周囲には絶対知られては成らない。

Laravel最強すぎへんか？
これはCodeigniterを越えただろ

しかもこのスレにもよく出現する零碧アンチで確定ｗ


503 : 名無しさん＠お腹いっぱい。 (ﾜｯﾁｮｲW 5fd4-t97i [180.11.210.227]) 2020/03/25(水) 01:27:08
零の軌跡とかいうストーリーもキャラも魅力が全くないクソゲーだから仕方ないのでは

779 : 名無しさん＠お腹いっぱい。 (ﾜｯﾁｮｲW 5fd4-t97i [180.11.210.227]) 2020/03/26(木) 03:31:34
またロイドやらなんやら特務支援課の雑魚を操作しないといけないのか
あんなゴミキャラ使うのうざいんだよなー
1章あたりで全員死んでくれないかな

243 : 名無しさん＠お腹いっぱい。 (ﾜｯﾁｮｲW 5fd4-t97i [180.11.210.227]) 2020/03/27(金) 23:40:09
むしろ特務支援課だけやりたくない
ロイドやエリィなんてキャラとして何の魅力もないクソゴミキャラだから

722 : 名無しさん＠お腹いっぱい。 (ﾜｯﾁｮｲW 5fd4-TbzQ [180.11.210.227]) 2020/03/31(火) 06:45:54
零碧擁護してる奴ってほぼ40以上のおっさんだろw

878 : 名無しさん＠お腹いっぱい。 (ﾜｯﾁｮｲW 7dd4-dgXn [180.11.210.227]) 2020/04/03(金) 22:53:44
軌跡界隈で熱望されてるのが序章でロイドが死ぬストーリー展開

979 : 名無しさん＠お腹いっぱい。 (ｱﾝﾊﾟﾝW 7dd4-dgXn [180.11.210.227]) 2020/04/04(土) 20:13:43
ロイドはパトリックにも勝てない小者でしょw

codeigniterは元々眼中に無かったでしょ、っていうかcodeigniterってフレームワークっぽく無くしライブラリに近い感覚だね。

でもCodeigniterが一番使われているみたいだね

新規採用だとLaravel一強だろうし、徐々に減ってくるだろ

>>168
もうやめてｗｗｗｗ
笑い殺す気かよｗｗｗｗｗｗｗ

>>168
もうｗｗｗｗ笑いが止まらなくて飯がまともに食えねえｗｗｗｗｗ

ちょっとver7になってからの仕様変更が激しすぎて結構つらいな

>>171
仕様変更kwsk

>>167
どうして嘘つくの？

Laravel vs Codeigniter
Dodaの求人数 → 145 vs 17
Greenの求人数 → 564 vs 78
Indeedの求人数 → 1,813 vs 169
Qiitaの検索結果 → 9,374 vs 397
Stackoverflow検索結果 → 144k vs 67k
Githubのスター数 → 58k vs 18k
Googleトレンドの結果 →

まぁLaravelって5年前くらいからやっと使われだしたようなものだから既存システムの数が伸びるのはまだまだこれからなんじゃないかね

>>1
東京三鷹の土井（剛）莉里子



氏名■土井剛（莉里子）

生年月日■1994.3.7

前住所■〒181-0013 東京都三鷹市下連雀5丁目3 シティハイツ吉祥寺通り4階

性別■男（詐欺師のため、戸籍変更している可能性あり）

Twitter■@copy__writing　@kotobamemo_bot

疾患■性同一性障害（LGBT）、発達障害（ADHD）、アスペルガー症候群、統合失調症



●一方的に好意を寄せる男性から相手にされないと嫌がらせを繰り返す
●某大学病院の精神科隔離病棟にて強制入院
●骨が見えるほどのリストカット
●奇声をあげながら自室部屋のドアをナイフで突き刺す
●シティハイツ吉祥寺通り4階から飛び降り自殺
●性転換手術（金玉を取る）
●トラブル...嫌がらせ、ハッキング、乗っ取り、たかり、脅迫、殺害予告...etc
●去年から今年にかけてyoutuber同士のトラブルの仲介に入り某大手youtuberから複数回に渡り1億近い慰謝料をふんだくる
●自宅の吉祥寺にいられなくなり、大阪に潜伏中（警察からも逃げている）

PHPって色々なフレームワークがあるわけだが
お前らってLaravelのどういうところに魅力を感じて
このフレームワークを選択したの？

phpフレームワークはLaravelの他にはCakeとFuelしか使ったことないんだが、端的に言うとLaravelはきれいに書けることかな。
コードを書くほどLaravelの設計の美しさが分かる。
Cakeは規約キツすぎだし、ルーター書かないってのがキモい。
つうかCakeでルーターにmiddleware設定したくなったらどうすんだろう？

あとLaravelはbladeテンプレートエンジンも良かったな。今はもう使ってないけど。

オフショアに安く作らせるともれなくLaravel使いやがるのでツライ。
向こうではLaravelしか知らないPGがどんどん醸成されてるんだろうな。
日本も同じかもしれんが。
緊急バグのリカバリ対応で直接SQL流すから寄こせと言っても、生SQLを書けない奴ばかりだ。
で、Laravelの糞コードを見る羽目になる。

Laravel使うやつって確かにSQL書けないよな

springおじさんまた来たのか
謎のSQL書けるマウントがまた始まったよ、自慢にすらならんだろw

springおじさんってなんだ？

>>20 を発端に煽られたことを根に持ち「Spring使ったら何もできないくせに」って煽ってくるおじさんのことだよ

Symfony使ったら何もできなくせにとか
PHPのフレームワークで反論してくるならまだしも
何故別言語であるJavaのSpring Frameworkを持ち出してきたのだろうか

Laravel使っててSQL書けないやつに遭遇したことないけどどうやってクエリ書くんだ
まずSQL書いて確認してからクエリビルダに書き換えないと、いきなりLaravelのクエリビルダで書くの難しい

Spring FrameworkはSpring Bootが最高すぎる
あれフレームワークの革命児だろ

Laravel便利すぎないか？お試しでTodoアプリ作ってみたが
他のフレームワークだったら３０分かかるところを
Laravelだったら３０分でできた

>>186
変わらねぇじゃねーか

>>188
これもうわかんねーな

Javaとか1行も書きたくないな
まだC++とかC#の方が許せる

>>189
今だとJVM系であるKotlin大先生が活躍中だぞ

もうJVMの存在意義自体が疑わしいけどね
JVMならクロスプラットフォームだとかいう神話はとっくに終わってる

>>191
それがここ最近何故か知らんけど急に研究が始まったぞ
PHP、C#、Node.js、C++、等の各開発者達がJVM上で
言語を動かせないかチャレンジしている

Laravel使ってみたけどSymfonyとどっちがいいのか
迷っているんだが何かメリットってある？

Vue.jsとかReact使うならLaravel
それ以外ならSymfonyでいいんじゃない？

ということは機能的にはほとんど同じということですか？

リクエスト ショリシテ レンダリングケッカ カエス
フレームワーク ミンナ キョウダイ

今どきレンダリングはやらんでしょ
フロントフレームワークでやったほうが楽なんだから

時代はファルコンやろ

>>198
PHP8で廃棄決定やん

今まで普通にLaravelのbladeで画面もやってたから
そこらへんのVue.js使うチュートリアルやってもVue.jsでフロント側書くほうが
楽というのがいまいち実感わかない
みんなはどういった理由で楽と感じるの？

一番はモバイル対応だろ。
モバイルでもブラウザで済ませる方針なら従来型でもいいが。

Laravelはそもそも根っこの設計部分でフレームワークとして致命的におかしい
初心者が設計したと思われても仕方ない　最低だ
Laravelは根っこから設計に問題があるしおまけにFacadeに頼る逃げ癖もついている、Laravelの初期バーションがリリースされた頃から何も変わっていない
フレームワークのコンプレックスからかLaravelは他のフレームワークを敵と見てる
悪意があるわけでなくもう何も考えないで設計されているしその上他フレームワークでやっているような
当たり前の機能の実装を避けてきた、根本的にフレームワークとして致命的
Laravelは自分の価値観が絶対だと信じこんで一般的なフレームワークの基本設計からズレていることに気づけなかった

Laravelアンチ降臨

>>202
もっと具体的に
根っこの部分とは？

根っこも何も動作が重いに尽きる。

>>200
端的に言うと、MVCのVがすっきり分けられるってとこかな。

・htmlにphpを混ぜ込まなくて済む。（可読性、IDEの補完精度）
・htmlとphpのネストを別々にするというキモいことをしなくて済む。
・ビジネスロジックはAPIで、表示上のデータの整形は画面で、と分担がより明確化する。
・非同期処理でデータとってきた時の画面の更新はフロントフレームに任せるから楽。

>>201が言うようにネイティブアプリが必要になったときもそうしとけば楽だしな。

お前らってlaravel-mix使ってる？
それともvue createとかで別プロジェクト作成してる？

vue create使ってます

>>202
laravel云々を論じる以前に、伝達と表現技術を欠いて残念です。繰り返しが多い。抽象的かつ厳密さが無い。故に感覚的表現。ついでに根っこと言ったり、根本と言ったり概ね幼稚な表現。本当のところ理解出来てないんじゃないの？と想起させる。

私の主観はあなたの文章を以上のように感じてしまいました。アンチならアンチらしく理論武装して挑め。エラそうにかく言う私はlaravel使いこなせてません

VueよりもReactの方が絶対いいって！

React学んどけばモバイル開発も出来るんだぜ！
Vue Nativeも結局React Nativeにトランスパイルされるし

じゃVueでええやん、ってなる

react native 使ったことないけど実用性どうなの？
結局、 swift と kotolin のほうが良いやってならない？

あ、android と ios の互換性でって意味ね

Reactの方が細かいパーツの部品化がやりやすいから
使い込めば使い込むほど効率化できてくる

TypeScriptでやろうとするとReactがいいってなるな

過疎ってきたな
やっぱPhalconかー

lumen使いにくいな
やっぱlaravel使うわ

Laravelは今や世界最強のフレームワークだからな

５年後にLaravelを称賛するヤシが絶滅危惧種になってる
に１アベノマスク

やっぱりSymfonyがNo1になるのかな？

Wordpress/Drupalが新たな「フレームワーク」として残り続ける。
それ以外は他言語への流出が続く。

だからPhalconだって

お笑い芸人アンガールズのカッコいいほうは最近プログラミングの
勉強始めたらしくLaravelをやってるみたいだな

wordpressだけは絶対ないwあれはおもちゃでしょw

トイザらスにwordpressは売ってないと思うが

>>225
WordPressは、バージョンアップするたびに素人さん志向になっている。
ブロックエディターなんて必要なの？

Laravelって使ってみて思ったけどなんでUser.phpが直置きなの？
Modelsフォルダとか作ってそこに入れればいいと思うんだが
デフォルトでそうなっているのは何か理由があるんだろうか

>>228
俺も初めて触った時に同じことは思った。
「モデル」の定義は開発者によって様々、つまり曖昧な概念だから敢えてモデル用のディレクトリを作らなかったらしい。
だから開発者が自由な場所に配置できるようになってるし、「Models」というディレクトリを作ってそこに置いてもいいんだってさ。
俺はいつも「app/Models」もそうしてるよ。
てか公式見解は「Model」なんだけどね。

Where Is The Models Directory?

When getting started with Laravel, many developers are confused by the lack of a models directory. However, the lack of such a directory is intentional.
We find the word "models" ambiguous since it means many different things to many different people.
Some developers refer to an application's "model" as the totality of all of its business logic, while others refer to "models" as classes that interact with a relational database.

For this reason, we choose to place Eloquent models in the app directory by default, and allow the developer to place them somewhere else if they choose.

https://laravel.com/docs/7.x/structure

>>229
modelsの意味が曖昧だとしてもapp/modelsなら別に曖昧じゃないと思うけどね

LaravelはModelの意味は開発者によって様々といいながら、Laravel独自のModelという概念があるし、
その概念はDDDとかクリーンアーキテクチャでいうモデルと全く別物だからタチ悪い

>>231
DDDとか取り入れる時はEloquentsディレクトリ作ってそこにLaravelの所謂モデルを入れてる
DB取得にだけ使うから呼び方もモデルじゃなくてエロクウェントゥにしてる

うちの会社railsからlaravelに主力を変えた

symfonyしか知らんけどlaravelはhtmlのformどうやって作るんや
symfonyはformを作成する機能があってややこしいけど

>>234
symfonyもlaravelも普通のhtmlのようにform書けるぞ
わざわざFormBuilder的なの使わなくても良い

CakeにもあったけどFormBuilder的なの使ってる人居るんだな
生htmlかフロントフレームワークでいいじゃん
却って分かりにくいわ

>>232
lazyじゃなくなるな。APIなら大した問題ではないか？

>>235
えそうなの？うちの会社じゃformクラス作ってるが却って分かりにくい気しかしない

ぶっちゃけVueとかReactとかと組み合わせて使わないんなら別のフレームワーク使った方がいいんじゃない？
活発なバージョンアップでバンバン互換性が切れてるしLaravelだけの機能で全部賄ってたら古いバージョンにしがみつき続ける事になると思うんよね

>>237
ビジネスロジックにフレームワーク絡んでない方が楽できる場合もあるでしょ
まあケースバイケースってやつ

掌田津耶乃って人のlaravel入門ってどうですか？
評判いい？

評判いいよ

寧ろそれ以外の本はちょっと微妙だよね

>>241
やめておくのが吉
ご近所さんながら、玄関前に俺がかったのを置いといてあげるよ

できればなぜやめておいたほうがいいのかの理由も知りたいです

掌田津耶乃の本はプログラミング初心者向けでググれば誰かがウェブにおんなじようなこと書いてそうな内容
とりあえず公式ドキュメント（かその日本語訳）読んである程度分かりそうだったり
分からなくてもググって答え見つけ出して解決できる人なら買う必要はない

そもそもこういう入門書ってアプデの度に仕様変更で使い物にならなくなっていくからプログラミングのはじめの一歩ならいいけど基本は公式にあたる癖つけといたほうがいいと思うよ
当たり前だけどタダで読めて更新もされるんだし

でもLaravelの日本人コミッターに聞くと絶対
掌田津耶乃が上がるからそれなりに内容はよさそうな気がするが

掌田さんのlaravel本はわかりやすくてよかった
結局ほとんどググったけど、見返すとなるほどと理解が進む。
最初に何をすればさっぱりだった自分はまず掌田さんの本を見て
そかっからググって土日になんとかcrudたてることできました。
これでやっと組み込み基板の部品表管理と論理ソースのgheへのpush環境の
laravel実装が始められる…

>>246
はじめの一歩だから本でいいんだよ
いきなり公式ドキュメントを読ませようとするなどうせ挫折する
ググるのは基礎知識があってこそだ

>>249
だからはじめの一歩ならいいと書いてあるが？

ごめん書いてなかった

>>246
Laravel初心者っぽいし最初は本のほうがいいきがするけど

だからはじめの一歩ならいいと書いてあるが？

はじめの百歩くらいは本でいいだろ公式をあたれる能力が付くのはそれから

だからはじめの一歩ならいいと書いてあるが？

>>254
ゲーム好きってほどではなく軌跡のためだけにpspやvita,ps3,ps4を買う軌跡のヘビーユーザーとして意見さして頂きたい
あらかじめいうと、ルーファスが一番好きなプレイヤーの意見と考えてくれ。
Cはまずルーファスだと考えている。
身長がまず一つ、モーションで見ると、剣を抜くモーションが完全に閃の3,4のモーションそっくり。
そしてクロウに剣を突きつけるモーションは閃の軌跡2での正体を明かした後ヴィータに突きつけるモーションと同じ
またPVで撤収するときに実はユーシスが見切れている。これは正体が露見するのを防ぐためかと思う。アーツの紫の丸い玉は閃の軌跡3,4のSクラフトで最後紫になる。
PVのモノクロでロイド、リィン、ルーファス、まぁキーアもいるが、でてるのは3人の主人公の別の世界の存在である暗示。ノーマルリィンがでてくるから他の世界のルーファスがでてもおかしくはない。
前作で生きる意味を求めていたルーファス、偽物がゆえに本物になろうとオズボーンに認められようと足掻いていた。しでかしたと言われてめちゃ叩かれてるがひたすらもがいた不器用な男のファンなんだよ。
たぶんラピスも何かの紛い物、本物ではないが存在だが何かを救って救われるルーファスストーリーと期待してます。
仮にも鉄血の筆頭でレクターやクレアのように救われていないあいつは報われて欲しいと思ってるプレイヤーの妄想です。

>>253
>>255
効きすぎだろ

>>257
お前がな　どうした？顔真っ赤にして手が震えって手ているぞ

盛り上がってまいりました

信者がこれだけLaravelに夢中になるのだから
やはりおれのパンツにリソースをつぎ込めという指摘はきわめて的確なものであったといえよう
更なる増収増益のためにはパンツのステルス化及びカスタマイズモードの採用を提案したい

キチガイだらけ

Symfony蹴ってLaravel採用する理由は？

フロントエンドフレームワーク使うんならLaravelの方がいい

>>263
なんで？
JSON返すだけならフレームワークの相性なんて関係なくない？

>>264
まさかいまどきJSONでやり取りしてるの？

>>265
してるけど？

俺もJSONだわ

>>265
まさかXMLか？

おいおい、まさか…

天下のGoogle様の場合実はjsonではなくcsv形式でデータをやり取りしていることが多い

ここの連中JSONでやり取りしてるのかよｗ
セキュリティ大丈夫か？

JSONに親でも殺されたんだろうな

サーバー→クライアントがJSONなのであって逆方向の通信にJSON使ってるヤツなんて殆ど居ないだろうし
元々表示させる為のデータが何形式だったからと言ってセキュリティ的には関係ないだろ
クライアント→サーバーがどうかってのならまだしも

いやクライアント→サーバーがJSONでも一緒だろw
平文通信ならともかくw

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

13日の金曜日には特に

お前らのアプリってパスワードも平文で保存してそう

Laravel使ってて標準のハッシュ使ってないヤツとかいるの？

>>274
それJSONに限った話じゃないと思うけど？
具体的な問題点と、JSONに代わるセキュアなフォーマットを教えてください。

JSONは悪意あるスクリプトを埋め込まれやすいってのは聞いたことあるな
JSONというよりはJSONのパース処理側に問題があるらしいが

認証使えばいいじゃん

認証とは？

>>274
それ、JSONP

掌田津耶乃のってアマゾンの評価悪すぎて

>>279
そうそう。json_decodeとかunserializedとかは、改ざんされた入力データで想定外の復元が行われる可能性があるから、信頼されたクライアントでない限りは使わないのが無難(使うなとは言わない)。

WordPressでは普通に使ってるけどね

>>284
パース時にアンセキュアな問題があるとして、それはどんなフォーマットでも言える。
それはjson固有の問題ではないし、csvだろうがxmlだろうがx-www-form-urlencodeだろうが、パースが甘ければインジェクション系の脆弱性は起こりえる。
逆に、「○○っていうフォーマットを使えばパースは安全」って言ってるならその認識を改めたほうが良い。

>>274 や >>279 「考慮すべきことが増える」とか「悪意あるスクリプトを埋め込まれやすい」って書かれてるけど、肝心の比較対象が書かれていない。

>>286
だから、使うなとは言わない

>>287
その前に君の「〇〇っていうフォーマットを使えばパースは安全」
という認識を改めたほうが良いよ

>>284
言い過ぎだろ。json仕様に脆弱性はないし（今のとこ）、json_decodeにも脆弱性は見つかってない。
その点でcsvだろうとxmlだろうと、x-www-form-urlencodedだって同じ。（は言い過ぎか）

>>288
こどおじには理解できないみたいだからそうせめてやるなよｗ

json_decode脆弱性見付かって何回かアップデートかかってるぞ

>>289
げ、まる被り（笑）まあ、あとは実装するやつの心がけ次第ということだ。

そうそう。リスク判定できない人はjsonでデータを受け取るなと。

>>291
2009年の脆弱性言われてもなあ。
>>291

json自体の脆弱性の話はしてないんだ。
使い方が悪ければ脆弱性につながりやすいというのを理解できないおこちゃまをどうしてやろうかという話なんだ。

>>295
いや思いっきりJSON固有の話してたのに、急に一般論にして話そらすのやめよう？
話の始まりは >>265 だからそれを見返してね。

「ユーザー入力をJSONでフォーマットするのは危ないですよ」
と
「どんなフォーマットを使ってもユーザー入力は気をつけましょう」
じゃ全然話が違うでしょ

>>296
どんなフォーマットだろうが不特定からの入力は、危険だからValidationは必須だよ。
特にjsonとかのデコードを前提とする入力は、さらに慎重なValidationを検討する必要があるよ。

という話をずっとしてるでしょ。

>>297
それなら早く具体的な問題点とJSONに代わるセキュアなフォーマットを挙げてみてよ。
以前のレスにもそう書かれてのになんで挙げないのかな？

顔真っ赤だな。
jsonはJavascriptとの親和性、csvはExcelとの親和性、XMLは構造の自己記述性とか、それぞれ特徴あって、好きなの選べはいいじゃん。
今回の話はJSONが良さそうに思えるけど、他の選択肢、どんなのあるん？

>>298
たとえばusersテーブルに住所・電話番号を更新させるAPIをつくるとして、

1.住所・電話番号をそれぞれ2つのパラメータとして入力させる場合
住所・電話番号のチェックを行い、それから保存。
2.住所・電話番号を連想配列に格納したものを、json_encodeしたもので入力させる場合（パラメータ1つの場合）
decodeして1と同様のチェックを行う。更に追加でdecode後に要素の過不足が無いかもチェック。それから保存。

という感じで明らかにチェックしなければならないことが増えてしまう。
そして万が一追加チェックを忘れてしまうと、実装によっては脆弱性になりかねない。

>>296
>>265はいまどきJSONでやり取りしているの？って言っただけであって
セキュリティのことは言ってなくないか？

>>298
お前が挙げろよｗ
論破されたからってなりすましは良くないと思います

>>300
頓珍漢すぎるでしょ、
content-type ヘッダを application/x-www-form-urlencode で指定して、
その中身は実はjsonだったって場合の話してるの？
そんな実装ありえたにし、そもそもバリデーションを通さないでしょ。

jsonの場合なんだから、content-type は application/json で送って処理させるでしょ。
なんで、jsonって言ってるのに x-www-form-urlencode で送るのｗｗ？

>>300
curlで書くとこういうの想定してる？
curl "http://example.com"; \
-X POST \
-d "key={\"key\": \"param\"}" \
-H "Content-Type: application/x-www-form-urlencoded"
ありえないでしょ…
普通こうだよ。
curl "http://example.com"; \
-X POST \
-d "{\"key\": \"param\"}" \
-H "Content-Type: application/json"

そもそもミドルウェアレベルで弾く話だと思うんだけど、変な例ださないでよ。

>>300
うわーそうきたか
確かにそれは誰も想定できないね
JSON危険厨はやっぱレベルが違う

>>304
問題はそこじゃないと。。。

300の書きたかったことが304のようなことだったとして、結局inputに余計な要素が含まれていないかのチェックは実装によっては必須になるな。

>>307
それいったらJSON関係ないね。
application/json ではそれが必要なのに
application/x-www-form-urlencode にしたら不要になるって話じゃないでしょ。

ちなみに、Laravelの場合は fillable か guarded 設定しないと、
(new User)->fill($request->all())
みたいなことはフレームワークレベルで出来ないから、そっちもあんま関係ないね。

お前らJSONの脆弱性についてまったく理解してないんだな
さっきから的外れなこと言いすぎ
なんだろう俺とお前らの技術レベルの差がありすぎてまともな
議論にならないな

>>309
アプリ設計者の想定外のデータが復元されうること以外になんかあったっけ？

>>308
すまんどういうことだ？解説してくれ

だから送信は普通にPOSTするって言ってるだろ
JSON使うのはサーバー→クライアントだけだって

>>311
まず EloquentModel の fill メソッドは分かるよな？
もし分からなければ、それについてマニュアル読んでからきてくれ。

例えば >>300 のケースでシミュレータする
usersテーブルにinsertする為のUIがあったとして、
その入力結果をサーバーに送信する際、どんなフォーマットが適切（よりセキュア）なのかが今回の焦点。

>>300 が言っているのは
「パラメータ部分を
-d "user={"address": "東京", "tel": "08012345678"}"
にすると、request()->get('user') をjson_decodeした上で、userの中に余計な属性が無いことを担保しなくてはならない」
と言っている。
（クォーテーションのエスケープは省略するから脳内補完して欲しい）

で、担保する必要があるのは大体、Userモデルに対し fill($request->all()) するようなケース。
（今回だと $casts = ['user' => 'json'] で定義された fill(request()->get('user')) かもしれない。 ）
担保するって言っても $fillable を定義すれば良いだけだが。

そんなフォーマットはありえないから置いておくとして、
実際によくあるのは下の2パターン。
-d "address=東京&tel=08012345678" -H "Content-Type: application/x-www-form-urlencoded"、
-d "{"address": "東京", "tel": "08012345678"}" -H "Content-Type: application/json"
で、余計な属性が無いか担保する場合は前者も後者も変わらない。
逆に、前者の場合は担保が必要なくなる言ってるのはそれはそれで問題だね。

書き方はLaravelで例えたけど言語やフレームワーク変えても書き方が変わるだけで考え方は同じ。

>>312
だからお前が言う普通のPOSTって何だよ
curlで書いてみてくれ

なんでcurlなんだよ
URLSearchParamsとかFormDataにappendしたパラメーターをaxiosに渡すような極々シンプルなPOSTだよ

なんでcurlでかくのをそこまで拒むの？
本当は俺らの議論についていけてないだけじゃないのか？

>>312
httpメソッドが何かなんて誰も焦点にあててないのに何で急にPOSTが出てきた？

json_encodeやらjson_decodeって関数名が出てくるのがまずおかしい

>>315
いや、curlじゃなくても良いんだけどね。
言語に依存しない点で例に適切だろうからcurlが良いなって思っただけだよ。

で、その場合はaxiosにjavascriptオブジェクトを渡してapplication/jsonをPOSTするのと比べてどう適切（セキュア）なの？

ここまでの流れ
JSONは危険おじさん　「JSONは危険」
何が危険なのおじさん「何が危険なの」
JSONは危険おじさん　「パースする時が危険」
何が危険なのおじさん「何が危険なの」
JSONは危険おじさん　「危険なものは危険」
何が危険なのおじさん「危険な例をだせよ」
JSONは危険おじさん　「普通にPOSTするだけ」

>>320
普通にPOSTするだけ　は　何が危険なのおじさん　の方だよ

>>321
普通にPOSTするだけおじさんは「サーバー→クライアントにしかjsonを使わない」って言ってるよ
例もjsonじゃなかったし

>>272

でも実際JSONは危険だよね
去年のやつだってJSONの解析処理を逆手にとって
顧客情報盗まれたわけだし

そういえばLaravelの次期バージョンでフレームワークによるJSONサポートをなくそうかって話出てるね
多分この案は採用されないだろうけどさ

>>325
とりあえずissue見てみたけど見つからん
どこに書いてあるの？

結局「JSONは危険おじさん」による具体例と代替フォーマット無し

ヘッダーとしてAuthorization: Bearerで認証トークンくっつけて送信しろボケナスくんたち

>>324
去年の奴ってなんだよw
去年あった大きい事件で言えばセブンペイのパスワードリセットの件か？
JSONは関係無かったが

微妙に違うおじさんが5人くらいいる気がする

今はContent-typeにapplication/jsonを指定することの是非を話していて、
Authorizationヘッダは関係無いよ。
それともお前の頭の中ではAuthorizationヘッダにBearerトークンを指定するとなぜか急にJSONのパースがセキュアになんのかよｗ

おじさんそれぞれ名前を付けてくれや

一つの仕組みだけでセキュアな送受信なんかできねーのに一つの仕組みだけにこだわってるボケナスくん

curlの話してたら結局API認証の話になるのはある意味仕方ない

>>331
なるだろ　無知を晒すなよｗ

>>333
うん、じゃあAuthorizationヘッダにBearerトークンを指定するとJSONのパースがセキュアになる理由もどうぞ。

>>335
>>336

スレの流れ見る限りJSONは危険じゃないよおじさんの負けでいいんじゃないかな？
何ら反論できていないし

>>336
自演たのしいでちゅか？（＾＾；）

ボケナスjsonパースジジイは一生ビビってろ

JSON危険おじ「JSON送信するのは危険」
何が危険おじ「何が危険なの」
JSON危険おじ「パースするとき危険」
何が危険おじ「どう危険なの」
JSON危険おじ「危険なものは危険」
何が危険おじ「危険な具体例と危険じゃないフォーマットは？」
JSON危険おじ「普通にPOSTすればいい」
何が危険おじ「普通って何？content-typeで言うと？」
JSON危険おじ「…」
何が危険おじ「もしかしてx-www-form-urlencode？同じじゃん」突然現れた謎のおじ「Bearerトークン付ければ安全」
何が危険おじ「BearerトークンとJSONのパースは関係無いけど？」

で危険な具体例まだー？
結局 >>300 だけなの？彼は論破されたままダンマリだけど。

>>338
いいんじゃない？JSON嫌いおじさんは妄想で生きてけるんだし。
何も実例出さない段階でお察しだから。
CSVをJSONにしたら脆弱性出て、XMLにしたら直って、YAMLだとパフォーマンスが出なくて、x-www-form-urlencodedだとセキュアじゃない、はいはい、それ全部実装とバリデーションの問題だから。

だからお前が言う普通のPOSTって何だよ
curlで書いてみてくれ

出たなコピペマン

laravelより日本語勉強しなよオッサンたち

>>344
コピペじゃねーよ
俺がずっとcurlで例を書いてくれって言ってるのに結局書いてくれないから催促している

マジレスするとjsonが一番脆弱性が多いというのは確か
jsonの解析処理に問題があるからしょうがないね

>>347
jsonそのものじゃなくjson起因な

>>346
その話って >>319 で片付いてるじゃん。
なんでわざわざ騙るんだろう？
x-www-form-urlencode は json と比べてどうセキュアですか？という質問に回答できなくて（論破されて）悔しかったのか。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>363
> jsonハイジャック

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

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

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

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

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

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

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

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

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

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

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

v8ってChrome系のjsの事だろ

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

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

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

ブラウザアプリに限った話だけど、
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がどうこうの話じゃないんだっけ？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>399
え？それって結構初歩的な話では・・・・

>>396
だから除外しているって言ってるだろ
お前らって日本語理解しているか？
この程度も理解できないようじゃお前らLaravelの簡単なことさえもわからなくて悩んでるんじゃないのかｗｗ
まあLaravel使うやつはこの程度か・・・

話を戻すとjsonは脆弱性が多いので使わないほうがいい
csvやxmlについては実装次第ということか

>>394

Laravelは何も悪くない。
オフショアにやらせると速攻で作ってくれるので。
それしか知らない奴が問題。
メール送るだけのバッチまでLaravelを通しやがる。メモリ食うだけだ。
だから、どこぞのエージェントが回してくるスキルシートのアピール欄に
「Laravelならお任せください！」とか書いてあると、その段階でNG。

>>403
Laravelそのものが何も悪くないならお前スレチすぎだろ
ただの仕事の愚痴じゃねえか

>>404
これが仕事の愚痴に見えるようならもう少し勉強してから俺にレスしてくれ

メールバッチごときのメモリ使用量を気にする環境ってなんなんだよｗｗ
まあ塵も積もれば山となるのかもしれないけどさ

お前らってLaravelは使っているだろうけど
LumenとかLaravel Zeroとかは使っているの？

>>403
「WordPressならお任せください」
「CakePHPならお任せください」
「Symphonyならお任せください」
「Laravelならお任せください」
「PHPならお任せください」
「Rubyならお任せください」
「Javaならお任せください」
「Nodejsならお任せください」
どれ選ぶ？

CodeIgniter&FuelPHP「僕らは・・・・・・」

>>405
反論するならそこじゃないだろ
Laravelが何も悪くないならお前はスレチ

>>410
Laravel悪いぞ　メール送るだけでメモリ空メモリくりだ

>>411
メモリ空メモリくりって何の誤字？

まぁそれはともかく、実装の責務だったって話は無いの？
昨日まで「JSONは脆弱だ」と騒いでた人たちいるけど、実際には実装が悪くてJSON固有の話ではなかったように、
それは本当にLaravel固有の問題なの？
誰が実装したの？
実装に問題は無かったの？
メールドライバは何を使っているの？
仮にメールドライバを一般的なSMTPと仮定したとして、SwiftMailerの問題だったりしない？
Laravelはメール送信にSwiftMailerっていうライブラリを使っているんだけど、SymfonyもSwiftMailerを使っているから、実はSymfonyに変えてもメール送信に使うメモリ量は変わらなかったりしない？

>>412
いやJSONは実装ではなくフォーマット事態に脆弱性あるでしょ

laravelのjson処理には脆弱性あるよ
でもそれはアップデートすれば治るよね？

>>412
つまり他人を疑う前にまず自分を疑いましょうって話だわな
このエッセイ思い出した
https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E4%BB%96%E4%BA%BA%E3%82%88%E3%82%8A%E3%81%BE%E3%81%9A%E8%87%AA%E5%88%86%E3%82%92%E7%96%91%E3%81%86/

一部抜粋

> もちろんシステムソフトウェアにもバグはあるものですが、責任を押し付けたがる人が期待するよりは、はるかに少ないと言えます。
> 何か問題が起きた時には必ず真っ先に自分の書いたコードのバグを疑うことにしています。自分のコードを徹底的に調べて、それでもバグが見つからなかった時、初めてコンパイラのバグを疑い、スタック汚染を調査します、たとえば

laravelって組み込みlinuxの案件でしか使ったことないな
シェア的にはNo1のはずだけど日本ではまだCakePHPのほうが上なのかな

>>416
laravelは脆弱性が多すぎるので日本ではあまり使われていない
日本だとsymfonyかcakeが主流

>>415
いや、少なくともJSONに限っては深刻な脆弱性があるよ。
俺も自分の実装を見直したんだけど、やっぱり実装の問題ではなかった。

※ この期に及んで具体例無しで脆弱脆弱言ってるやつは荒らしとみなして触らないこと。

>>419
だからおれが>>300で具体例挙げたじゃん

>>420
>そして万が一追加チェックを忘れてしまうと、実装によっては脆弱性になりかねない。

>実装によっては

んでLaravel固有の具体例は？

誰かLaravelのissueにjsonの脆弱性について質問してこいよ
これで決着つくだろ

>>420
でもお前別人じゃん

LaravelがMySQLと相性悪いと感じるの俺だけ？
DBサーバがいるわけではなくてLaravelとDBが同一サーバにいるんだけどなぜか接続が切れることが多い
誰が悪いのか調べるために実験したんだが
・素のphpでDB接続→接続は安定
・cakeでDB接続→接続は安定
・codeigniterでDB接続→接続は安定
・symfonyでDB接続→接続は安定
・laravelでDB接続→５分に1回の割合でコネクションが切断される

laravelだけ通信が切断されることがあった。同じ系列であるmariadbでも
上の実験を試してみたが結果は同じだった

laravelで接続を安定させるために変更すべきオプションとかあれば教えてください

フレームワークの設定はDBのユーザ名とかDB名とか変更したぐらいで
その他の設定はいじくってないデフォルト設定という認識でＯＫ？

その通りです。デフォルトのままです。

考えられるとしたらコネクションプーリングのkeepaliveみたいな役割する間隔の
設定値だけどlaravelってデフォルトでコネクションプーリング動くんでしたっけ？

>>427
そもそもphpとmysql間でコネプー維持するもんなの？
javaでイベント駆動なら分かるけど、phpでイベント駆動なんて聞かないし、
リクエスト終了時にコネクションも切断するでしょ。

自分が今まで常駐したところだとPHPでもコネプーしているシステムが多かったですね
DBの接続切断処理に対するサーバ負荷を下げる目的でやっていたみたいですが

お前らおすすめのLaravelチュートリアルって何？

>>1に貼ってあるやつ

いまから新規構築だったらlaravel一択だろ

めずらしくこのスレ議論が白熱しているな
いつもこのぐらい白熱していればいいんだがな

>>433
json信者が発狂してるからね

>>433
半分くらいは荒らしみたいなもんだったけどな

>>435
でもお前jsonの脆弱性答えられなかっただろｗ

やめたれｗ

>>435
お前がjson脆弱性君か早くjsonの脆弱性について答えてくれよｗ

>>408
ExpressじゃなくてNode.js？

>>424
なんかそれこのスレで散々言われてたけどVPS or VirtualBox+CentOS7+Nginx+Laravelでやってる俺はそういう現象に見舞われた事全くないんだけど
どんな環境でやってんの？

未だにDockerを使わずVBで鯖構築してる奴いるのか

逆にDocker使ってるならMySQLとLaravelの相性云々言う前にDockerってキーワード出てこないとおかしくない？

>>418
だからさあ、具体的な内容書けよ。
仕様の脆弱性なんだよな。
XMLの実体参照の問題みたいなのでもいいから示してみなよ。

jsonおじさん呼び込んだそもそもの原因である>>263って結局どうなの

バカみたいに伸びてると思ったら外部JSONが汚染されてるからどうのこうのって話？くだらな、スレチもいいとこじゃん

「Laravel得意です！」のアピールはやめとけというのがこのスレの結論だな。

>>444
jsonを返すだけなのでフレームワークの相性は関係ない

>>446
糖質

>>447
全然違うだろ 仮にapiサーバとして動かす場合はLaravelが一番優れている
他フレームワークと違って細かい制御が可能になる

webpackを自分でセットアップしなくて済むのはビギナー的には大きい

>>449
だから具体的理由も書けよいつも糖質君

>>450
LaravelMixのこと言ってる？
あれ独立して使える時点でLaravelとの相性は関係なくないか？

そもそも言うほどwebpack自分で設定するか？
vue create か create-react-app コマンド打つだけで雛形用意されるし、そこから追加の設定が必要ならLaravelMixでも変わらない。

>>451
お前が書けよ

>>452
でもそれバックエンドとの結合テストでデバッグする際に毎回サーバーにdistのjsをコピーするって事っしょ？

>>454
つまり？

>>455
ごめん、24歳保育士の彼女と電話してた

やめたれｗｗ
>>455だって彼女ぐらいいるよ・・

>>456
俺の成りすましすんなゴミ

>>455
つまりLaravelはフロントフレームワークとの相性がかなり良い
他フレームワークと違って細かい制御が可能でビギナーにも優しい

>>458
24歳保育士の彼女との電話がなりすましってことは
彼女いるのは嘘なんですか（；ω；）

>>460
55歳保育士のおかんと電話してた

>>460
彼女どころかすでに結婚してるから
ちなみに俺フェラーリに乗っていてコロナ自粛前は
毎日スポーツジムに通ったり映画館や近くの高級店で優雅な朝食を
食べたりしていたな　ごめんねレベルが違う話しちゃって

結婚しているはまあいいとして
普段の生活情報いりますかね？

>>459
細かい制御って？

>>464
知らないなら自分で調べろよ

変なやつ増えたなぁ

いや昔のメンバーが戻ってきたとみるべきだろう

>>465
具体例出せって言われてるのいつ理解するの？

>>462
なんか一般人が必死に考えた金持ちのイメージって感じなんだけど・・・・

HTTPメソッドの使い分けはその操作が安全であるかどうか、べき等であるかどうかで判断するのが原則。

安全→サーバ、特にDBなどの状態を変化させないこと
べき等→その操作を何度行っても結果が同じであること

検索のような安全でべき等な処理はGETが推奨。
要はGETを使う場合はブラウザ側でキャッシュしても問題ないようにしておいてねということ。

POSTはリソースの新規作成など安全でもなくべき等でもない操作に使う。
ただし、クエリパラメータに出したくない項目がある場合や、検索項目がとんでもなく多くてURLが長くなる場合などに、安全でべき等な操作であってもPOSTを使わざるを得ないこともありうる

GETであることの他の利点は、Google検索のようにURLだけでそのまま検索結果の表示ができること

つまりjsonだけで行う通信は脆弱性があるということ

× つまりjsonだけで行う通信は脆弱性がある
○ 話は変わるがjsonだけで行う通信は脆弱性がある

>>470
× つまりjsonだけで行う通信は脆弱性がある
× 話は変わるがjsonだけで行う通信は脆弱性がある
○ つまりどんなプロトコルだろうとPOSTのような処理には作り方次第で脆弱性を生むリスクがある

�@edit画面が呼ばれ、DBから初期データ取得してフォーム要素にセットして表示
　⇒ この画面で編集されて[確認]ボタン押されPOST送信される

�Aconfirm画面が呼ばれ、フォームデータを取得しバリデーションして以下２通りの処理に分かれる
　その１) ⇒ バリデーションＯＫの場合、確認画面を表示。return view('path.to.confirm', compact('data'));
　その２) ⇒ バリデーションＮＧの場合、edit画面に戻しエラー表示。return view('path.to.edit', compact('data', 'error'));

以上のような画面遷移があるとすると
path/to/edit.blade.phpのフォーム要素valueの書き方をどうすべきか迷っています。

DBから取得し、そのままビューに渡すと value="{{$data->hoge}}" 形式で書きます。
edit画面に戻す時にそのまま渡すと配列のため value="{{$data['hoge']}}" こう書くことになります。

なので両方に対応するには value="{{$data['hoge'] or $data->hoge}}" のように書くことで対応できそうです。
でもスマートではないのでedit画面に戻す時は $data = (object)$data; のようにキャストすることで value="{{$data->hoge}}" だけでよさそうになりそうです。

これって他にもっといい方法ありますか？

>>473
6.x で例書くけど今度からはバージョンも書いたほうがいいぞ。

> return view('path.to.edit', compact('data', 'error'));
これが駄目
正解は FormRequest クラスを使う。
https://laravel.com/docs/6.x/validation

どうしてもコントローラーでバリデーションしたければこれを使う。
return back()->withInput();

そして view では old 関数を使う。
<input type="text" name="title" value="{{ old('title', $data->title) }}">
第1引数は前回入力値のname属性名。第2引数はデフォルト値。
https://laravel.com/docs/6.x/requests#old-input

書いてあげたぞ
https://paiza.io/projects/XrMo0UYmazpxy6h5np-9YA

Oracle「Laravelもボクが管理するよ」
ってなったら終わりだな

FormRequest使うと入力エラーだと入力画面に戻ってoldで入力値が取れるけど、その時にFormRequest内で入力値に追加することってできないのかな
やりたいことは画像アップロード付のFromでエラーで戻った時に正常にアップロード済みの画像は再選択しなくてもいいようにしたいです
画像でエラーが出た時はもちろん再選択でいいです
なので入力エラーの時は入力データに別のキーでアップロード済み画像のフルファイル名と元ファイル名を持たせようかと思ったんだけどうまくいかない

そういう用途用のlaravel用ライブラリ誰かが作ってた気がするけど
ライブラリ名が思い出せない　すまんな

>>477
画像ファイルそのものをpostするのではなくbase64エンコードした画像をpostしちゃえば、ただのstringのやりとりだし簡単に解決じゃね？

つか最初からSPAならそんなこと悩まなくて済むのにね。

こういうのがいるからセキュリティリスクを生むんだよな

>>477
SPAにしちまえYO

>>481
SPAだのjsonだのbase64だの言ってる情弱共は脆弱性の「ぜ」の字も知らないんだろうね
何が脆弱なのかも分かってないから「根拠ガー」って連呼するしかできない

設計レベルの質問でないのに、すぐSPAにしろとか回答するのは傍から見てもムカつくよな。

>>483
いつまでふんわり指摘俺カッケーやってんの
具体的根拠が示されないまま進むふわふわ議論を良しとする考え方の方が危険だわ

お前らってJavascript側ではバリデーションやって、
サーバ側ではバリデーションやらないという片手間落ち実装してそう
ちゃんと両方に実装しなきゃ駄目daz


dareka zenkakunyuryokunimodosuhouhouwooshietekudasai

>>486
次元が低すぎる議論はしてないです

>>486
何言ってるの。SPAにすればすべて解決するのに。

SPAはLaravelとの相性がかなり良いから正直バリデーションもあんまりしなくて良いとも思う

>>489
ほんとにそれな

バリデーションないアプリとか怖すぎてリリースできねーよ

>>486
まさかいまどきサーバーでバリデーションしてるの？

普通は両方でバリデーションやるだろ

確かにフロントとバックのバリデーション分担って悩ましいよね
結局のところどっちもやるべきなんだと思うけど

最近昔のシステムの改修しててソース見ると
フォームポスト
↓
バリデーション→確認画面表示
↓
バリデーション→本登録

みたいになってるけどこの二回は流石に要らんだろと思って
一回目のバリデーション通ったらその結果をセッションにぶち込んで二回目のところはセッションから取り出した値そのまま通すことにして
UI側にアクティブなバリデーション入れた
画面遷移の確認→確定シーケンスは保持
ただ確認画面はページは遷移せずにDOMの表示切り替えにした

VueとかReactみたいなハイカラなもの使いたいけどまだ実用できるレベルじゃないから勉強中で悩ましい

どんなにJavaScriptでガチガチにバリデーションしてもセキュリティ考えると結局サーバーサイドでバリデーションしないといけないのは変わらないしな
ユーザビリティとしては一旦JavaScriptでバリデーションしてエラー出した方がいいけど、バリデーション処理が2箇所になってメンテナンス性が悪くなる

早い時点でチェックすればいいんだから、クライアント側でやっておけばいいじゃん

セキュリティ面の考慮を除いても、DBが必要なバリデーションがあるだろが（Uniqueとか）。
フォーマットチェックだけならJSで済ましてもいいけどさ。

JSON君に倣って冗談で>>492書いたつもりだったのにマジでサーバーでバリデーションしてないやつがそこそこ居て笑えないわ

JavaScriptでまずバリデーションして要件に満たないものは弾いて送信処理ぜずにエラー処理でいいんやないの？

どうしても送信先でバリデーションしたいんならXHR通信(ajax,axios)使って飛ばした後結果次第でエラー表示するか
成功したらリダイレクトでどっかに戻すかすればいいじゃん

>>479をコード化したよ
https://paiza.io/projects/gJICjiZ28BKhWd8Ew9jXsQ

>>498
セキュリティ意識が高いだけJSONおじさんのほうがまし。

セキュリティ意識が高いのではなくもはやスレを荒らしたいだけのようにしか見えないがな

application/json はバリデーションが必要
x-www-form-urlencode はバリデーション不要
って認識だからなぁ
セキュリティ意識高いだなんて笑っちゃうよ

>>498
クライアント側でしかバリデーションしていない業務システムを見たことあるなぁ
世の中のシステムには当たり前ができていないものがめちゃ多いので
あながち冗談って言い切れないのが怖いところ

>>503
不要なんて言ってないじゃん。JSONがより必要。

>>499
ユーザーがブラウザからソースいじって勝手にフォーム書き加えたり、ブラウザのスクリプトオフにしたり、フロントのバリデーション通さずに送信するなんてかなり容易だと思うんだけと

>>505
で、より必要になるバリデーションとは？

と聞くと逃げる模様

Jおじまだいたのか

>>507
だから、POST値の項目改ざん検知だって。
きちんとフレームワークで保証されてるならいいけど、そうでないならきちんと自前で実装すべき。
言っておくがJSONとかフォーマットに限らずだぞ。
これは設計次第だから、実装者がきちんと判断できる実力を持つべき話だ。

>>509
>JSONとかフォーマットに限らずだぞ

Jおじ君、自分でJSON固有の話ではないと認めてしまった。

>>510
俺いつJSON限定と言った？

>>511
>>297

>>511
>>505 で「JSONはより必要」と言ってるよ。
お前 >>505 じゃないの？
同じ人なら矛盾するし、別人ならせめてまともな回答してくれ。

あとこのスレを JSON で検索しろ。