【PHP】Laravel【フレームワーク】 Part.3
レス数が1000を超えています。これ以上書き込みはできません。
テンプレ追加修正お願いします
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【フレームワーク】
https://medaka.5ch.net/test/read.cgi/php/1503683914/
【PHP】Laravel【フレームワーク】 Part.2
https://medaka.5ch.net/test/read.cgi/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テーブル作るにはどうすれば良い。 レイアウト部分を共通化しようと思って@includeしてるんだけど
読み込んだファイルの@section~@endsection部分が
表示されないんだけど、何で？？？ 使い方間違ってるからだろ
なんでそんな質問が沸くのか逆に聞きたい 詳しい人教えてほしい。
view composerでサイドバーに表示する情報を一括でデータベースから取得してviewに渡してるんだけど、
例えばおんなじ情報を一部のコントローラーの処理でも使いたい時がある。
このときってサイドバー用にDBたたく処理と、コントローラー用にDBたたく処理が2つになって冗長になってしまうはずだけど、
どうやって対処すればいいんだろう？
そもそもview composerの使いどころを間違っているのか…？ >>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
緩和してもまだリクエスト数が上回っているのではなく？
ログ取るとかしてリクエスト数調べて見れば？ blade分かりにくすぎない？
親ファイル基準で考えればいいのか子ファイル基準で考えればいいのかイマイチ分からないんだけど 日本語化が出来ない...
公式からjaフォルダー事持ってきたのに何故かenの方のエラーメッセージが表示される >>26
どうおかしいんだ？
https://i.imgur.com/bdYtoFE.png
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 を出してくれるからそこ見たらなにか分かるかもね。
https://i.imgur.com/AnjmG94.png
あとLaravelがエラー吐く時はapp/Exceptions/Hander の render() メソッド通るからそこで例外だしたりログとってみれば？ >>32
結局、429出なくなった。
file_get_contentsしていた箇所をcurlに置き換えただけで。
しかし、Laravelには関わりたくねーな。
ベトナム辺りに流すとLaravel使いたがるので困る。 いやー俺もSpringBoot軽く齧ってlaravelに逃げてきたけどマジで分かりやすい
一々フォームの検証でエラーがあった時に元のページにリターンするアトリビュートを指定したりしなくていいとか便利 >>33
いや、apiにfile_get_contentsは無いだろw
つうかfile_get_contentsだとまだ429が出るってことかよw >>36
出る。
curlでkeep aliveしてるって訳でもないので、Laravelのthrottleは関係ねえな。 >>33
じゃあcakeがいい？そんなの使うの老害くらいでしょ >>31
laravelがエラー出してるのかそうでないのかなんてログ取れば一瞬で分かるだろうに…
その程度の頭でlaravelとは関わりたくないと。
こういう人がオレオレフレームワークとか書いたりしてるのかな。 外注選定でここ数年Laravelばかりやってる奴はまずNGにする。
Laravelでしか物を作れないから。
とか書くと「俺は違う」という奴が出てくるが、とにかく問答無用でNG。 簡単すぎるからでは？昔っから初心者はRailsから入るなCをやれみたいな原理主義者は居たし それ言ったらフレームワーク全般に言えない？
laravelであることを特定できない >>44
Laravelでしか物を作れないって言っただろ？
こういう外注はLaravelをやりこんでいるので他の技術がおろそかになっている
例えば組み込みのファームウェア製作とかできないだろ？ >>50
javaも駄目
こういう外注はどうせSpring Bootばっかりやっていて
いざSpring Framework案件になったら全く何もできなくなる
今までこいつらができていたのは開発者が設定すべき内容を
Spring Bootが自動でやってくれていたからに過ぎない SpringBootとSpringって似て非なるものじゃないっけ？ SpringBootで思い出したけど
LaravelBootって開発中止しちゃったのかな
SpringBootと同じような感じでコーディングできるLaravelを作るって
意気込んでいたけど とりあえずこういう人とは一緒に働きたくないてのはわかる
外注さんにも選ぶ権利はある LaravelやSpringBootは駄目でSpringは良いの？
自動でやってくれるってのは駄目ってのを突き詰めていくと、
apacheやnginxを使わないでサーバーソフトウェアは自作しろとはならないのかな？
CentOS使わないで自作しろとか、高級言語使わないでアセンブラで作れとはならないのかな？ Laravel信者ホイホイか、ここは。
まぁ、どこぞのエージェント経由の面談で「Laravelなら任せてください！」と張り切ると
逆効果な場合もあるってことだ。 あほなの？
なんで組み込み任せるやつ探すのに、webのフルスタックエンジニア紹介させるんだよｗ
組み込みやってるやつ紹介するように依頼しろ。
で、そんなやつはスレチだわ。 職人は意識高い系嫌いだろうけどどっちもプライドはクソほど高いよね 今、掌田本の実践開発編読んでるけど意外と知らない事も多いな ストレージ関係の細かい事やらサービスとファザードの事やらイベント、スケジューラーやら
あとDBまわりだとついついrawで書いちゃうところを実はもっとちゃんとした書き方あったのかっていうのとか
知らなくても代替でどうにかなるような事だけどこれ使った方がスマートなつくりにできるんだろうなって感じ
まぁ公式ドキュメント全部読めば済む話ではあるんだけど使う機能の部分しかちゃんと読んでなかったんだよね 現状PHPはLaravel使うかSymfony使うの２択だな
CodeIgniterはいいのかね？ Laravelって部分的にSymfonyが使われてるとかよく言われてるけどSymfonyを知っておいた方がLaravelの深い部分を知る上で有利な事って何かある？ >>63
CodeIgniterはMVC的に管理はしたいけど、学習コストかけたくないって時期に便利に使ってた。
ほとんど素のphpで動くんで、学習は楽だったけど、いまさら使おうとは思わんかなぁ。
4が開発中みたいだけど、どうなんだろ。 Laravelを勉強するにあたって2020年現在一番おすすめの
チュートリアルってありますか？ Laravel界隈っていうかここだけだと思うけどね でもPHPフレームワークはLaravelが最強だよ 古いマイグレーションファイルって消していいの？まだよく分かってないんだけどphp artisan magrateしたら最深のマイグレーションファイルが実行されるの？ 消しちゃいかん
なんのために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ファサード使えばコントローラー云々とかルーター云々とか一切気にする必要ないけど >>95
これだわ
flash関数を使えば良いんだな
助かる Facade警察の話はもう語り尽くされただろ
使い方次第で良薬にも劇薬にもなる まぁ寧ろ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 の説明は助かりました。 MVCとオブジェクト指向の基本さえ理解してたら都度マニュアル読むだけで十分な気がする
逆にまだそっちを理解していないなら先にそっちのチュートリアルをしたほうがいいと思う 例えばredirect()がいちいち何を返すとか把握しとかないといけないもんなの？ >>116
面接でポートフォリオ提出してここ何リターンしてるか分かる？って言われて分からなかったからそれじゃコピペと同じだと言われた あとソースコードがフレームワークのルール完全に無視しているとも言われた Laravelを使うという仕様だったのになぜLumenを使用したのかとも聞かれた >>118こいつは>>117じゃない
ソースコードのルールは完全に守ってた 因みにその会社ではSymfonyを使っていた
だからSymfonyとLaravelでは向き合い方が違う可能性も考えた Symfony使う会社なのになんでLaravelで提出したの？ Lumenって事はREST特化だから redirect() はURLミスで404用json返す時くらいかな
異常系も例外投げてHandlerでjson構築して返すし
Viewあるならリクエスト成功後にTopやログイン後のユーザページに飛ばすとかあるけども
Lumenで正常系に redirect() 使用してると違和感を覚えるかも いやLumenなんて使ってないよ
それ偽レスだよ
成り済ましをやる様な腐った人間がプログラマーには多いよな
たらこみたいなナルシストが多過ぎて自分は何をやっても許されるんだと思ってる目が細いのが多い ごめん>>126だけどちょっとイラッとしてしまったすまない Symfonyの会社でLaravelで提出したのも偽レス？ とりあえず質問者はsage消してID出したらどうだ？ 有識者の皆様方、下のGitHubのプロジェクトをLinuxでまともに動くように手伝ってくれ。
2人くらいで実装がんばってるようだが、俺も同じ部分で躓く…
OSS Calendar
https://github.com/thinkingreed-inc/oss-calendar laravelのセキュリティー勧告やCVEって公式にWEBで発表してますか？
もしくはセキュリティー情報の公式のメーリングリストなどあったら教えてください そういや似たようなカレンダーReactで作ったな… >>133
dockerコンテナ化されてるんだからOS関係無くない？ LaravelはMariadbってサポートしてますか？
PostgreSQLやsqliteは接続できるのに
Mariadbとの接続がうまくいかないです >>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側両方見て原因探ればだいたい解決できる artisan serveで実行した状態でDB接続できるなら
DBへの接続設定等は間違っていないはず
にも拘わらずapache配備で実行できないというのは
SELinuxが邪魔しているとしか思えないんだが お前らって色々フレームワークを検討してLaravelを採用したと思うけど
他のフレームワークではなくLaravelを選択した理由って何？ 楽に作りたい時はLaravel
速度が欲しい時はGo + gRPC & Vue >>133
やっぱりまともに動かんねぇ…
何が悪いんだか… 共和国編終わったらさすがに最終章やってくれ
これ以上他の国に寄り道してほしくない >>141
MariaDB=MySQLってことだよググれば分かるだろ いやイコールではないが
フォークされた以上時間が経つにつれ差分は増えていく 俺のavastも反応してワラッタ
カスペルスキー入れたノートPCは反応しないから誤検知だろうな >>160
そんなことを質問してるやつに言っても意味がない
イコールでいいんだよ ■ 創価学会の敵対者対策マニュアル
http://imgur.com/6JD5hr1.jpg
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になってからの仕様変更が激しすぎて結構つらいな >>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トレンドの結果 → https://i.imgur.com/bddtGGc.png まぁLaravelって5年前くらいからやっと使われだしたようなものだから既存システムの数が伸びるのはまだまだこれからなんじゃないかね >>1
東京三鷹の土井（剛）莉里子
https://i.imgur.com/xgeBwrQ.png
氏名■土井剛（莉里子）
生年月日■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 >>20 を発端に煽られたことを根に持ち「Spring使ったら何もできないくせに」って煽ってくるおじさんのことだよ Symfony使ったら何もできなくせにとか
PHPのフレームワークで反論してくるならまだしも
何故別言語であるJavaのSpring Frameworkを持ち出してきたのだろうか Laravel使っててSQL書けないやつに遭遇したことないけどどうやってクエリ書くんだ
まずSQL書いて確認してからクエリビルダに書き換えないと、いきなりLaravelのクエリビルダで書くの難しい Spring FrameworkはSpring Bootが最高すぎる
あれフレームワークの革命児だろ Laravel便利すぎないか？お試しでTodoアプリ作ってみたが
他のフレームワークだったら３０分かかるところを
Laravelだったら３０分でできた Javaとか1行も書きたくないな
まだC++とかC#の方が許せる >>189
今だとJVM系であるKotlin大先生が活躍中だぞ もうJVMの存在意義自体が疑わしいけどね
JVMならクロスプラットフォームだとかいう神話はとっくに終わってる >>191
それがここ最近何故か知らんけど急に研究が始まったぞ
PHP、C#、Node.js、C++、等の各開発者達がJVM上で
言語を動かせないかチャレンジしている Laravel使ってみたけどSymfonyとどっちがいいのか
迷っているんだが何かメリットってある？ Vue.jsとかReact使うならLaravel
それ以外ならSymfonyでいいんじゃない？ ということは機能的にはほとんど同じということですか？ リクエスト ショリシテ レンダリングケッカ カエス
フレームワーク ミンナ キョウダイ 今どきレンダリングはやらんでしょ
フロントフレームワークでやったほうが楽なんだから 今まで普通にLaravelのbladeで画面もやってたから
そこらへんのVue.js使うチュートリアルやってもVue.jsでフロント側書くほうが
楽というのがいまいち実感わかない
みんなはどういった理由で楽と感じるの？ 一番はモバイル対応だろ。
モバイルでもブラウザで済ませる方針なら従来型でもいいが。 Laravelはそもそも根っこの設計部分でフレームワークとして致命的におかしい
初心者が設計したと思われても仕方ない 最低だ
Laravelは根っこから設計に問題があるしおまけにFacadeに頼る逃げ癖もついている、Laravelの初期バーションがリリースされた頃から何も変わっていない
フレームワークのコンプレックスからかLaravelは他のフレームワークを敵と見てる
悪意があるわけでなくもう何も考えないで設計されているしその上他フレームワークでやっているような
当たり前の機能の実装を避けてきた、根本的にフレームワークとして致命的
Laravelは自分の価値観が絶対だと信じこんで一般的なフレームワークの基本設計からズレていることに気づけなかった >>200
端的に言うと、MVCのVがすっきり分けられるってとこかな。
・htmlにphpを混ぜ込まなくて済む。（可読性、IDEの補完精度）
・htmlとphpのネストを別々にするというキモいことをしなくて済む。
・ビジネスロジックはAPIで、表示上のデータの整形は画面で、と分担がより明確化する。
・非同期処理でデータとってきた時の画面の更新はフロントフレームに任せるから楽。
>>201が言うようにネイティブアプリが必要になったときもそうしとけば楽だしな。 お前らってlaravel-mix使ってる？
それともvue createとかで別プロジェクト作成してる？ >>202
laravel云々を論じる以前に、伝達と表現技術を欠いて残念です。繰り返しが多い。抽象的かつ厳密さが無い。故に感覚的表現。ついでに根っこと言ったり、根本と言ったり概ね幼稚な表現。本当のところ理解出来てないんじゃないの？と想起させる。
私の主観はあなたの文章を以上のように感じてしまいました。アンチならアンチらしく理論武装して挑め。エラそうにかく言う私はlaravel使いこなせてません React学んどけばモバイル開発も出来るんだぜ！
Vue Nativeも結局React Nativeにトランスパイルされるし react native 使ったことないけど実用性どうなの？
結局、 swift と kotolin のほうが良いやってならない？ あ、android と ios の互換性でって意味ね Reactの方が細かいパーツの部品化がやりやすいから
使い込めば使い込むほど効率化できてくる TypeScriptでやろうとするとReactがいいってなるな lumen使いにくいな
やっぱlaravel使うわ Laravelは今や世界最強のフレームワークだからな ５年後にLaravelを称賛するヤシが絶滅危惧種になってる
に１アベノマスク Wordpress/Drupalが新たな「フレームワーク」として残り続ける。
それ以外は他言語への流出が続く。 お笑い芸人アンガールズのカッコいいほうは最近プログラミングの
勉強始めたらしく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人の主人公の別の世界の存在である暗示。ノーマルリィンがでてくるから他の世界のルーファスがでてもおかしくはない。
前作で生きる意味を求めていたルーファス、偽物がゆえに本物になろうとオズボーンに認められようと足掻いていた。しでかしたと言われてめちゃ叩かれてるがひたすらもがいた不器用な男のファンなんだよ。
たぶんラピスも何かの紛い物、本物ではないが存在だが何かを救って救われるルーファスストーリーと期待してます。
仮にも鉄血の筆頭でレクターやクレアのように救われていないあいつは報われて欲しいと思ってるプレイヤーの妄想です。 >>257
お前がな どうした？顔真っ赤にして手が震えって手ているぞ 信者がこれだけLaravelに夢中になるのだから
やはりおれのパンツにリソースをつぎ込めという指摘はきわめて的確なものであったといえよう
更なる増収増益のためにはパンツのステルス化及びカスタマイズモードの採用を提案したい Symfony蹴ってLaravel採用する理由は？ フロントエンドフレームワーク使うんならLaravelの方がいい >>263
なんで？
JSON返すだけならフレームワークの相性なんて関係なくない？ >>264
まさかいまどきJSONでやり取りしてるの？ 天下のGoogle様の場合実はjsonではなくcsv形式でデータをやり取りしていることが多い ここの連中JSONでやり取りしてるのかよｗ
セキュリティ大丈夫か？ サーバー→クライアントがJSONなのであって逆方向の通信にJSON使ってるヤツなんて殆ど居ないだろうし
元々表示させる為のデータが何形式だったからと言ってセキュリティ的には関係ないだろ
クライアント→サーバーがどうかってのならまだしも いやクライアント→サーバーがJSONでも一緒だろw
平文通信ならともかくw >>273
素人にはわからないかもしれないが、サーバ側で不特定の相手からjson形式でデータを受けるときは、セキュリティ上考慮すべきことが増えるんだよ。 Laravel使ってて標準のハッシュ使ってないヤツとかいるの？ >>274
それJSONに限った話じゃないと思うけど？
具体的な問題点と、JSONに代わるセキュアなフォーマットを教えてください。 JSONは悪意あるスクリプトを埋め込まれやすいってのは聞いたことあるな
JSONというよりはJSONのパース処理側に問題があるらしいが >>279
そうそう。json_decodeとかunserializedとかは、改ざんされた入力データで想定外の復元が行われる可能性があるから、信頼されたクライアントでない限りは使わないのが無難(使うなとは言わない)。 >>284
パース時にアンセキュアな問題があるとして、それはどんなフォーマットでも言える。
それはjson固有の問題ではないし、csvだろうがxmlだろうがx-www-form-urlencodeだろうが、パースが甘ければインジェクション系の脆弱性は起こりえる。
逆に、「○○っていうフォーマットを使えばパースは安全」って言ってるならその認識を改めたほうが良い。
>>274 や >>279 「考慮すべきことが増える」とか「悪意あるスクリプトを埋め込まれやすい」って書かれてるけど、肝心の比較対象が書かれていない。 >>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危険厨はやっぱレベルが違う 300の書きたかったことが304のようなことだったとして、結局inputに余計な要素が含まれていないかのチェックは実装によっては必須になるな。 >>307
それいったらJSON関係ないね。
application/json ではそれが必要なのに
application/x-www-form-urlencode にしたら不要になるって話じゃないでしょ。
ちなみに、Laravelの場合は fillable か guarded 設定しないと、
(new User)->fill($request->all())
みたいなことはフレームワークレベルで出来ないから、そっちもあんま関係ないね。 お前らJSONの脆弱性についてまったく理解してないんだな
さっきから的外れなこと言いすぎ
なんだろう俺とお前らの技術レベルの差がありすぎてまともな
議論にならないな >>309
アプリ設計者の想定外のデータが復元されうること以外になんかあったっけ？ だから送信は普通に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じゃなかったし でも実際JSONは危険だよね
去年のやつだってJSONの解析処理を逆手にとって
顧客情報盗まれたわけだし そういえばLaravelの次期バージョンでフレームワークによるJSONサポートをなくそうかって話出てるね
多分この案は採用されないだろうけどさ >>325
とりあえずissue見てみたけど見つからん
どこに書いてあるの？ 結局「JSONは危険おじさん」による具体例と代替フォーマット無し ヘッダーとしてAuthorization: Bearerで認証トークンくっつけて送信しろボケナスくんたち >>324
去年の奴ってなんだよw
去年あった大きい事件で言えばセブンペイのパスワードリセットの件か？
JSONは関係無かったが 今はContent-typeにapplication/jsonを指定することの是非を話していて、
Authorizationヘッダは関係無いよ。
それともお前の頭の中ではAuthorizationヘッダにBearerトークンを指定するとなぜか急にJSONのパースがセキュアになんのかよｗ 一つの仕組みだけでセキュアな送受信なんかできねーのに一つの仕組みだけにこだわってるボケナスくん curlの話してたら結局API認証の話になるのはある意味仕方ない >>333
うん、じゃあAuthorizationヘッダにBearerトークンを指定するとJSONのパースがセキュアになる理由もどうぞ。 スレの流れ見る限り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で書いてみてくれ >>344
コピペじゃねーよ
俺がずっとcurlで例を書いてくれって言ってるのに結局書いてくれないから催促している マジレスするとjsonが一番脆弱性が多いというのは確か
jsonの解析処理に問題があるからしょうがないね >>347
jsonそのものじゃなくjson起因な >>346
その話って >>319 で片付いてるじゃん。
なんでわざわざ騙るんだろう？
x-www-form-urlencode は json と比べてどうセキュアですか？という質問に回答できなくて（論破されて）悔しかったのか。 >>341
これだけでいい。
危険おじ「jsonは危険」
疑問おじ「どう危険なの？」
危険おじ「…」
危険おじ「jsonは危険」
疑問おじ「日本語わかる？」 >>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
そいつもはや荒らしだから触らないほうがいいぞ 確かにLaravelでjsonを扱うのは結構難しいよね 考慮することが多い気がする
その点symfonyだと考慮するべきことのほとんどがフレームワーク側でチェックが入るので安心して使える
ただ細かい制御をしたいんだったらLaravel一択 フロントエンドからのリクエストに対してJson形式でレスポンスで返すバックエンドを仕事で構築したことがあるけど
laravel制アプリは脆弱性のテストツールで唯一jsonハイジャック対策が不合格になったのに対してsymfony制アプリはすべて合格だった
まあlaravel制アプリも結局設定変更レベルで合格になったけどsymfonyは確かにデフォルト設定のセキュリティレベルがlaravelより高いような感じ >>363
> Json形式でレスポンスで返すバックエンド
あれ、結局サーバー→クライアントの通信の話なの？
ユーザー入力をサーバーサイドでパースするのが問題だっていう設定どこに消えたのw >>363
> jsonハイジャック
急にクライアントの話になってて草
それとも>>363が作ったアプリではphpからjavascriptを動かしていたのだろうか >>363
laravelとsymfonyで全く同じアプリ作ったの？
同じアプリ作る意味が分からんけど、フレームワークが異なれば実装も異なるんじゃないの？
実装が異なるのにフレームワークの責務と言い切れるの？
すっごくシンプルなアプリならともかく、php製のjavascriptクライアント作っちゃうくらいだからやっぱりフレームワーク関係ないのでは？
しかもツールによる診断項目ってポートスキャンとかに限られてるだろうし、せいぜいインフラ構成くらいしか診断できないでしょ。 JSON危険おじさん、嘘を見破られてまたまた論破されてしまう。 >>364
すまん俺はその人ではない
>>365
phpのv8js使って色々やってます
>>366
自分の所は毎回laravelとsymfonyの２種類で同じアプリを作成し、その時点で
一番脆弱性が少ないフレームワークを本番環境にリリースする形です
まあ会社の方針ではなく顧客の入札仕様に入っているのでしょうがないんです（；ω；）
チェックツールについてはポートスキャンだけじゃなく画面で自動入力したり不正なリクエスト送ったりする
テストツールがあるんでそれ使ってました富士通製とNTTデータ製の２ツールで毎回テストやってます v8jsってなんだよｗｗｗって思ったらマジであるのかｗ ここまでの結論としてはjsonに脆弱性はないけどcsvにはあるということでＯＫ？ 正直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の脆弱性について質問してこいよ
これで決着つくだろ 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チュートリアルって何？ めずらしくこのスレ議論が白熱しているな
いつもこのぐらい白熱していればいいんだがな >>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を返すだけなのでフレームワークの相性は関係ない >>447
全然違うだろ 仮にapiサーバとして動かす場合はLaravelが一番優れている
他フレームワークと違って細かい制御が可能になる webpackを自分でセットアップしなくて済むのはビギナー的には大きい >>450
LaravelMixのこと言ってる？
あれ独立して使える時点でLaravelとの相性は関係なくないか？
そもそも言うほどwebpack自分で設定するか？
vue create か create-react-app コマンド打つだけで雛形用意されるし、そこから追加の設定が必要ならLaravelMixでも変わらない。 >>452
でもそれバックエンドとの結合テストでデバッグする際に毎回サーバーにdistのjsをコピーするって事っしょ？ >>455
ごめん、24歳保育士の彼女と電話してた やめたれｗｗ
>>455だって彼女ぐらいいるよ・・ >>455
つまりLaravelはフロントフレームワークとの相性がかなり良い
他フレームワークと違って細かい制御が可能でビギナーにも優しい >>458
24歳保育士の彼女との電話がなりすましってことは
彼女いるのは嘘なんですか（；ω；） >>460
彼女どころかすでに結婚してるから
ちなみに俺フェラーリに乗っていてコロナ自粛前は
毎日スポーツジムに通ったり映画館や近くの高級店で優雅な朝食を
食べたりしていたな ごめんねレベルが違う話しちゃって 結婚しているはまあいいとして
普段の生活情報いりますかね？ >>465
具体例出せって言われてるのいつ理解するの？ >>462
なんか一般人が必死に考えた金持ちのイメージって感じなんだけど・・・・ HTTPメソッドの使い分けはその操作が安全であるかどうか、べき等であるかどうかで判断するのが原則。
安全→サーバ、特にDBなどの状態を変化させないこと
べき等→その操作を何度行っても結果が同じであること
検索のような安全でべき等な処理はGETが推奨。
要はGETを使う場合はブラウザ側でキャッシュしても問題ないようにしておいてねということ。
POSTはリソースの新規作成など安全でもなくべき等でもない操作に使う。
ただし、クエリパラメータに出したくない項目がある場合や、検索項目がとんでもなく多くてURLが長くなる場合などに、安全でべき等な操作であってもPOSTを使わざるを得ないこともありうる
GETであることの他の利点は、Google検索のようにURLだけでそのまま検索結果の表示ができること
つまりjsonだけで行う通信は脆弱性があるということ × つまりjsonだけで行う通信は脆弱性がある
○ 話は変わるがjsonだけで行う通信は脆弱性がある >>470
× つまりjsonだけで行う通信は脆弱性がある
× 話は変わるがjsonだけで行う通信は脆弱性がある
○ つまりどんなプロトコルだろうとPOSTのような処理には作り方次第で脆弱性を生むリスクがある ①edit画面が呼ばれ、DBから初期データ取得してフォーム要素にセットして表示
⇒ この画面で編集されて[確認]ボタン押されPOST送信される
②confirm画面が呼ばれ、フォームデータを取得しバリデーションして以下２通りの処理に分かれる
その１) ⇒ バリデーションＯＫの場合、確認画面を表示。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 Oracle「Laravelもボクが管理するよ」
ってなったら終わりだな FormRequest使うと入力エラーだと入力画面に戻ってoldで入力値が取れるけど、その時にFormRequest内で入力値に追加することってできないのかな
やりたいことは画像アップロード付のFromでエラーで戻った時に正常にアップロード済みの画像は再選択しなくてもいいようにしたいです
画像でエラーが出た時はもちろん再選択でいいです
なので入力エラーの時は入力データに別のキーでアップロード済み画像のフルファイル名と元ファイル名を持たせようかと思ったんだけどうまくいかない そういう用途用のlaravel用ライブラリ誰かが作ってた気がするけど
ライブラリ名が思い出せない すまんな >>477
画像ファイルそのものをpostするのではなくbase64エンコードした画像をpostしちゃえば、ただのstringのやりとりだし簡単に解決じゃね？ つか最初からSPAならそんなこと悩まなくて済むのにね。 こういうのがいるからセキュリティリスクを生むんだよな >>481
SPAだのjsonだのbase64だの言ってる情弱共は脆弱性の「ぜ」の字も知らないんだろうね
何が脆弱なのかも分かってないから「根拠ガー」って連呼するしかできない 設計レベルの質問でないのに、すぐSPAにしろとか回答するのは傍から見てもムカつくよな。 >>483
いつまでふんわり指摘俺カッケーやってんの
具体的根拠が示されないまま進むふわふわ議論を良しとする考え方の方が危険だわ お前らってJavascript側ではバリデーションやって、
サーバ側ではバリデーションやらないという片手間落ち実装してそう
ちゃんと両方に実装しなきゃ駄目daz
dareka zenkakunyuryokunimodosuhouhouwooshietekudasai >>486
何言ってるの。SPAにすればすべて解決するのに。 SPAはLaravelとの相性がかなり良いから正直バリデーションもあんまりしなくて良いとも思う バリデーションないアプリとか怖すぎてリリースできねーよ >>486
まさかいまどきサーバーでバリデーションしてるの？ 確かにフロントとバックのバリデーション分担って悩ましいよね
結局のところどっちもやるべきなんだと思うけど
最近昔のシステムの改修しててソース見ると
フォームポスト
↓
バリデーション→確認画面表示
↓
バリデーション→本登録
みたいになってるけどこの二回は流石に要らんだろと思って
一回目のバリデーション通ったらその結果をセッションにぶち込んで二回目のところはセッションから取り出した値そのまま通すことにして
UI側にアクティブなバリデーション入れた
画面遷移の確認→確定シーケンスは保持
ただ確認画面はページは遷移せずにDOMの表示切り替えにした
VueとかReactみたいなハイカラなもの使いたいけどまだ実用できるレベルじゃないから勉強中で悩ましい どんなにJavaScriptでガチガチにバリデーションしてもセキュリティ考えると結局サーバーサイドでバリデーションしないといけないのは変わらないしな
ユーザビリティとしては一旦JavaScriptでバリデーションしてエラー出した方がいいけど、バリデーション処理が2箇所になってメンテナンス性が悪くなる 早い時点でチェックすればいいんだから、クライアント側でやっておけばいいじゃん セキュリティ面の考慮を除いても、DBが必要なバリデーションがあるだろが（Uniqueとか）。
フォーマットチェックだけならJSで済ましてもいいけどさ。 JSON君に倣って冗談で>>492書いたつもりだったのにマジでサーバーでバリデーションしてないやつがそこそこ居て笑えないわ JavaScriptでまずバリデーションして要件に満たないものは弾いて送信処理ぜずにエラー処理でいいんやないの？
どうしても送信先でバリデーションしたいんならXHR通信(ajax,axios)使って飛ばした後結果次第でエラー表示するか
成功したらリダイレクトでどっかに戻すかすればいいじゃん >>498
セキュリティ意識が高いだけJSONおじさんのほうがまし。 セキュリティ意識が高いのではなくもはやスレを荒らしたいだけのようにしか見えないがな application/json はバリデーションが必要
x-www-form-urlencode はバリデーション不要
って認識だからなぁ
セキュリティ意識高いだなんて笑っちゃうよ >>498
クライアント側でしかバリデーションしていない業務システムを見たことあるなぁ
世の中のシステムには当たり前ができていないものがめちゃ多いので
あながち冗談って言い切れないのが怖いところ >>503
不要なんて言ってないじゃん。JSONがより必要。 >>499
ユーザーがブラウザからソースいじって勝手にフォーム書き加えたり、ブラウザのスクリプトオフにしたり、フロントのバリデーション通さずに送信するなんてかなり容易だと思うんだけと >>505
で、より必要になるバリデーションとは？
と聞くと逃げる模様 >>507
だから、POST値の項目改ざん検知だって。
きちんとフレームワークで保証されてるならいいけど、そうでないならきちんと自前で実装すべき。
言っておくがJSONとかフォーマットに限らずだぞ。
これは設計次第だから、実装者がきちんと判断できる実力を持つべき話だ。 >>509
>JSONとかフォーマットに限らずだぞ
Jおじ君、自分でJSON固有の話ではないと認めてしまった。 >>511
>>505 で「JSONはより必要」と言ってるよ。
お前 >>505 じゃないの？
同じ人なら矛盾するし、別人ならせめてまともな回答してくれ。
あとこのスレを JSON で検索しろ。 509=297な。
なりすましが多くてわかりづらいわここ。 どうしてJSONだとバリデーションが“より”必要なの🤢 だからJavaScriptでまずバリデーションして要件に満たないものは弾いて送信処理ぜずにエラー処理でいいんやないの？
どうしても送信先でバリデーションしたいんならXHR通信(ajax,axios)使って飛ばした後結果次第でエラー表示するか
成功したらリダイレクトでどっかに戻すかすればいいじゃん >>513
例えば、ネットショップを作るとする。
公開画面でユーザが買い物をする。
管理画面で注文について管理する。
当然双方での料金の計算ロジックは同じではなければならないから、
モデルに相当するものは共有したい。
どうするつもりか教えてくれ。 >>519
どうするとは何に対してどうって聞いてるの？
モデルを共有するかどうかという質問？
モデルを共有したいのだから共有すればいいじゃん。
で、JSONの脆弱性についての回答はまだかな？ >>520
Validationと脆弱性がなぜつながるのか教えてくれ namespace分けろよ
\App\Models 共通のモデル
\App\Frontend\Http\Controllers
\App\Admin\Http\Controllers
こんな感じで別々にするんだよ。
間違っても App\Http\Controllers\Admin,Frontend にするなよ。 jsonがどうとか他でやれ。Laravelの話から 逸れてるだろうが。 >>523
>>505でも言ってるようですがJSONがより必要なのはなぜですか？ >>524
俺、本当のことを言うと505じゃないんだわ(まさか本当に505と思われているとは)。
もう飽きたから次の話題行ってくれ。 >>525
飽きたからとか言って誤魔化すなよｗ
早くjsonの脆弱性とやらを答えろよ もしくは自分の負けを認めなさい >>521
Jおじさぁ…話の流れ分かってないならスレ読み返そうよ。
>>270 あたりから読み返してね。 勝ち負けっていうかJSONの脆弱性について知識の為に聞きたかったんだけど、Jおじによる妄想だったならもうそれでいいか。 お前達はなんでそんなフレームワークを使っているんだ？
修行でもしているのか？ LaravelはJSONを返すAPIに特化させて外観はフロントフレームワークで書いた方が絶対いい laravelがphpとjavascriptを
縦横無尽に使える両刃の剣と聞いたんだけど
web.appからアクションindexを呼び出して、
「$this->name=文字列」をいれたら
アクションwriteの$this->nameが別のモノに
なってるとか、オブジェクト指向としてオカしすぎる。
---MainController.php---
namespace 略
use Illuminate\Http\Request;
class MainController extends controller{
public function index(){
$this->name="TAROU";
/*処理A*/
}
}
class public write(){
$who=$this->name;
/*処理B*/
}
}
---wep.app---
Route::get('/test','MainController@index');
Route::post('/test','MainController@write'); > laravelがphpとjavascriptを
> 縦横無尽に使える両刃の剣と聞いたんだけど
LaravelはJavaScriptフレームワークじゃないよ。
LaravelMixのこと言ってるならあれは関係ない。独立したプロダクトだし、ただVueの初期設定を簡単にするためのパッケージでしかない。
それで、貼ったコードはjavascript関係ない。
しかもその文法もおかしいし。
何を主張したいのかよく分からない。
> オブジェクト指向としてオカしすぎる。
お前に跳ね返ってきてんぞ >>532
お前まさか$this->nameがローカル変数と思っていないよな？
MainControllerクラスが持っているインスタンス変数だぞ もしかしてindexでTAROUって文字入れてるのに
writeではnameがnullになっちゃうよってこといいたいのか？ >>532
う～ん、確かに、オブジェクト指向としてオカしすぎる。かも。 ブート中ではなく、ブート後のログインIDとパスワード入力中のタイミングで
laravelのリクエストをシャットダウンしその後systemctl restartを実行する方法はありますか？ >>539
> ブート後のログインIDとパスワード入力中
何をブートした後の話？
何のログインIDとパスワード？
多分その質問はLaravelと関係ないと思うけどphpのプロセスを終了させたいなら ps aux | grep php でプロセス番号調べて kill コマンドで終了させたら良いんじゃない？ .env.exampleを.envにコピーする拡張プラグインがgithubにあってワロタｗｗｗ
プラグイン使うほどじゃないだろｗｗｗｗ 実況者の加藤純一がlaravelデビューしたせいで
このスレの勢いが熱いな すみません自分も今日Laravelデビューしたので質問させてください
環境はUbuntu20.04でPHPは7.4を使用しております
composer create-project laravel/laravel sample
を実行するとsampleフォルダにlaravelのプロジェクトが作成されます。
この状態でsampleフォルダに移動してphp artisan serveを実行し
psコマンドでプロセスを確認するとphpプロセスが数えただけで27個動作しているようです
これは正常なんでしょうか？それとも異常でしょうか？ >>543
異常っぽいね。artisanで建てたサーバー止めるとプロセスどうなるの？（= Laravelに起因してるの？） >>545
laravelとは関係ないフォルダでphpのビルトインサーバー立てるとどうなるかも確認したほうがいいね。
artisanのサーバーもビルトインサーバーだし。
php -S localhost:8000 >>518
こういうやつがJおじを生み出してしまうんだろうな
API直接叩かれたらどうすんのさ >>548
俺は負けを認めただけで謝ってねーよ
文句あるならお前があいつらを論破しろ >>548
そもそもお前らがjsonの話題を振ったことが悪い
そのせいで俺が恥かいて最終的に負けを認める形になってしまった
お前らも論破できないなら負けを認めろ しかしjson脆弱君は会社でも同じような事言って他の社員困らせてるのかな >>553
json脆弱君はお前だろ 名前欄の528取れてねーぞ 自演失敗乙 全部自演かよw
脆弱性あるといい、証拠だせといい、頭の中がjsonでいっぱいなんだなw >>555
全部自演にして逃げるのは苦しいだろ
多少自演はあっただろうが、何人かはネタ抜きでJSON脆弱説を唱えてたぞ >>556
ネタ抜きとじゃなくて本気だから
JSONの脆弱性知らないとかお前らってちゃんとセキュリティ勉強してる？ jsonはフォーマット自体に脆弱性がある
だから最近のWEBアプリはjsonを使わない実装が主流になっている 自演は要らんし、Laravelの話題からも外れてるだろ。
いいかげん他所でやれ。 未だに相手してるやつはJおじも根拠おじも両方荒らしだぞ >>561
Laravelはjsonの処理で不正スクリプトを実行されやすいから無関係ではないだろう お前らってLaravelでバッチ処理作るときってどうしてる？ 使ってないけどそういう機能Laravelにあるらしいね バッチはLaravelで作らない
バッチだけFaaS使うよ すみませんLaravelについて質問させてください
php artisan serveで開発用サーバを立ち上げてWEBブラウザからアクセスした場合は
PostgreSQLに接続できるのですが、Apacheに配置してWEBブラウザからアクセスした場合は
PostgreSQLに接続できなくなります。これは何が原因でしょうか？
OSはCentOS8を使用しておりSELinuxはdisabledになっております。
またファイアウォールを止めたりPostgreSQLやApacheの再起動等も試してみましたが
状況が変わらないです 接続できないってのが抽象的すぎる。
せめて該当のログ貼りなよ。 >>567
実行ユーザの違いだよな、接続方法はTCP？unixソケット？
あるいはそもそもアクセス権で.env読めないとかだったりして。 >>567
・artisan serve のLaravelからアクセスするDB
・apacheのLaravelからアクセスするDB
↑この2者は同じなの？違うの？
つーかなぜログを貼らないのか。 ログ貼れとか言ってるやつ初心者すぎないか？
artisan serveでは接続できて、apacheでは接続できないって
どう考えても原因一つしかないじゃん >>567
その前にパスに/publicが必要とかいうオチはないよね？ >>571の言う通り原因は１つしかない
そして開発サーバでつながるけどapacheではつながらないってlaravelの有名な
トラブルだから質問者もちゃんとぐぐってないんだろうな composer create-projectでlaravelプロジェクト作ったら.env.exampleが見当たらないんだけど
もしかしてlaravel7で何か変わった？laravel6だとちゃんと.env.exampleがいるんだけど >>574
ごめん繋がらなかった事ないからその一つ全然分からんわ
少なくとも>>567はSELinux無効にしてるって言ってるからマジ見当付かない 多分apacheユーザから.envが閲覧不可な権限になっているはず
試しにsudo chmod a+r .envのコマンドを実行してみてくれ >>577
嘘っぽくてすまん、俺は荒らしじゃないし本当なんだ
大分前にそれのissueが上がっててそれに対するプルリクも出されたんだが却下されてたのは見た
そのissueとプルリクのURLは失念してしまった すみません解決しましたdnf check-updateを実行したところ
apacheのアップデートが来ていたのでそれを適用したら
繋がるようになりました みなさんご指導いただき(人''▽｀)ありがとう☆ございました >>577
自分の技術レベルではわからないことが起きたからってすぐに荒し扱いするのは良くない ケチくさいジジイどもが勘違いした返答ばかりのゴミスレだな ララ帳とかのLaravelのチュートリアルとかやり始めて疑問があるんだが
Controllerはapp\Http\Controllers直下に配置されるのに何でModelは
app\Modelsではなくapp直下なの？
もしかしてLaravelに限らずModelは専用フォルダを作成しないという方式が
一般的な構成なのか？ >>583
それについては >>228-232 あたりで出てるね 最近Laravelでアプリ作ったけどうんざりしたよ
フレームワークの設計ひどすぎるでしょ
特にLaravel7は未完成で何度も後方互換性のないAPI変更を繰り返してる
それに比べるとSymfonyの設計ってとても良く出来てる
新API追加に慎重に検討しているのも無駄じゃないんだなって DB::selectするとき、第2引数を文字列の配列にしてるけど文字列と認識されないでクォーテーションがつかずエラー吐く時がある、変数を型指定したほうが良いのかな？ jsonに含みたくないカラムが含まれてしまいます。
->join()でテーブル結合したあと特定のカラムを削除する方法とかjoinで特定のカラムを無視する方法ってありますか？
テーブルのモデルで$hiddenは設定しています。 >>588
selectで指定すればいいんじゃない？
'メインのテーブル名 . *', 'joinで追加したテーブル . 追加したいカラム'
みたいに でもselectで指定するとjoinってできなくないですか？ >>589
->join('追加するテーブル', 'users.id', '=', '追加するテーブル.user_id')
->select('users.*', '追加するテーブル.body')
とするとできました。公式ドキュメントの読み込みが足りなかったです。
助かりましたありがとうございます。 まず、SQL文を理解しろ。
Laravelしか出来ない人間になってしまうぞ。 >>594
ドキュメントの読み込みってよりもSQLに対する根本的な理解不足だよ DB::selectをDBのコネクション用に使って後は素のPDOを使うという手法に落ち着いた >>601
でもjsonだと脆弱性があるのでxml使ったほうがよくないですか？ 昨年5.8で製品リリースして以来久々にLaravel案件来たが今7になってんのか…
やはり最新版を使うべき？ >>603
7はマイナーバージョンアップでの変動激しいからよっぽどのドMとかじゃない限りやめといた方がいいと思うよ
6がLTSだったはず >>606
lts以外だとjson関連の処理で何か脆弱性があるんですか？ >>610
このスレでjsonについて何か言ってる人はほぼ荒らしと見て間違いないから当てにしないほうがいいよ いやいやｗｗ
WEBアプリでjsonってもはや必須だろｗｗ
それなのにjsonについて何か言ったら荒し扱いとか酷すぎるｗｗ 以前jsonに脆弱性があるって言ってきた方がおりまして・・・・
その人にどういう脆弱性なの？って聞いても全然答えてくれなかったんですよ jsonは扱いを間違えると不正なデータをぶち込まれやすいフォーマットだからな
XMLのほうがまだ不正なデータはぶち込まれにくいかもしれない >>613
スレ全部見たら分かると思うけど荒らしってのはjsonを異常に敵視してるやべーやつのことな そもそもLaravelのスレでXMLなんて話す価値が無いやろ 9月上旬にLaravel8がリリース予定らしいですが、これはLTSになりますかね？ >>621
そうなんですね…
ソースありがとうございます！ Railsやアクティブレコード系の
フレームワークって
DBとガチガチに蜜結合しててやりにくいのと
「webアプリはこういうものだ」っていう
狭い視野の世界をフレームワークが勝手に決めつけて
その狭い世界だけのアプリしか作れない。
その決めつけの範囲外の特殊な事をやりたくなったり
画期的な事をやろうとするとめちゃくちゃやりにくい
Wordpressは「ブログを作る」
という目的に世界を限定してブログをつくるための
機能だけをしこたま提供してるけど
ブログ以外のものは一切作れない
Rails系のフレームワークも同じ
「Rails系のアプリ」しか作れない
Expressとかはそういう決めつけが一切なくて
自分で自由にSQL構築して好きなように
DBいじれる
まずDBのテーブルと対応した
モデルクラスをいちいち全部作るのが
最大の無駄 何でLaravelのスレで意味不明な事を言っているんだろうかｗ >>532
アクションごとにcontrollerは別のインスタンスになるよ >>627 はスクリプト終了時にインスタンスは消えるよって言いたかったんじゃない？
その場合はどう実装するかじゃないでしょ
スクリプト終了時にインスタンスが消えるのは言語仕様＝スクリプト開始時に別のインスタンスになる Laravel8、LTSじゃないけどjetstreamかなり良いみたいだから気になるわ。
tailwindCSSとLivewireで動くユーザー認証系が最初から用意されてる。 Laravel8はついにモデルの置き場所がapp/Modelsになるみたいだな >>633
laravel4の時代に回帰したってとこだね。 9月8日リリースってなってるけどもしかしてこれってUTC基準か？ Laravel8使ってみたけど結構いいね
これLTSではないのが残念無念 >>644
分かるわー。今回は実務で利用頻度高そうな機能の追加&改善だからな。 お前らさっそくlaravel8でtodoアプリづくりか？ Laravel8最高すぎてワロタ なぜLTSじゃないのかが悔やまれる 確かにどうやってLTSかそうでないかを決めるんだろう >>651
そうだよ。LTSはバグフィックス2年、セキュリティ3年のサポート期間を設定しているので、前者の2年がLTSリリースの周期となる。
前回のLTSはバージョン6で2019年9月リリースだから、次のLTSは2021年9月だろうね。 おまえらLaravel8でjsonのサポートが強化されたぞ マジだjsonの変換にラムダを使えるようになってるね 質問です。wordpressとlaravel、どちらのほうが世間の需要は多いですか？
親が「wordpress勉強するよりlaravel勉強したほうがいい」ってしつこいです。
ぱっと見た感じlaravelよりもwordpressのほうが圧倒的に需要が多そうに見えます。
クラスの友人で直phpとwordpressを使ってる人はいますがlaravel使ってる人は皆無です。 勉強の目的によるだろ
wordpressはブログのテンプレート
laravelは汎用フレームワーク と思ったけど学生か？
卒業後の職を探してるなら断然laravelだし、
素人がブログ作りたいだけなら断然wordpressだ。
もし職を探してるならクラスメイトに聞くよりも求人サイトでlaravelとwordpressの求人数や条件を見比べてたほうが圧倒的に良い
勉強に限定するならlaravelを見倣いながらオレオレフレームワークを作るのが一番良い アドバイスありがとうございます。
wordpress→機能が限定的、laravel→かなりなんでも作れる
ということがわかりました。親も嘘は言ってなさそう、ということがわかりました。
>>657
>勉強の目的によるだろ
勉強の目的はwebサイト作りです。
管理画面つきのwebサイトや管理画面をカスタマイズできるBLOGを作りたいと考えていました。
>と思ったけど学生か？
はい。卒業後は就職ではなく専門学校か大学に行きたいと考えています。
職探しはもう少し後になりそうです。 Laravelのメリットとデメリットを教えてください。 >>660
PHPを前提にしてたメリデメてことかな？wordpressやPHPの他のFWとの比較。
メリット:
セキュアなコードが自然と書ける
日本語情報が多い
ユーザー認証のスカフォールドが提供されており、認証が必要なサイトの開発が始めやすい
パッケージが豊富でwebの殆どのユースケースに対応していてフルスクラッチでの開発の機会が減る
フロントエンド開発との相性が良い
デメリット
メジャーパージョンアップで破壊的変更が入りやすい
情報商材系の変なグループのカモにされやすい
パフォーマンスチューニングしないと捌けるリクエスト数が少ない wordpressは手っ取り早くブログ作る分には良いけど、作りがレガシーすぎる（手続き的すぎる）し、バージョン管理との相性悪すぎ。
なによりhtmlの中にビジネスロジック入れるような書き方に吐き気がする。
素人向けに作られてるからある意味正解なんだろうけど。 >>661
Laravelって捌けるリクエスト数少ないんだ
何もチューニングしないと最大リクエスト数どのぐらいですか？ >>663
作るものによるので何とも。「laravel 遅い」とかで検索してみてくれ。ただOPcache使えば、不満はほぼ無くなる。 大体N+1をやらかしているからのような気がする遅いのは >>665
さすがにそんな雑魚は稀。↓だとOPcacheの有無で捌けるリクエスト数が5倍以上違ってる。
https://qiita.com/ucan-lab/items/850bfd3afd3cc0fff60f
海外だとフレームワークごとのパフォーマンスをいくつかのユースケースで測定した結果が公開されている。
https://www.techempower.com/benchmarks/#section=data-r19&;hw=ph&test=fortune&l=y451q7-1&c=6&f=0-bam8-4fwb9c-27wr74-4fti4y-13ydj4-b8jk-2ubk-4-0-0 でもPHPフレームワークだったらLaravel一択だよね
それともSymfonyやCodeigniter4のほうがいいのかな OPcacheでチューニングすりゃ遅い部分はカバーできるから、変に他のフレームワークを使う必要は無いぞ。 >>672
できるよPHP8でLaravel動かしたらさらに早くなるぞ
これで証券取引所でも安心して使えるね（＾ｖ＾） 実際Todoアプリですら他のフレームワークに比べて遅いからな
さすがにTodoアプリ程度だと数百ミリ秒単位の違いだけど >>675
てっきり初期化までのオーバーヘッドの時間が遅いと思ってたんだけど、アプリの規模関係あるの？ 論理ーうるふうううううううううううううううううううううううううう！！ よっぽど要求が極端なもの以外ならLaravelで問題無いと思うけどねぇ
開発効率を重視したいし Laravelに限らずインタプリタ言語全般に言えるけど管理画面や業務システムのような、アクセス数が限られているようなサイトでしか使わない。
インタプリタは遅いから。 >>680
いつの時代の常識ですか？今２０２０年だぜ >>683
PHP < ば、バージョン8からはJIT使えるようにするから、それまではOPcacheで許して？ laravel 8から入った初心者なんですけど
laravel 7の本を購入したらはまりますか？ >>687
laravel8からはかなり色々変わってるからなぁ。個人的には7で環境作っておおよそのこと学び終えてから、8にした方が良いとは思う。 基本的な事は変わらないし、変わったところなんて初心者なら尚更使わない事が多いので
別にLaravel7の本で十分だよ >>689
laravel8インストールして試してないやつが妄想で言うのやめろ。modelの場所も変わったし、ルーティングの書き方も終わったのに、基本的なことは変わらないて言うのはアホすぎる。
そもそもlaravelの公式がメジャーバージョンは、毎回破壊的変更が含まれるって言ってるのに基本的なことは変わらないとか無責任すぎるわ。 その程度で変わったとかｗ
ドキュメント読めば直ぐ分かるレベルだろｗ
論外過ぎるｗ >>692
相手は本買うか悩んでるレベルの初心者やぞ？その程度とかw
しかもお前、バージョン8のドキュメント読まずに変わったところなんて初心者が使うようなところじゃないとか大嘘ついてるじゃん？
そんなお前がドキュメント読めばすぐわかるレベルってどの口が言うんだ？
説得力なさすぎ。
ちなみにルーティングの実装変わったせいでエラーに悩まされてTwitterやqiitaで悲鳴あげてる奴ら何人も居たぞ。
論外なのは明らかにお前だわ。こっちはバージョンアップのたびにドキュメント確認してるんだよなぁ。お前と違って。 >>692
初心者相手にドキュメント読めば大丈夫という回答は頭おかしい
お前素人か？ 質問者がここで聞いている以上はModelsの話はここで説明した差分を考慮すればいいだけでは？ >>696
この問題の発端は>>687の初心者からの質問に対して、>>689でドキュメント全く読んでないことがバレバレのクソ雑魚なめくじが、知ったか炸裂させたことだぞ。
ゆえにそのレスはズレてるんだわ。横レスするならコンテキストをまず理解しような。 >>696
しかもそれに対する言い訳と思しき>>692の見苦しさたるや。
自分がドキュメント読んでないのに他人(しかも初心者)には「ドキュメント読んだらわかるレベル！論外！」とかキチガイすぎてビックリするわ。 別にドキュメントなんて読まなくてもModelsの位置が変わってるけどそんなに大きな変更はないよって事でよくない？
なんでイチイチそんな下らない事でドキュメント読めとかの話になるのか甚だ疑問 >>699
お前は日本語読めないの？ルーティングの仕様も変わったて書いてあるよな？laravelのドキュメント読んでるやつならそもそもそんな間抜けな回答しないと思うんだよね。素人くんかよ。
それに俺はlaravel8ではなく入門書に合わせて7を使えって回答なら文句ないんだわ。
せめてlaravel8でも問題無いか？て質問されたら、回答者は7と8の差分をドキュメント読んで把握してから回答すべきでは？ 8を勉強したい初心者に、結構な差分のある7のドキュメント薦めるとか、どう考えても鬼だなw >>701
話逸らすなよ、お前が日本語読めないバカでさっきからズレたレスばっかりしてることに、いい加減気づいてくれ。 >>701
あとアスペのお前に説明してやると、>>687はlaravel8から入った初心者と書いているだけで、laravel8を勉強したいなんて一言も言ってないぞ。
おそらく最新バージョンが8だから、そのバージョンしか使えないって思ってるだけだろうね。 >>703
8の勉強をするのに、7のドキュメントで代用できるか、と聞いてるんです なりすましが出そうなので・・・
勉強をしたいのはLaravel7です・・・ 質問するときはなりすまし防止のためにIDを出すのが普通だぞ
今更後出しで>>705や>>707のように後出しされても
なりすましとしか思えない いずれにせよ問題なのは、>>687はlaravel8から入ったとしか書いてないのにlaravel8を勉強したいに違いないて決め付けているアスペのカス。 改めまして
laravel 8から入った初心者なんですけど
laravel 8を勉強するにあたり
laravel 7の本を購入したらはまりますか？ >>705
仮に本人だとして。勉強したいのは7でもなく、laravelそのものでは？laravelバージョンにはLTS版とそうじゃない版がある。
LTSのほうがサポート期間は長い。最新のLTS版は6であり、7や8と比べてサポート期間は1年以上長くなる。
なので、本当は6の入門書を買って勉強するのが1番良い。
バージョンは何も指定しなければ8が入るけど、composerから7や6を指定してインストールは可能だからあえて8で頑張る必要は無い。
composer create-project laravel/laravel プロジェクト名 --prefer-dist "6.*"
こんな感じで行けるはず。 すみません。書き込みは>>687だけです。
今後も書き込みはしませんので偽物は無視してください。 あとすいません。
インストールされているのはlaravel 8です。
本を読んで学習したいのですがlaravel 7までの本しかなかったのでそれで大丈夫か不安な思いから質問させていただきました。 書き込みはこのレス合わせて4レスのみです。
後は偽物です。
レスは全部読んで参考とさせていただきました。 今のプロジェクトv7で作ってるからリリースされてから久しくスルーしてたが
そんなに違うんならちゃんと調査せんといかんな この中に例のアスペがなりすましたものも含まれているとしたら、だいぶキモいな。 つか7をインストールし直さないで、あえて8でやることの是非を質問したのってなんで？
「あ、本は7に対応してるのかー、じゃあ7をインストールし直そう」ってなるのが自然な気がするんだけど。
なにかしら8でやりたい理由があったんだろうけど、それを否定して「7でやったほうがいいぞ！ドキュメントなんてお前にはまだ早い！」だなんてネガティブすぎるし、その初心者に失礼だと思うわ。
（非公式だけど）丁寧な日本語ドキュメントもあるのに、それを読ませることすら否定するのは異常だし損だと思う。
>>693で親切にURLすら張られてるのにね。
つまり、その初心者が8で初めて結果躓いて、ドキュメントやstackoverfloxなりその他ウェブで調べてみた結果、どうしても解決しないなら7でやり直してみればいいじゃん。
実務じゃないんだろ？勉強ならそれでいいだろ >>717
laravel8から入ったとしか書いてないのに、8を勉強したいんだて決めつけているアスペはそろそろ消えたら？
初心者なら、laravelセットアップしたら最新版=8になるという程度の認識だろうよ。 >>717
あとこれの問題は>>697が全てだから。アドバイスする側が8のドキュメントも読まずに、「変わったところなんて初心者が使わないことが多いので」て大嘘ついたこと。
んで、そんなクズが初心者には「ドキュメント読めばすぐ分かるレベルwwそれで分からないのは論外www」とか言っちゃうというね。 >>717
一連の流れみてて、なんか違和感あると思ったらそれだ
初心者がドキュメントなんて読んでも理解できるわけないって決めつけてるところだ
確かにドキュメントを目次から全部読むのは難しいとは思うが、今回はそうじゃなくてアップグレードガイドかリリースノートを見るだけだからな
なんにせよ無理と決めつけてる意味が分からない >>720
そのアップグレードガイドやリリースノートすら見ないバカがアドバイスする役割を担おうとしていることがまず問題になってるんだが？
経験者すらちゃんとドキュメント読めてないのに、なぜ初心者は読んだ上で正しく対処できると信じられるの？ >>718-719
いやいや、質問者が8を選んだ理由を決めつけていないし分からないよ。
だから「なぜ7じゃなくて8なのか？」と質問したんだよ。
このスレで質問するというアクションに至ったのだから、なにかしら8を選ぶ理由があると思うんだよね。
「本に書いてあるインストールコマンド叩いたらデフォルトの8がインストールされた。7をインストールし直すのも面倒なので8でやる。」
というのも理由として十分だと思うよ。
> あとこれの問題は>>697が全てだから
全てでは無いと思う。
「マニュアル読めば分かるんだから8でやればいい」
「マニュアルは難しいから7でやればいい」
というアドバイスもそれぞれ立派なアドバイスであって、
「一旦8で初めてみて、躓いたらマニュアル等で自分で調べてみる。どうしてもダメなら7でやり直せばいい」
というアドバイスがあっても良いはず。
> 8を勉強したいんだて決めつけているアスペはそろそろ消えたら？
そろそろも何も、俺は717のレスが今日初めてだ。
否定すべきことがあれば俺のアドバイスに向けるのが建設的だと思う。俺の人格を否定しても意味が無いんじゃないか？ 皆さん議論しているところ申し訳ないのですが
自分が勉強したいのはLaravel7です。
Laravel8勉強したいって言ってるのは全部なりすましだと思ってください Laravelに関してはLTSを選んだとしてもあんま恩恵ないと思うんよね
過去に5.5で作ったのとか全然LTSの恩恵受ける間もなく気が付いたらサポート期間終わってたし >>723
まず>>687からの流れを一通り読んでほしいのだけど、アドバイスはそのあとの2つのみだ。
1つは、8は結構な変更が入ってるから7でやれ
もう1つは、8は初心者に影響する変更なんてほぼ無いから気にせず8をやれ
これに対して後者はそもそも嘘である、という批判をしたのが発端。
で、それに対してズレた反論としてドキュメントよめば分かるじゃんというのが投稿された。
「初心者に影響する変更なんてほぼ無い」は偽であるて話なのに、ドキュメント見れば大丈夫て意味分からないだろ？
更に言うと、こいつらは間違いなくドキュメントなんてまともに読んでいない。なぜなら、>>690では初心者に影響する変更は2つ挙げているのに、その後の反論ではmodelsの変更だけしか論じていないからだ。
結論としては、「アドバイスするなら8にどんな変更が加わったかを把握している人間がやるべきだ」ってだけ。これには同意できるだろう？流石に。 俺は別の初心者だけど、なぜ大きな変更があると判明してる8が出たあとに、先に消えゆく7で勉強するのか意味がわからない。
可能なら最新のを使って勉強したいわ。 Laravelだけの初心者でプログラミングに関してわりとベテランならそれでもいいだろうけど
トータルで初心者だとマニュアル通りにいかないのは結構大変って事じゃない
昔Railsの環境を構築しようとしたとき結構苦労した事を思い出したがインフラド素人にこれ構築させるのは絶対無理だろうなって思った >>727
今回に限っていうと、7向けに書かれた書籍を活用したいという前提があった >>727
それなら8対応した入門書出るまで待てとしか。それが嫌ならlaravelで実開発やってるエンジニアにメンターついてもらえ。 とりあえずここは役に立たないとわかったのが一番の収穫でした。
日本語が通じないんですもの。 >>730
なぜ入門書orメンターが必要という前提なのか >>732
初心者だから。公式のマニュアルはrailsと違ってチュートリアルが用意されているわけではない。点の情報を線にするのはそれだけ時間と労力が要る。
その時間と労力は、少なくとも初心者が支払うには見合わなさすぎるし、下手するとベストプラクティスとは程遠いものができてしまうから。 >>733
入門書やメンターが無くても理解できる初心者だっているだろうに、なぜ 727 においてはそれが必要だと決めつけるんだい？ 俺は初心者だったときにLaracastsで学び始めたな
英語さえ聞き取れるなら動画つきだし分かりやすいと思うが そもそも>>687の人は本を読んで勉強したいんだから
公式ドキュメントを回答するのはダメだろ >>738
誰も公式ドキュメントみて勉強しろなんて言ってる人いないよ。
あくまでみんな本を主体とした上での話をしていて、
もしバージョンによる差異がある場合はリリースノートなり調べて解決するべきなのか？ってところを議論していたと思う。
>>732は一般論としての質問でしょ。 >>736
まず第一に>>733は「理解するために」入門書やメンターが必要なんて一切言ってないぞ。
入門書やメンターを用意したほうが理解が早まるかつ、より正確だろうという主張している。
そしてそれは決めつけるも何も、普遍的な事実だと思うがな。
あと昨日あたりのレスには、laravel8のアップグレードガイドすら理解できてないアホ経験者が何人か居たけど、初心者の方がそいつらよりオツムの出来が良くドキュメントも正しく理解できるて前提で話すことは合理的だと思うかい？ >>740
発狂してるようだけどどうした？
こどおじがそんなに悔しかった？ >>741
laravel8のアップグレードガイドをまともに読めなかったことを馬鹿にされたからって、そうやって人格攻撃に走るのは良くないなぁ。冷静に反論しようぜ。
まぁ冷静に反論するだけの知性があるなら、そもそもlaravel8のドキュメントちゃんと読めるだろうからなぁ。
無理難題言って悪かったね。好きなだけ罵ってくれ。お前にはそれぐらいしかできないだろうからwww >>742
だからそういうところを直さないから発狂しているって言われちゃうんだよ 相変わらず議論にならなくて、発狂しているてレッテル貼って>>740の本質的な内容は完全にスルー。恥ずかしいやつ。 >>742
そいつは俺じゃないから無視してくれ
730で「それなら8対応した入門書出るまで待てとしか」と書いてるよね。
同じ人だよね？同じ人かどうかはともかく少なくとも賛同している前提でレスするね。
待てと書いているわけだから、現状だとそれ以外の選択肢が無いと言いたいんだよね。
でも>>727は入門書を前提に学ぶとは書いてないよ。
「入門書（orメンター）」はあくまで君が推奨しているだけであって、公式の見解でもないし、そもそも初心者の定義だって決まってない。
入門書、メンター、Laracasts、公式ドキュメント、非公式ドキュメント、その他学習サイト、ブログ記事、5chで質問、etc…
ウェブで検索すれば色んな情報が得られる中、「初心者は入門書でないと無理だ」と決めつけるべきではなくないか？
ということを言いたかった。
> あと昨日あたりのレスには～
いや、「laravel7の入門書を持ってます」のくだりとは関係ないでしょ。それについて触れてないし。
>>727や一般論の話をしているんだよ。 >>746
そうなの？じゃあ本格的に昨日laravel8のアップグレードガイドもまともに読めなかったアホの1人が横槍入れてきたんだろうなぁ。事実なんだから、真摯に受け止めて反省してほしいだけなのに。
で、話戻すと俺は基本的に学習の効率性の面からアドバイスしている。laravel8の入門書が出るまでlaravel8の勉強を待った方が結果的に習熟は早くなると考えたからだ。
これはオレがlaravel8で環境作って開発してみた経験と、実際Twitterで初心者の人からlaravel8のルーティング周りでハマっていてアドバイスを求められた経験に基づいている。
もし俺が、自分の目の届く範囲にいる初心者にlaravel8の初心者に同じ質問されたら、マニュアル見ながらやってみたらと答えるだろう。
なぜなら何かあっても助けられるからだ。でもここはそうじゃないだろ？それこそ嘘の答えを平気で書き込む経験者すら居る。qiitaやブログ記事はそれこそベストプラクティスとは程遠い記事すら見かける。
更に海外のリソースは英語の習熟度に依存するので選択肢として挙げるには、質問者のプロファイルが足りていない。 >>746
お前のレベルでもわかりやすく理解できるようにわざわざ長文書いてやったのに
それを長文きちゃったとか言って煽るってどういうこと？ 荒らしする暇あったらlaravelのコード書いた方がよっぽど生産的だろうに。どういうモチベーションで書き込んでいるのかな？現実世界で辛いことがあって、その腹いせなのだろうか？ 多分Laravel8の破壊的変更に対応できないLaravel使いがイライラして荒していると思われる
公式ドキュメント読んでも理解できないし、Laravel8対応の技術本もないしでイライラしまくってるんだろうな どこから湧いて出たんだってくらいスレが盛り上がってるな >>751
それはもう別職種に転職した方が幸せな気もする(笑) 使えない奴らばかりだな。
なぜ初心者向けの書籍が売れるのか。
それはそれを順に読めば（逆をいえばそれ以外読まなくても）最低限の学習ができるからだ。
初心者にとって一番嫌なのは情報を追わないといけないようなコンテンツ。
検索しろとかアップグレードガイド追えとかあり得ないw
もう一回だけ聞いてやるわ。
laravel 8から入った初心者だけど、
laravel 8を勉強するにあたりいいコンテンツはある？
YesNoで答えてくれれば良いぞ。 >>755
すでに>>747がその回答になってるはずなんだが。不明な点があれば聞いてくれ。 フレームワークの書籍買うのなんてプログラミングそのものが初めてのやつだけ
そんな奴に聞いてやるわなんて書き込まれて
まともな返答する気が起こるわけがない 次回のLTSはLaravel8ベースってことでいいんだよね？
だったらLaravel8を勉強したほうが今後のためにもいい気がする
さすがにLaravel7や6を業務で使うのに8勉強してたらアホだけど >>758
次のLTSは1年後に来る予定のバージョン10だね。 Laravelのバージョンアップは毎回破壊的っていうけど他のフレームワークで破壊的じゃないやつってあるの？ >>760
基本的にはどのフレームワークでもメジャーバージョンアップでは破壊的変更が入りうる。なぜなら後方互換性を維持するのは手間だからね。 そういえばこのスレで以前jsonの脆弱性について騒がれていたけど
laravel8ではその脆弱性は修正されているの？ laravel 8が出たなら7を使うことなんてないんだよ
日本語ドキュメントもあるしな
つうかあのおっさん未だに翻訳頑張ってて偉いね >>765
されてない
多分直す気無いんじゃないかな いやLaravelのjsonの件はネタとか関係なしに有名だろ
プログラマとまったく関係ない加藤純一が実況で触れるぐらいだし >>769
純粋な疑問なんだけど、それ面白いと思って書き込んでるの？ 本当に妄想なのか？
みんなでものすごい議論しあってただろ
本当に妄想だったら誰も相手にしないはず マジレスするとLaravelのjson脆弱性はLaravel6の時の話であって
今は修正されている Laravel8のアップグレードガイド読めない君最近見ないね お前らってLaravel8のルーティングの書き方がわからなくてストレスたまっちゃって
それでこのスレを荒らしていたのか？ ・初心者はlaravel 7で勉強しろ
・初心者は移行ガイドを嫁
どれが正解なの？どっちもデメリットが思いつくけど 初心者の定義がはっきりしてないのに正解なんて分かるわけない
プログラミングの初心者なのか？
phpの初心者（他言語経験有）なのか？
Laravelの初心者なのか？
MVCの初心者なのか？
で話だって全く変わるだろうよ >>780
どの場合でもlaravelの初心者なのは間違い無いので、いきなりlaravelのアップグレードガイド見ろって言うの無茶じゃね？
先週荒れてたのは、経験者がアップグレードガイドを理解できず、laravel8の変更なんて大したことないと豪語しちゃって周りから叩かれてたからなわけで。 アップグレードガイドを読みながらlaravel 7の本を進めるなんてできるかね？
初心者のうちにそんな効率の悪い子としてられるか アップグレードって言っても空っぽのプロジェクトだろ？例え初心者でも大変なのか？
既存プロジェクトでしかもテストも書いてないから大変だ！って言うなら分かるけど >>783
プロジェクトのアップデートの話でなく、知識のアップデートの話だよボケ >>783
まぁ、人によるとしか言えんな
同じ初心者でも 数ヶ月ぶりにlaravel触ると、分かんねえ。本読んでもわかんね。 >>783
まず本に書いてる通りにやっても動かない、というのが問題だわな。
んで、動かなかった時にアップグレードガイドをみて原因を特定できる初心者がどれほど居るのか？って話だと思うぞ。
まぁ実際8をインストールして何か作ってみたら分かるよ。7までの書き方だとcontrollerクラス見つからねーてエラーになるから。
ここで、8を勧めてない奴は俺がそうであるように8で実際作った経験がある奴で、8で良いじゃんて言ってるのはlaravel公式のドキュメントなんて普段読んだことがなく最新のアップグレードも試したことない奴だと思うわ。 実践開発という本やってるけどangularで詰まった
やっぱ古いからなのかな >>789
controller見つからないはあり得ないだろ
artisanのmake:controllerで作っていればちゃんと所定の場所に生成されるはず
それって手動でコントローラ作成してないか？ >>791
まず8をインストールして、route/web.phpに7までと同じ書き方でエンドポイントにcontrollerを指定してそのurl呼び出してみたら分かるよ。 初めてLaravelをインストールしてみようと思うんですが
コンパイルはどうやって行うんですか？ 度々すみません 公式サイトのドキュメントを見ると
laravelというコマンドでプロジェクトを生成するパターンと
composerというコマンドでプロジェクトを生成するパターンがあるようなんですが
これらの違いって何かあるんですか？ 「お酒買ってるってことは夜勤帰りですか？」て聞かれて「あ、そうですよ」て返したら「お疲れさまです！明日も頑張ってくださいね」って言われた
半年間行ってて初めて話しかけられてめちゃくちゃ嬉しいぞ >>796
最終的には変わりないよ。 ただlaravel installerはパス通さないといけないので、初心者はcomposerで入れた方が良いと思う。 laravel公式のvagrant？を使う環境を用意してくれてますが
dockerはないのでしょうか？ >>799
公式ではないけどいくつかあるよ。有名なのはlaradock。でもdocker使うのならオススメはvesselかな。 確かに今まで疑問に思ったことなかったけど
違いがないのでなんでlaravelというコマンド用意したんだろう >>792
コントローラー@関数名から
[コントローラー::class, 関数名]
にするだけじゃん
それ説明するだけの事をなんで勧めない理由にすんの？ 学習するなら
require laravel/ui
php artisan ui vue --auth
php artisan migrate
とか
require laravel/jetstream
php artisan jetstream:install livewire
php artisan migrate
とかをやってある程度枠組みができた状態からやった方がいいだろ
routeファイルなんてゼロから書いても仕方ない >>802
初心者には8をお勧めできないことを証明してくれてありがとな。そのやり方だと動かない。
問題はルートサービスプロバイダ。namespaceプロパティにapp/Http/controllerを代入せずnullにしたこと。
だから、8ではcontrollerごとにuseするか、controller名をフルパスで指定するか、ルートサービスプロバイダ側の設定を7と同様にする必要がある。
んで、そういった設定の違いに気付いてlaravel初心者が自分で対応できるかは不定なので、参考書とバージョンを揃えるのが無難。 >>803
それただ単にユーザー認証のスカフォールドを実行してるだけじゃん。
しかも前者はbootstrap+vueだからまだ良いけど、後者はlivewireに加えてtailwindCSS+AlpineJSだから、参考書に全く載ってない技術スタックになってしまうぞ。
そしてtailwindCSSやlivewireは英語オンリーだし、AlpineJSは日本語あるもののドキュメント自体整備があまり進んでない代物だよ。こういうことはlaravel8で開発してみたら判るんはずだけどねぇ？ >>804
？
802の言ってること正しいじゃん
::classって書いてある時点でnamespaceがフルで必要なのはlaravel以前に言語仕様じゃん >>806
それは好意的すぎる解釈だね。変更前と変更後のどちらもコントローラーとしか書いてないて時点で、俺は::classに変えておきながら、コントローラーはそのままなんかいて思ったけど？ はやく８対応の本を出してください
急いでますから！ へぇ、8からは::class
キーワードで指定できるようになったか
7まではコントローラー名を文が字列指定だったからIDEが認識しなくて地味に不便だったんだよな >>806
うん、まっとうなIDE使ってりゃ
「そんなクラス存在しないけど多分これだよね？useしとく？」
て聞いてくるよな >>810
まっとうなIDEねぇ？どんどん初心者にlaravel8を勧めないて話から逸れていってる気がするけど。
初心者でまっとうなIDE導入する人どれだけおるん？vscodeやatomスタートが殆どでは？ >>811
vscodeでもuseに変更するか聞いてくるぞ
atomはしらん >>811
レスバはお前の負けだからおとなしく引き下がったほうがいいぞ というかそもそも
SampleController@関数名という描き方から
[SampleConroller::class, 関数名]という描き方になるだけで
なんで初心者にLaravel8を進めないという結論になるんだ？
初心者なんだからLaravelは[SampleConroller::class, 関数名]って書き方で
ルーティング設定するんだって思うだけで終了だろ
違い気にするのは過去のLaravelで製作してるやつらだけだろ >>814
まず>>789を読んでみたら判ると思うだが、初心者が既存のlaravelの参考書を使う場合、参考書のバージョンにするほうが良いのか、8にする方が良いのかという話なんだわ。 >>812
プラグインをちゃんとセットアップすればね？お前の想定している初心者像がもはやどんなものなのかすら分からんな。 Laravel初心者がuseをし忘れて（または知らなくて）解決できないってケースを否定まではしない
ただ、そもそも論になって申し訳ないが、それはLaravelとは関係なくてphpの言語仕様だから、そういうレベルだとそもそもphpの言語仕様から学ぶべきだと思う。 >>817
いや、そもそも>>802に気づくことができないだろって俺は思ってる。 話逸れるけど、名前空間の概念を知らないレベルだとアップグレード云々どころか本とバージョンが合ってても難しそうだな
名前空間なんてphp固有の概念ですらないし
つかこういう本の読者想定って最低限言語仕様を理解している前提じゃないのかな？
あんまそういう本買わないから分からないんだけど
発端となった人の参考書の想定読者層を知りたい >>819
俺はlaravel初心者の大半はPHP初心者でもあるって想定だね。そもそもPHPある程度できるやつは、laravelの参考書読むより、マニュアルとlaravel本体のコード読んで勝手におぼえるじゃんて思ってる。 >>805
既に動くルーティングがあるっていうのはめちゃめちゃ参考になるんだが >>821
初心者はPHPの書き方も知らないのにどうやって参考になるの？ >>821
お前自身ユーザー認証スカフォールド使ったことある？実際それセットアップしてコードリーディングしてたら、そのコメントは絶対出てこないはずなんだが。 ああスマン、見直してみたらルート設定が書かれてるのは
vendor/laravel/jetstream/routesの中身だったのをrouteに書いてあるのと勘違いしてた >>816
それは昔のvscodeだろ今はvscode標準でphpの機能入ってるから
プラグイン無くてもuseにするか？とかは聞かれる 黙れ黙れ黙れ黙れ黙れ黙れ
お前らにプラグインいらなくてもいいって言われて発狂しそうだわ 今までとルートの書き方が違うから初心者に進めることができないってのが理解できない
初心者は今までの書き方との違いなんて気にしないだろ ここで聞かれてるんなら差分くらいはここで説明すれば済む話じゃね？ やってみて分からんかったらまたここで聞けばいいだけだろ >>829
参考書と異なることが問題だって既に何度も説明してるのだが？ すみません ドキュメントを見るとLravelのAPI回数規制で429を返すようですが、
回数パラメータを多くしても429が返ってくるのはなぜでしょうか？
artisan serveで起動していたのでartisan serveを再起動してみたり
キャッシュクリア実施してみましたが変化なしです。
マックス値を10回で設定しているのになぜか3回目から429になります 自分も教えてくださいLaravelでsqliteデータベースを使用してチュートリアルを
行っているのですがphp artisan tinkerコマンドでシェルに入ってモデル操作を行うと
DBからデータを取得したり書き込んだりできるのですが
php artisan serveでサーバを立ち上げて実際のコントローラ経由でモデル操作を行うと
sqliteにアクセスできないのですがどうすればいいでしょうか。
エラーを見るとapp直下のモデルが見つからないとかモデルの関数名間違い等のエラーではなく
そもそもsqliteのデータベースファイルが存在していないというエラーになってしまいます。 DBに接続できない件解決しました
Laravelはartisan serve経由だとMySQL、artisan tinker経由だとSQLiteにアクセスする仕様なんですね
この仕様知らなかったので焦ってしまいました
>>836
ありがとうございます。Laravelの仕様の問題だったようです > Laravelはartisan serve経由だとMySQL、artisan tinker経由だとSQLiteにアクセスする仕様なんですね
そんな仕様ないと思うけど 多分artisan serveとtinkerで実行したときとでモードが変わっている
productionとdevelopmentが切り替わったせいでDB接続先も変わったんだろう 7や8ぐらいで変わったとか言ってたら既存のライブラリなんかまったく使えないだろｗｗｗ
ホントバカが多すぎて笑えるｗ >>843
いや、変わったとか大騒ぎしてんの一人二人くらいだろ 7→8に変えたけどroute書き換えるくらいでウチのフロントのReactくんは問題なく動いたよ そもそも話の発端は、本を頼りに勉強する初心者くんにlaravel8をやらせてよいか？だからな。業務で使ってるようなやつなら、別に自分で対処すれば済む話。そこを理解してないバカが約1名居るようだな。 make:authで認証自動生成してくれるけどメールアドレス前提で
コントローラや画面生成するのやめてほしい
make:auth実行したらどういうアカウントのModelにするか入力させる方式にしてほしい
イメージ的にはsymfonyでmake:entityしたときみたいな感じ Redisについて質問です。
Predisが将来削除されるということから、PECLでPhpRedisをインストールしました。
マニュアル（Laravel 6.x Redis）に以下記述があります。
-----
Redisファサードエイリアスに加えPhpRedis拡張を使用する予定であれば、
Redisクラスとの衝突を避けるために、
RedisManagerのような他の名前にリネームする必要があります
-----
マニュアルに記載の通りエイリアスから下記行を削除しました。
// 'Redis' => Illuminate\Support\Facades\Redis::class,
上記対応をした場合、以下の記述はPhpRedis拡張を利用しているのでしょうか？
-----
use Illuminate\Support\Facades\Redis::class;
Redis:set(key, value); >>849
Illuminate\Redis\RedisManager で定義されてる connector() でこう実装されてる
switch ($this->driver) {
case 'predis':
return new Connectors\PredisConnector;
case 'phpredis':
return new Connectors\PhpRedisConnector;
}
だから、ここにブレークポイント貼って確認すると良いと思う。
driver は config/database.php の redis.client で設定されてるから確認して。 >>849
そもそもの話だけど、predisは復活したから削除されなくなると思うで。 >>850
>>851
ご回答ありがとうございます。
↓に記載されていないメソッド（hMSetとか）も呼び出せるようになっていました。
https://laravel.com/api/6.x/Illuminate/Redis/Connections/PhpRedisConnection.html
ファザードをほとんど理解していないので>>850さんが言うように、
↓のクラスが何をしているのか調べてみます。
use Illuminate\Support\Facades\Redis::class;
ありがとうございました。 結局Modelsディレクトリ問題は何だったんだよ
初心者ながらにググって作り方調べて毎回作って設定とかに紐付けてたのに
8は普通にあるじゃねえか ModelとViewとControllerを配置するディレクトリ構成が他のMVCフレームワーク異なっててわかりにくい 色んなフレームワーク使ったけどLaravelがとうとう人類が手に入れた完成版て感じ、なんでもできる
5.8の時点でそう思う（数年前5.8で作ったシステムの使い回し案件をやりながら） laravelのインストールが終わりましたが結構大変ですね。。。 Composerがエラーを吐きまくる
Composer嫌い、動けば便利なんだろうけどさあ… >>858
Dockerなんですけどパーミッション関連が大変でした。。 JetstreamのオプションってConfigでオンオフできるけど、勝手に切り替えていいのかな
とりあえずチーム機能入れといて後で要らなくなったからオフするとか LaraveldeはCakePHPのようにコントローラーとアクションを作成したら自動でビューに紐付いたりはしないのでしょうか？
このように書いた場合はview('hello.world')を書かずとも、
http://localhost/hello/worldにアクセスしたら、
resources/hello/world.blade.phpを使うと思ってたら使われませんでした。
class HelloController extends Controller
{
public function world(){
return view('hello.world');
}
} 寧ろフロントはJSフレームワーク使うからPHPによるVIEWはノーセンキュー >>861
それLaravelじゃなくてDockerが苦労したってことね そうなんですね！
viewをしっかり設定するようにします！
ありがとうございます！ eloquentとcollectionの親和性もっと高めてくれないかなあ。なんか惜しい。 routingのwebとapiってどのように使い分けたら良いのでしょうか？
和訳ドキュメント見ても近いわけがよく分かりません デフォルトで適用されるミドルウェアが違ったりするんよ。
app/Http/Kernel.php
あたりを見てみるといい。 >>871ではないですが、たとえば同プロジェクト内のフロントにAPIを提供するだけの場合、web.phpとapi.phpのどちらを使うべきなのでしょうか？
調べても
・内からの場合はweb.phpを使う
・APIなのだからapi.phpを使う
・api.phpにweb.phpと同じミドルウェアを適用して使う
など色々出てきてよく分かりません…… インメモリのSQLiteにpostしたレコードを、assertDatabaseHas()で検証することはできますか？
テーブル名が分かりません。 >>873
別にどっちでも良い
そもそもwebとかapiとかは便宜的に名前付けられてるだけだから好きに変えられる。
RouteServiceProvidorで定義されてるから確認したら良い。
あとはApp\Service\Kernelでルートごとのミドルウェアグループの適用されてるからそれも見たほうが良い。 違った
App/Service/Kernel
↓
App/Http/Kernel >>875
なるほど、納得できました
ありがとうございます！ ドキュメントの和訳ずっと続けてるあのおじさんいまだに続けてたんだね
すごいな 学生にインターンという名で
バイトレベルの報酬でフルスタックの仕事させようとするの止めろｗ
twitterで宣伝していて引いたわ フルスタックとか言ってもただの学生だろ？
戦力にはならないしそんなもんだろ Livewireとかこれから使われるようになると思う？
いよいよLaravelも老害化してきたか。 早すぎだろ
ようやく覚えてきたのにもう世代交代かよ
正直そこまで極端に早いとビジネス成り立たないだろ、常に学習コストばかりかかる せめてinertia使おうぜ
Reactないから俺は使ってないけど sanctumって複数ログインできる？
普通にauth.phpでsessionってしているすれば動いてるっぽいけど langのvalidaton.phpでattributesを日本語化する時、カラム名だけじゃなくモデル名を指定することはできないだろうか
同じカラム名でもモデルによって意味が違う事があるんだよね laravelですら構造や仕組みをしっかり理解してないままなんとなく使ってる奴がほとんどですね MultiAuth実現するときに認証系のソースの中身とかはガッツリ読み込んだな laravelマスターしてエキスパートになれたら
年収いくらくらいを目指せますか？ laravelっていうかphpをいくら極めたところで年収は500がいいとこじゃないか？ もうちょい行けるぞ 1000近くまでは行ける
ソースは俺
めんどいからそこまでやらんけど 開発環境で質問です。
久しぶりにLAMPで開発することになりました。
昔はXAMPPを利用していましたが、
皆さん今はどのように進めていますか？
はやりはDockerでしょうか？ そうですよDockerですね
docker-composeを使うといいですよ 別にXampp含めて何でも良いと思うけど
Dockerもありだが、本番環境に近いのがベストだよね
Vagrant + Vurtualbox + CentOSとかでもありかと 自PCで完結させた所で後で結局テストサーバーとかステージングサーバーに上げるんだから
最初からサーバー上で動作確認してるわ
エディタで保存したら自動的にサーバーに上がるようにしてる データクリーニングしたくなったときどうするんだろ
自分一人しか使わないなら好き放題データ消せるけど、それなら自分一人の為にインフラ用意するのも無駄じゃない？
web, db, redis, storage どこまで用意するのかにもよるか PHP開発でデバッガは使わない、そんな大したバグ追いになるケースがなくログで今まで十分だった
大したもの作ってないって煽られるのかも知れないけど
DBはメンバー毎に用意する、ディレクトリ分けてURLを別にしキャッシュの名前空間も自動で切り分けるようにしてる 俺もPHP開発でユニットテストは書かない。ユニットテストを実行しなくても、そんな大したバグを作るケースが無く、毎回手動テストを念入りにすれば十分だった。バグを作らない自信もある。他のメンバーも書いてない。
大したもの作ってなって煽られるかもしれないけど >>899
あれ、それってローカルで開発したら必要なくね？
うはw俺天才w >>899
それ、開発を楽にしようとして逆に大変になってないか？ Laravelなのに未だにこんな未開な環境で開発してるのもおるんやね。>>899みたいな環境、オンプレ残ってた5年前ぐらいまでウチもあったけど、今は滅んだ。 うちは案件によってどっちもやる
新技術についていけないのと、必要が無いからあえてレガシーにやるのとは違う 開発環境何使ってる？
うちはwindows10でWSL使ってる。
複数環境使えるから、dockerの必要もないかな。 マックからwindowsに引っ越してきました。
PHPやnode.jsやgoなどちょっと試す程度なら、
マックの場合ターミナル開けばコマンド打ってすぐに開発環境が構築できますが、
windowsの場合一般的にどう構築していくのでしょうか？ 本番環境にDocker使うのも増えてきてるけど、
すべてのケースで使えるところまではいってないかな >>910
WSLでしょうか？ちょっと調べてみます！
>>895
でVagrant + Vurtualbox + CentOSがいいのかなと思ったのですが、
このcentos上にdockerを構築するでもいいんですよね。
なんか色々ありすぎて面倒です。 >>908
homebrewみたいなのを求めてるなら
Windows Package ManagerがリリースされるまでのつなぎとしてChocolatey、scoopがあるよ
あとはWSLとMicrsoftストアからUbuntuなどのLinuxディストリインストールして動かす >>908
あとはnode.jsとか公式サイトで配布されているセットアップファイルからインストールする >>912
Windows Package Manager には期待したいですね。メモしておきます。
結局色々ありすぎて、どうせ本番環境に近い形で構築するならばといことで
Vagrant + Vurtualboxでやっていきたいと思います。 nvmは複数バージョンのnode.js入れる時便利 >>911
Docker Desktopだけでいいでしょ。
要件満たしたWindowsなら勝手にWSL上にホストを作ってくれる。
自前でWSLなりVMなりでDockerホストを用意してもいいけど。 dockerコンテナが↓の構成の場合にphpコンテナからnodeコンテナのnodeスクリプトを実行する方法がわかりません。
php（php-fpm、composerなどインストール）
node（node、npmなどインストール）
もともとphpコンテナにnodeやnpmなどインストールしていて、そのときは以下のコードでnodejsのスクリプトを呼び出すことができたのですが、
exec(node, main.js, 2>&1, out, ret)
コンテナ分けた場合の呼び出し方がわかりません。
どういう書き方で呼び出すことができるか教えてください。 >>882
すんごい触りしか見てないけど、JavaServer Facesだよね、これ。 laravel6lts使ってるけど、laravelって
cakephpのbakeみたいにcrud自動生成コマンド
標準で付いてないの？(´・ω・｀)ｼｮﾎﾞｰﾝ php artisan make:controller ExampleController --resource サービスプロバイダが何の事やらさっぱり理解できん
誰か助けて Laravelいいなと思って少し勉強したんだけど、使えるサーバーが限られていない？
どこのサーバー（共有レンタルサーバーとか）でも簡単にデプロイできる？
multi auth使うとなるとnode.jsのインストールも必要なんでしょ？ >>922
別にいらんよ。
phpの対応したバージョンとextensionがあれば動く。 今から新規システム作るならバージョンは何がいいの？
6はもう古い？ ほぼ8一択
10にアップデートしない前提なら6でもいいけど >>919
>bake
これがいいぞ。
Scaffold系は色々あるけどこれが一番シンプルで使いやすかった
https://github.com/appzcoder/crud-generator >>927
なるわけないだろ
ただのアップデートなんだから 8より6の方がLTSだからいいんじゃないのか
納品後にLaravelのアップデートなんてまずしないし >>925
次のLTSは9だぞ。3月のリリースやめて今後は1年に1回のメジャーアップデートにするって、一昨日ぐらいに発表されてた。 >>929
アップデートしない前提ならLTSである意味すら無いのでは？
それともマイナーアップデートが配信されたらそれだけ反映するのかな？ >>930
ほんとだ、ブログに書いてあるね。
「セマンティックバージョンを採用以降、リリースサイクルはこれまでと変わらないにも関わらず、コミュニティにとってはリリースがとても頻繁になったと感じてしまい、実態とずれた感覚を与えてしまうから。」
ってことかな。
同じこと思ってたし良い判断だな。 >>931
基本的にアップデートしないけど、危険性の高いバグフィックスなんかがあった場合にはできる可能性があったほうがいい
サポート終わるとそれがなくなるからな このフレームワーク機能が多すぎない？
昔はこんなに多機能じゃなかったのに >>935
あれができなきゃ、これもできなきゃで、MS-EXCELが巨大化したのと一緒かな 久々に使ってみたが、複雑になりすぎて使いにくくなったな 8はRouteの書き方がけっこう変わったね
9でLTSになったら移行するけど、それまでは使う気になれんのぉ IISとかAzureはPHP8サポートしないのね。7の1.5倍は速いのに >>939
JITのRFCちゃんと読んだ方が良いぞ。 >>940
PHP8のJITがWeb向けじゃないといいたいのかも知れないけど
Laravelを使ったものなら体感で違いがわかるくらい速くなるぞ >>941
Laravelの場合ってのは、OPcacheやpreload使ったケースとの比較で体感できるぐらいに早いって話？ >>944
最適化したLaravelがPHP8でどれくらい速くなるか検証してくれ LaravelってURLがドメイン直下じゃないと動かない設計なのかよ
サブディレクトリに置くとmix('css/app.css') なんかがリンク切れになる
Stackoverflowに同じ質問あるけど未解決、なんちゅー不便なフレームワークなんや jsでalertを使うと配列が読み込めるのってなんでだ livewireも読み込めないし、サブディレクトリマジで使えないんだな
めちゃくちゃ高機能になってる一方、こんな不都合があるとは驚いたわ
しょうがないからルートに置いたらあらゆる問題が解決した mixをassetに変えれば動くけどバージョニング対応できなくなるから解決策ではないだろ？
8でjetstreamやlivewireを使うとさらにややこしくなる、それらはサブディレクトリ設置を想定してないから
数々の質問サイト見ても結局面倒だからルートに置けって結論になってる
反論がある方はどうぞ、良い解決策があれば教えてください そもそもサブディレクトリにこだわってる奴は何がしたいんだ？ 何って、一つのサーバーでいくつもLaravel動かしたいじゃん
一人や数人で使う小さいサービスや、開発中なんかに普通にある需要だろ それサブディレクトリ使う必要性ゼロじゃん。サブドメインごとにそれぞれ異なるドキュメントルートをnginxなどに設定するだけで済むんじゃないのか？ もちろんサブドメインじゃなくても良いぞ。
a.hoge.com → /var/www/a_hoge/public
b.hoge.com → /var/www/b_hoge/public
fuga.com → /var/www/fuga/public もちろんドメイン管理権限持ってればそれで全く問題ない
問題はない場合 いやサブディレクトリに設置できないフレームワークの方がつらいと思うが…
今の若者はそんなことやらないのか、昔はApache入れたらユーザ毎のウェブディレクトリがデフォであったもんだが 自分が困ってない問題を指摘する人間を冷笑して煽るしか芸が無い
今の若者そのものｗ そもそもサブディレクトリに置いてmixがリンク切れになるとか言ってFWディスるから煽られる。
そんなんでリンク切れになるなら、mixでコンパイルしたアセットをCDNにすら置けないじゃん、てことを考えるとどっちがおかしいか明白でしょ。 これ見て誤解する人いたら可哀想だから言っておくが、スタックオーバーフローで回答してた奴とここで文句言ってる人がクソ雑魚なだけで、mixアセットもlivewireアセットもサブディレクトリ運用できます。 ありがとう、最初からそう教えてくれればよかった、できたわ
とは言え俺の聞き方が悪かったわ、ここで回答が得られると思ってなくて書き殴ってしまった
すみませんでした
ちなみにmix_urlの指定はすぐできたけど、livewire.phpのほうは最初configになくて一手間かかりました >>969
パッケージは初手でvendor:publishしてconfigを持ってくるて覚えておくと良いよ。今回の場合、どちらもそれぞれのマニュアルにバッチリ書いてあるレベルの話だから、安易にFWの問題と切って捨てるのは印象悪い。 公式マニュアルって正確な情報を漏れなく記載しないといけないから冗長な物が多くて、
つい読まずにぐぐって知りたいことだけ書いてある記事見てショートカットしたくなるけど
Laravelのは読みやくて出来いいから真っ先に見るべきだな
逆に全体的に思うのはぐぐって出てくる記事の質が10年前より劣化してる
昔はスタックオーバーフローでなんでも解決、キータですら役に立ったこともあったのだが最近はダメだね >>971
そうだね。livewireもそうだけど、マニュアルはスッキリしてて読みやすいからまず真っ先に読んだ方が良いと思う。それで分からないなら、コード直接見る。
qiitaは初心者と初心者上がりの半端な人がゴミを量産しているから全く参考にならない。解説サイトも同様。stackoverflowやteratailもごく一部の回答者以外はqiitaの質と大して変わらない印象。 >>946
Webサーバーのconfでどうにかすればいいだろ >>955
公開サーバーならサブドメイン切ればいいし
非公開ならポート番号分ければいいじゃん Angularを齧った事あるヤツなら知ってる＜base href="～" /＞を使えば解決するけどな タグのエスケープってこれで行けるんだっけ？
<tag /> ログインしてるかどうかの処理はどこに書いたらいいんでしょうか？ >>978
Laravelの作法に則るならmiddlewareだよね。そのmiddlewareを指定するのはrouteでやる。コントローラーのコンストラクタでやる人も居るけど、それだとログイン必須のルートがぱっと見て分からないので不便。 みんなWindowsで開発する時どうやってる？
・xampp
・php artisan serve＋何らかのDB
・Docker等
・別のサーバーに上げる
どれ派が多いのか知りたい WSL（Debian/Ubuntu）+Docker
どうしてもDockerが使えない且つRedhat系なら別VMを建てる。 海外だとXAMPPよりLaragonのほうが勢いある。 >>979
middlewareですね。ありがとうございます。 Xampp使ってるのは95パーセントの超初心者と5パーセントの超玄人 Laravelってミドルウェアまで視野に入れたフルスタック系のフレームワークだからXAMPPだと再現が難しい。 xampp使ってる会社あるか？
ほぼdocker一択だろ？ Dockerで本番環境までやってるところはDocker一択だろう
そうでなければ別の選択肢もあるかな
なるべく本番環境に近づけることが優先
ということでXamppは仕事で使うとかはちょっと想像しにくい >>988
VPS借りてLinuxだが言うほど一択か？ >990はわざわざVPS借りてその中で開発しているのか。それはそれで面倒くさいね。 VPS上で開発も別に珍しくないと思うが
自分で環境構築できない人（デザイナーとか）に環境渡すの楽だし
とにかくDocker一択ってことはないかな
意識高い系が集ってるならそれでいけるだろうが、
世の中みんなそんなに意識高くないよw 教養の有無を意識が高い低いって言ってるようなもんだな dockerなんて一人が設定ファイル書いて他の人はコマンド一発だから一番楽じゃね？ >>995
俺もそう思う。今時駆け出しエンジニアでもdocker使ってるのに、それを意識高いとか言うの謎すぎて草生える。 Dockerって重いしトラブル多いやん
インストール中にコケたりとかで、新人に導入させるのいつも苦労する このスレ民は「APIのレスポンスをjsonで返すとか脆弱性の観点からありえない」って言ってるし、具体的に何が脆弱なのかも答えられないレベルだから
まだ1990年代の感覚なんだろうね このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 451日 10時間 29分 15秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
