先ほど2.xで重要なセキュリティ修正がリリースされました。特に admin_ のような prefix ルーティングを行っている人は必ず適応してください。
リリースのない2.5未満のバージョンを使っている人は差分を見て自力でホットフィクスを行ってください。

>>551 パッチは「適応」じゃなくて「適用」するものな。
まァ、12時間前の俺なんだけど。てか、しばらく来ないうちに過疎りすぎだろ。

>>551
いつもいつもありがとうございます

>>553 どういたしまして

ちなみに今回みたいなセキュリティバグはどうやって見つけてるんですか？
運用で発覚してるのか、それともコードレビューで見つけてるのか。。、

コードレビューですね。レビュー会をやっているわけではなくて個人的に。
人が書いたコードを読むのは勉強になるので。

>>555
コード見ずにテストする方法では検出が不可能か、極めて難しい問題ってのが有るんだよ。
そして負荷が高くなった時とかまれにしか発生しないが重大な問題になりがち。

だからコードを見ないでテストすることにも一定の意味はあるが、
コードを見て問題点を探す作業、つまり>>556もいってるコードレビューね。
これは 絶対に 省くことは出来ない。

コードレビューを軽視して、仕様ばっかり見ているような所はダメなところだよ。

んで、コードレビューという作業は、他人の書いた難解なコードを解読する 作業じゃない。
っていうかそんなの馬鹿じゃない？

Aさん「難しい問題作りました！」
Bさん「難しい。うーん、うーん。あっ分かった！」

お前ら、謎解き合戦でもして遊んでるのか？ それで誰が喜ぶんだ？って。

読めないコードは、読む人の技術不足じゃない。書く人の技術不足だ。
読めなければ書き直しを言い渡して良い。
（もちろん言語の文法が理解できないっていうのは、読む人の技術不足。
文法がわからないからっていうのは、書き直しの理由にはならない）

>>557
自分立ち入りで書いたソースならコードレビューするけど、さすがにフレームワークはしないでしょ。
今回みたいに興味があってするとか、運用で問題発覚して解析するというのは別として。

基本的にアップデートってそのまま上書きしたらいいの？
何か使えなくなるコードがあったりしない？

>>559
俺も思う。だから俺は何もしない。

composer を使っていなければ lib/Cake 以下を上書き。
2.6.0 -> 2.6.9 みたいな同じマイナーバージョンならそれほど問題は起きないはず。そうじゃない場合は、公式にあるマイグレート手順の通りにすればそれほど問題は起きないはず。
ただ、prefix でルーティングしてる場合は多少バグってでも上げるべきかな。

>>561
その、それほど問題は起きないはずってのが怖いよね。万が一バグったらそのままのがよかったじゃんってなる。

>> 562
1. prefix ルーティングを使用している
2. 'prefix' => 'admin' なら admins テーブルからログインユーザーを探す、といった prefix キーに依存した認証処理になっている
3. その認証の結果アクセスできるはずの admin_系の画面を第三者に利用されると困る

3つ全部に該当する場合に問題になるので、バグが起きた場合のリスクと、admin_系の画面を不正に利用された場合のリスクを考えて選択するといいかも。
同時に報告したもう一つの脆弱性は正直大したことじゃないので。
もっとも、クリティカルなフィールドの検証に range か comparison を使ってなければの話だけど。

過去作った1.3系を最新の1.3.20にアップデートしたいと思うけど
何か問題起きないか不安だ。どんな機能が更新されたのかいまいち情報ないし。

>>564 各リリースノートに更新内容が書いてある。ずいぶん前に作ったままなら、少なくとも削除と更新が同時に走ると全データがUPDATEされる不具合が2.xからバックポートされてるはず。

>>565 不具合の修正が、ね。不具合バックポートしてどうすんだ。

特定のサイトにアクセスをした際に
リファラを書き換える事って出来ますか？


AAAというサイトへアクセスを想定しています。

実際には、Yahooで検索して遷移したとします。
しかし、AAAのサーバ側では「Googleからのリファラであった」と見せかけるにはどうした良いですか？

リファラを送出してるのはブラウザであってCakeは関係ない

>>568
どうやったらリファラ偽装できるの？

そもそもなんで偽装したいんだよ

>>569
ブラウザ依存の話だからスレ違いどころか板違いだ
使ってるブラウザのスレ見つけてそっちで聞いてこい

2.xまでですっかり配列脳に染まった自分。
3.0からのオブジェクト返しにちょっと慣れずにいます。

今まではリレーションされたレコードを含めて配列で一気に取ってきておいて、
あとは巨大な配列をブンブン回して処理していたのを、
ある程度Entityに分担させられるようになる（Lazy loading）って認識でいいのかな？

あとは、DBからコードの形で取得したデータを
対応する文字列に置き換えたりっていうような処理を
自分はHelperとかにやらせてたりしたけれど、それもEntityにやらせる方が良かったりする？

http://api.cakephp.org/2.5/class-App.html#_import
http://api.cakephp.org/2.5/class-App.html#_uses
まずAPIドキュメントを見るんだ
書いてあるとおりクラス名だ importの方はいろいろ柔軟だけれども

原則としては１クラス１ファイルだが、特定のクラスからだけしか参照しない
内部クラス的なものはそのクラスと同じファイルにまとめてしまうことはあるな

APIドキュメントのApp::import()の方に
　string $name optional null
　Name of the Class or a unique name for the file
って書いてあるけどファイルでもいいってこと？

Lib/Hoge.phpに
<?php
class Hoge1 {}
class Hoge2 {}

とか作って
App::import('Lib', 'Hoge');
すれば Hoge1 も Hoge2 も使える？

そういう話ならこっち読んだほうがいい
http://book.cakephp.org/2.0/ja/core-utility-libraries/app.html

２つ目はできるかできないかならできるが、インスタンス化はもちろん自前でやらなければならない
単にimport書くのが面倒だという理由ならやめた方がいい

>>578
thx
こういうのって普通の使い方は書いてあるけど
「じゃあ、こういう使い方はできるの？」ってのには触れてないんだよね。
言語の基礎的なことなら自分で試せばいいんだけど、フレームワークが間に入ってると
そもそもできないのか、自分の使い方が悪いのかが切り分けにくいし。

独自例外クラスとかほとんど空なのに個別にファイルつくるのは面倒だから
1ファイルにまとめたかった。
Javaとかなら1ファイル1クラス(非ネストクラス)って決まってるから諦めつくんだけど。

App::importは基本的にはApp::build()で登録済みのpathを探しに行く
登録済みのpathにあるファイルなら、クラス名＝ファイル名ならクラス名だけで解決できる
path登録してないなら明示的にpathを特定してimportすることになる
e.g. App::import('File', 'MyClass', array('file' => '/path/to/MyFile.php'));
App::uses()使ったほうが遅延読み込みしてくれるし、IDEの補完やメンテナンスのことも
考えれば（書いた本人が直すとは限らない）規約に従って作っておいたほうが、最終的にはスムーズ

今から作るなら3なんかなぁ
2でちょっと作りかけたコードがあるが、今ならまだ移行できる

.
.
.
Σ(Д・;)"プチエンジェル事件"！(小学生売春事件)
▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼
プチエンジェル事件に隠された日本の闇を暴露する！

■実は、『女性皇族』の『男遊び』と、
　女性皇族がおこなったハニートラップだった！！

■その『男遊び』と『トラップ』を誤魔化す為の、
『プチエンジェル事件』が真相だったのだ！！

■闇に包まれた真相を、私が『暴露』する！！

※知る覚悟はできていますか？
下記を『Google』か『Yahoo』で検索して下さい。

～～～～～～～～～～～～～～～～～～～～～～～
検索⇒『佳子様　真子さま　kare氏』
～～～～～～～～～～～～～～～～～～～～～～～

※上記で検索しますと、１ページ目の５番目以内に、

【懇約〕秋篠宮家の佳子様と･･･････
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑が表示されます。

※世の中、知らない方が良い事もあるんです・・・。
▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲
.
.
.

Cake3でちょこっと作ったけど情報が少ないな
日本では流行らない気がする

２までと比べて作りやすくなったから俺は好き

あと2，3年は2で行けるはず。全然情報ないし、2の開発も続いてるしな。

そう言えば最近、ようやくぐぐっても1の情報ばかりということがなくなったな
あれホントうざかった
3を始める人はまたその状況が続くんだな

>>587 一般論としてグローバル関数／定数には

■名前衝突のリスクが高い
PHP本体のバージョンアップや、サードパーティのライブラリとの共存で問題が生じる可能性がある。

■オートロードできない
使われないかもしれない関数／定数であっても予め定義しておかなければならず、パフォーマンスが低下する。

という欠点があるので削減していく方向なのだろう。
と思っていたけれど、stackTrace() のように3系になってから新たに導入された前例があるので何とも言えない。
ちなみに導入された理由は Cake\Error\Debugger を毎回書くのに疲れたから。

>>587
どうしてミグラチオンしないのよーッ！！

Cakeのページネーションで、
$this->Paginator->settings = [
'limit' => 10,
'order' => [ 'created' => 'asc' ]
];
みたいに指定すると、ビューのページネーションのリンクに
sort:Model.created/direction:asc
みたいなのが付くんですが、これを付けないようにする方法ありませんか？
orderは 'created' => 'asc'で固定にしたいです。

>>594
コントローラーでrenderする時のパスって、appを分けてる場合はどうなるのですか？
普通に絶対パスを書くのですか？

>>596
ごめん。
appわけたことないからわかりません。

>>596
俺も分けたことないけど App::build() はどう？

>>598-599
横だけど、appわけないって、管理画面と公開画面作る時どうしてるの？
prefixで対応してるの？それだと困らない？