【PHP】Laravel【フレームワーク】 Part.4
レス数が900を超えています。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【フレームワーク】 Part.3
https://medaka.5ch.net/test/read.cgi/php/1574216148/ >>836
まとめてくれてるのはいいんだけど、過去ログ見ればわかるから。
結局、laravelの脆弱性対策はどうなの？ >>836
一般的で無いとする根拠は？
- 12factors
- gitguardian
あたりの記事でも、プライベートリポジトリであってもクレデンシャル情報を原則入れるな、だよ。
例外として、以下の条件を満たしている場合はOKとしている。
- アプリのコードと分離したリポジトリである
- 暗号化している >>838
「プライベートリポジトリであってもクレデンシャル情報を原則入れるな」=「流出を危惧」ではないよ
「データベースへの接続情報は、ミドルウェアの管理者が管理する事」とか「特定管理者以外に資格情報は開示しない」って、ルールの背景を考えるとわかる
ソース流出を想定するっていうのは、大雑把すぎるんだ
流出のみでなく、内部統制であったりカジュアルな盗み見防止であったり、理由はいろいろだけど「閲覧できる範囲をより限定的にする」ことがベストプラクティスなのは間違いない
問題は、現状、「閲覧できる範囲をより限定的にする」=「ソース管理からはずす」ではないプロジェクトが多数出てきている事
主にインフラの多様化が進んだせいだね
なので、まとめは「ソース流出」を一般的な脅威と捉えず、ちゃんと自環境の脅威を整理しようね。ってことだろ
この辺は.envを管理対象にするとかしないとかとは本来は関係ない話
どっちであっても、考えなければならない事
セキュアな環境をどうやって作るかってところだね gitguardianの記事を読んでないんだろうか？
そこでは、悪意のある攻撃者はプライベートリポジトリにヤバい情報を置いていると考えて優先度の高い攻撃対象に選定するので、原則置くなって話なんだけどな。せめて置くなら暗号化せよ、だね。
わざわざ「プライベートレポジトリは、シークレットを保管するための安全な保管場所だと勘違いしている人はたくさんいます。」て書いてくれているわけだし。
「勘違いしている人が沢山いる」からそれが一般的だ！て主張なら同意するけど、一般的だから問題無いという主張なら同意できないかな。 >>839みたいな具体的な脆弱性の内容とその対応がようやく出てきてよかった。
どういった状況で何の情報を誰から守るか具体的な対応が取れてるなら他人にとやかく言われることじゃ無い。
「.envをコミットしない」だけじゃ具体的な危険性の説明が無くて大雑把すぎる。
他人に時間取ってもらって対策してもらうには話の進め方が雑 長々と脆弱性の問題書いてるけどさ、それ以前の問題なんだよ、たしかにそれもあるんだけど。
環境ごとに変わる値をコミットしても意味ないし邪魔なんだよ。 発想が真逆で笑える。
.envは.gitignoreでデフォルトコミット対象外なのに、あえてコミットする奴らが居て話題なっている。
そして、そいつらに理由を聞いてもまともな理由が返ってこないというのが現状な。
>>756みたいな恥ずかしい勘違い以外だと客の希望によって仕方なくって話ぐらいじゃないか？ >>844
でかいとこだと一定数存在しそうなルールだと思うよ
過去になんかやらかしてたら、ガイドラインに取り込まれてそうな香りがプンプンする箇所だしｗ
「本番に上げる一時ファイル以外のコードは、すべて管理対象とすること」とか普通にありそう >>841
「ソースコード流出」の例は、粒度がおかしいって指摘だろ
ソースコード流出を考えなきゃいけないようなプロジェクトだと、それ以前に閲覧権限の制限で「機密情報はどうやって管理されるべきか？」って話になるし、流出を考えなくて良いプロジェクトならどーでもいい切り口
ソースコード流出の原因を適当に並べると
・公開範囲の設定ミス
・閲覧可能アカウントの乗っ取り/クラック
・SaaSの脆弱性をつかれる
とかだと思うけど、こんなレベルにブレイクダウンして、コード管理手法を問うようなた議論はこのスレで見たことない(＆スレチ) 本番用.envの設定ミスで本番データがテスト環境のDBに書き込まれてたとか普通にありそう
そういうやらかしやった企業だとよくわかっていない上司が
「すべて管理対象に含めろ！！」とか言ってそうだねｗ .envとしては正しいけどキャッシュのせいで違う値で動作していたってパターンもあるなｗ 話変わって申し訳ないけどlaravel-mixって使わないほうがいいの？
前にこのスレでlaravel-mix馬鹿にしている人がかなりいたけど使うとダメなのかな 別に使ってもいいよ
どうせならvue.jsのスタンダード覚えた方が潰しが効くし、完全にフロントとLaravelを分離できるから、バックエンドだけ移植とかにも対応しやすくていいとは思うけど >>850
使っても良いと思う。大きな問題もないし。
でも使う意味はあんまり無いと思う。
vue-cliを捨ててまでlaravel-mixを使うメリットが無いのと、今なら爆速の開発サーバーviteもあるし、ますます使う意味が無くっなった。 React使ってるからLaravel-Mixで問題ない .envや/vendorをコミットする衝撃に比べるとlaravel-mixを使うなんてどうでもいい
ベストではないがバッドというほどのことではないね >>850
laravel-mix馬鹿にしてたのはたぶん1人。同じやつが何度も書いてたと思われる。 .envコミットは論外だけどvendorやnode_modulesをコミットはケースバイケースだね 逆だぞ
.envをコミットするのはケースバイケース
node_modulesやvendorはOSによってダウンロードするライブラリが違うから
基本コミットしないほうがいい コミットについてにぎわってるようだから自分も質問させていただきます。
laravelのcacheフォルダのファイルってコミットしたほうがいいんですかね？
デフォルトだとcacheフォルダは管理対象外っぽいですけどコミットした時のメリットって何かありますか？
あとlaravel-mixを使用したときにビルドされたcssやjsは管理対象に含めたほうがいいんですか？
それとも管理対象に含めるのはやめて本番環境で毎回ビルドかけたほうがいいんですか？ キャッシュをコミットして本番アップしないと、初回アクセスしたユーザーの処理が遅くなるだろ
大企業ではキャッシュも本番アップするのが常識だぞ >>860
キャッシュは必ずコミットするべき
理由は詳しくは言えんがlaravelのissueを見てくれ、散々.gitignoreから外したほうが良いって言われてる
え、.env？あれをコミットするのはどうかしてるね >>859
お前しつこいぞ。ケースバイケースっていうが>>756のケースしか上がってきていないし、そのケースで.env使うのはアホって結論出てる。
あとOSによってダウンロードするライブラリが違うってどういうこと？お前はwindowsとmacとlinuxでjsやPHPのコードの使い分けてると思ってんの？マジ？
そんな程度だからケースバイケースなんて寝ぼけたこと言っちゃうんだぞ。1年ぐらいROMしとけ。 確かcomposerかnpmでmac環境でしか落ちてこないライブラリとかなかったけ？
最近dockerした使わんから勘違いかもしれんが お前ら初心者を騙すのはほどほどにしとけよ
信じるやつが出てきかねんぞ キャッシュはコミットしない
js cssとかのビルドアーティファクトは状況による
ただリポジトリに入れるとコンフリクトが多くて面倒
小規模なら本番でビルドするのもありだけど、大半は自動ビルドツールを使う >>863
node_modulesがOSごとに違うのは有名な話だろ >>863
なんで老害って他のやり方を一切認めないの？ >>873
認めて欲しいなら>>820の質問に答えような。 どんどんネタに走っていくな
キャッシュのコミットはさすがにネタとしてもやりすぎw
>>860は狙いすぎ キャッシュはコミットしないほうがいいよって言うと
「なんで老害って他のやり方を一切認めないの？」
と返されるのかな OSごとに異なるって、LinuxとWindowsだったらあるかも知れんけど
CentOSとAmazon Linuxぐらいの違いでも変わるの？ 「コンプラがー」「OSの違いがー」
お前ら根本的にずれてるよね
そんなの焦点ですらないのに laravelも最近symfonyに押されつつあるな お前らってデプロイ時のDBの初期データってどうしてる？
本番リリース用のシーだー作ってそいつで登録？
それとも普通にリリース用sqlファイル用意してそいつで登録している？ adminユーザー1個だけtinkerで登録して
後は蔵に全部入れさせる やっと念願のlaravelでアプリ開発できる
よろしく 本番用シーダーは基本作らないほうがいいぞ
あれはあくまでもテストデータを用意するためのツールであって本番環境で使うことを想定されていない
本番用データを登録するならシーダーではなくmake:commandで専用の登録コマンドを作ったほうがいい いやマスター用のseederは環境問わず使うんだから用意するだろ
トラン用のseederはその通りだが シーダーなんてテスト用のゴミデータ入れるためのもんだろｗ
PHP配列書いてデータ管理するつもりなのかｗ Laravelの1+N問題ってのは理解できたんだけど
10+2N問題ってのが全く理解できない どうすればそんなことになるのかもよくわからん .envコミット君といい本番用seeder君といいこのスレは愉快な仲間たちでいっぱいだな >>893
想定はしているぞ。ただし推奨はしていないので、app.envにproductionて文字列が定義されていた場合は、本当にシーダー使う？てプロンプトが出てくる。
https://laravel.com/docs/8.x/seeding#forcing-seeding-production >>896
なんで老害って他のやり方を一切認めないの？ お前らマスターテーブルとトランザクションテーブルの違いも理解してねえのか
マスターテーブルのseederは用意するだろアホか 単発IDで老害って書いてるお前の方が頭が固い老害
老害は出ていけ 俺はいわゆるマスターテーブルみたいなのはenumクラスで定義するから、最近はマスターテーブル自体作らないな。
ただシーダー使ってマスターテーブル作りたい奴は好きにしたら良いとは思う。都道府県マスターとか？ マスタデータをValueObjectのようなクラスで持たずにDBで持つ場合は、SQLを用いた検索をできるメリットがある。
逆にそれがメリットにならないようなデータはDBで持たずにValueObjectで持ったほうがいい。
.envのコミット（多分ネタだと思うけど）と違ってこっちは本当にケースバイケースだからな。 seederなんてテスト目的でも書きたくないわ
php直書きだぞ？メンテナンス性悪すぎだろ >>897
それLaravelじゃなくSQLの話じゃね？ >>906
典型的老害で草
ちゃんと少数派のことも認めろ 俺「ああ…すごく気持ちいいよ、富美男」
富美男が俺のものを、そのごわごわとした手で優しく包み込む。
程良い締め付けと心地良い温もりで、思わず口元が緩んでしまう。
梅沢富美男「バカ野郎が……こういうのはどうだ？チロチロ…」
俺「うぁ…くっ…！！」
富美男が悪戯に亀頭の先端をチロチロと弄ぶ。屈強そうな外見には似つかわしくない、丁寧で繊細な舌使い。
あまりの気持ち良さに、射精感がぐぐぐっと高まるのを感じる。
梅沢富美男「…可愛い顔しやがるじゃあねえかこの野郎…そろそろ仕上げだ。ジュルジュル…ゴプッ！グポポ…ジュルジュルルル！グッポ！ブブブ…！」
俺「ひぁああ…！富美男！富美男ぉお！ぐっ…！！」
富美男が俺の股下で激しく上下する。俺のものはてらてらと光沢を帯び、上下運動を繰り返す度に富美男の唾液と俺の精液が混じり合った、ひどく性的な粘液が滴り落ちる。
限界までいきり立った俺のものは、欲望の全てを富美男の口内に解き放つ。
俺「ああはあっ…！！はあっ！はあ…はあっはあ……！富美男…富美男良かったよ…」
梅沢富美男「…ゴクンッ！……はあっはあっ…てめぇこの野郎！こんなにも一杯出しやがってバカ野郎…腹ん中パンパンじゃねえか…！！…まだ出したりねえよな？」
俺「…富美男には全てお見通しか。敵わないよ、お前には…」
梅沢富美男「当然だバカ野郎…ここからが本当の夢芝居だ」
俺と富美男は、夜が明けるまで、何度もなんどもお互いを求め合った。 >>912
ありがとうございます。保存させていただきました。 俺「ああ…すごく気持ちいいよ、富美男」
富美男が俺のものを、そのごわごわとした手で優しく包み込む。
程良い締め付けと心地良い温もりで、思わず口元が緩んでしまう。
梅沢富美男「バカ野郎が……こういうのはどうだ？チロチロ…」
俺「うぁ…くっ…！！」
富美男が悪戯に亀頭の先端をチロチロと弄ぶ。屈強そうな外見には似つかわしくない、丁寧で繊細な舌使い。
あまりの気持ち良さに、射精感がぐぐぐっと高まるのを感じる。
梅沢富美男「…可愛い顔しやがるじゃあねえかこの野郎…そろそろ仕上げだ。ジュルジュル…ゴプッ！グポポ…ジュルジュルルル！グッポ！ブブブ…！」
俺「ひぁああ…！富美男！富美男ぉお！ぐっ…！！」
富美男が俺の股下で激しく上下する。俺のものはてらてらと光沢を帯び、上下運動を繰り返す度に富美男の唾液と俺の精液が混じり合った、ひどく性的な粘液が滴り落ちる。
限界までいきり立った俺のものは、欲望の全てを富美男の口内に解き放つ。
俺「ああはあっ…！！はあっ！はあ…はあっはあ……！富美男…富美男良かったよ…」
梅沢富美男「…ゴクンッ！……はあっはあっ…てめぇこの野郎！こんなにも一杯出しやがってバカ野郎…腹ん中パンパンじゃねえか…！！…まだ出したりねえよな？」
俺「…富美男には全てお見通しか。敵わないよ、お前には…」
梅沢富美男「当然だバカ野郎…ここからが本当の夢芝居だ」
俺と富美男は、夜が明けるまで、何度もなんどもお互いを求め合った。 本番データの登録でseederは草
普通にsql使えよｗ seederのほうがlaravelのみで管理できるからそっちのほうがいいと思うけど
sqlだとそのsqlファイルをpublicとかに配置しないといけないよね？ >>918
多分ネタだろうから相手にしないほうがいいぞ
本気で言ってるなら理由を書くからな
ネタで言ってるやつはみんな理由を書かない
このスレの掟な >>918
別にpublicに配置する必要なくね？
mysqlに接続して用意しておいたSQL実行すればいいやん
別にseederでも問題ないと思うけどね
俺は開発用のデータとごっちゃになるからやらんけど すみません教えてください
laravelを使っていてcakephpにしかない機能が使いたい場合があります
その場合laravelにcakephpをcomposerでインストールすれば
cakephpでlaravelが使えるようになりますか？ laravelでcakephpを使えるようになるかということでござったが
くっ…書き間違いをしてしまったようでござるな…
失敬！ﾄﾞﾋｭｰﾝ その機能の具体的なパッケージ名やクラス名を書いてくれないと答えようがないと思うんだが…w
まぁ解決したようだし良いか では自分も質問です
Laravelを選ぶ利用の一つとして、フレームワークが持つ豊富な機能と、
静的メソッドに見えるファサードという記法がみやすく、分かり易いEloquentORMという点が挙げられると思います。
このEloquentとファサードは賛否いろいろ意見はありますが、
アプリケーションのモックや、小規模アプリケーションでは使い勝手が良く、
ある程度動かすところまで開発するには大変便利だと思います。
複数人で開発を行い、長期的に運用、保守していかなければならないような場合に、この機能とどう付き合っていくべきでしょうか？
ベストプラクティスがあれば教えてください >>927
具体的な問題点と期待値は何ですか？
それとも感想が欲しいだけ？ >>927
ベストプラクティスなんて無いぞ。ある程度の規模の開発ではeloquentとファサード使うな！はアイスタイルってスタートアップが提唱してたけど、単に杜撰な設計をFWの機能のせいにしているだけかなって。
むしろヤバいのは、モデルクラスの便利機能だな。アクセサとミューテータ。ここは容易にカオスになっていく。 eloquent使うなと言うのは乱暴だよなぁ
それなら別のフレームワークでええやんと思う レス数が900を超えています。1000を超えると表示できなくなるよ。
