元スレ【PHP】Laravel【フレームワーク】 Part.4

php覧 / PC版 /

みんなの評価 :

前へ 1 2 3 4 5 6 7 8 9 10 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

101 = :

>>100
それでいいんじゃないの？
想定してない画面遷移はそもそも想定外なんだから、想定外が起きないようにガチガチに制御するのは普通だと思う。
逆に許容できるケースのほうが珍しいんじゃないか？

102 = :

みなさん二重にPOSTされてしまった時の対策ってどうしてますか？
やっぱりボタン押されたらJSでボタンを非活性にするほうがいいんですかね

103 = :

>>102
>>63と同じ荒らしか

105 = :

使わないとテストできないのでは？別の選択肢としてPestもあるけど、わざわざインストールしないしねー。

106 = :

自動テスト使わないとリファクタリングしにくいもんね。
Laravel本体はテストコード無いけどSymfonyとかはテストコード入ってるね

107 = :

>>106
「Laravel本体はテストコードが無い」の意味が分からない
え？君大丈夫？
http://github.com/laravel/framework/tree/8.x/tests

108 = :

>>107
コンポーザーで入れたらテストコード入ってないよ

109 = :

ぶっちゃけ仕事で作るプロダクトはテストコード書いたことがない
客がそこまでの予算出さないからな
こっちは納品して終わりだし、納期もカツカツでテスト書く時間がない、たまには書いてみたい

110 = :

>>108
Laravel本体にテストコードが無いという指摘はどういう問題につながってるの？まさか、Laravel本体のテストも手元で実行したいのか・・・な？

111 = :

>>110
Laravel本体にテストコードが無い
じゃなくて
コンポーザーで入れたLaravel本体にテストコードが入ってない
ってことだよ。適当に流しときなよ

112 = :

>>111
そういう話では無いでしょ。>>106も踏まえての話だから。そもそもComposerでもLaravel Installerでも本体のテストコードなんて入ってこないよ。

なのでコイツは何言ってんだろ？てことで尋ねているのよ。

113 = :

>>108
君は106と同じ人？

114 :

変なテスト仕様書は書かされるのに

115 = :

お前らってLaravelをバックエンドにしたときフロントエンドってどうしてる？
laravel-mixで構築して同一プロジェクトに含めてる？
それとも@vue/cli等フロントエンドJSが提供しているツールでフロントエンド用の
プロジェクト作ってる？

116 = :

>>115
後者
laravel-mix使うメリット無いわ
あれ使ったらフロントとバックエンドを強制的に同じサーバーで動かす必要あるし

117 = :

>>116
>フロントとバックエンドを強制的に同じサーバーで動かす必要あるし
小規模プロジェクト一人でやってるからウチはそっちの方がいい

118 = :

SPAはフロントとバックを分離できるのがメリットだからlaravel-mixは使わないなー

>>117
同じサーバーでも動かせるよ

119 = :

>>115
俺は前者
前者が普通じゃないのか？

121 = :

基本的にはLaravel-Mixを使うのが普通だね

122 = :

普通ではないと思う

123 = :

>>122
エアプか？

124 = :

何か海外でlaravelの.envを読み取るツールがあるらしくて
.envに記載してるメールのID、PWを抜かれてSPAMに使われてるみたいです
APP_ENV=trueになってると狙われるそうです

125 = :

>>121
君の狭い世界では普通なだけで、その他大勢の中では普通とは限らないのでは

126 = :

APP_ENV=trueって何だよ
APP_DEBUGじゃなくて？

127 = :

>>126
ソース貼ってないし相手にするだけ無駄

128 = :

>>126
この脆弱性はAPP_ENV=trueであってる
もう修正済みだけどissuesを見るんだ

129 = :

>>124
「メールのID、PW」とは？
SMTPサーバーのユーザー名とパスワード、であってるのかな？

>>128
君は>>124と同じ人？
いつ頃のバージョンで修正されてるの？

130 = :

このスレよく虚言癖の来るからあんま相手にしないほうがいいぞ
前スレも「laravelはjsonの取り扱い方に脆弱性がある」とか一切ソース貼らずに騒いでるのやつがたくさん（一人の自演？）居たし

131 = :

ホントだ、issues見たけどそんなのないや
デマ流して何がしたいんだよそういう病気なのか

137 = :

公開ディレクトリに.envを置くって状況が想像付かんのだが
どういう理由でそういうことになるんだろう

140 = :

publicディレクトリの中に置かないのにどうして読み取れるの？

141 = :

まさかドキュメントルートの中に置いてないよね？

142 = :

>>140
Webサーバーで/をapp/public/にマッピングするのが昨今一般的なやり方だが
未だに
/var/www/html/app/public/
や
/usr/share/nginx/html/app/public/
にプロジェクトを置いてデフォルトルートからサブディレクトリにアクセスしてるんなら
ザルとは言わんまでも～/html/app/ディレクトリの存在は筒抜けじゃね？

143 = :

環境変数定義を公開ディレクトリに置くとか怖すぎ

144 = :

>>142
そうなんだよな、それをやったら.envどころかプロジェクト全体丸見え
特殊ツールなんていらんしsmtp crackどころではない全情報取れる

145 = :

laravelはサブディレクトリに設置する前提ではないので
運用方法を間違えてる人の人的ミス

146 = :

.env絡みで別の話だけど.envをソース管理にコミットする？
しないのが普通だろうが俺は.envで管理する情報追加の履歴も取りたいからコミットしてるんだけど

147 = :

githubとかの公開設定ミスったら終わりだぞ
そもそも.envは環境によって違うし
設定例として履歴残したいなら.exampleでええやん
今は機密情報を本番サーバーに置くことすらしたくないと言うことで、実行時にシークレットマネージャーとかから取得する時代だしね

148 = :

そういうファイルをコミットするバカは消えるべき