私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ[PHP][フレームワーク]CodeIgniterスレ
php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 : ○
レスフィルター : (試験中)
>>199
CodeIgniterなら、テンプレートファイルに無理やりロジック(PHPコード)を入れられるんじゃないですか?
http://userguide.cilab.info/general/alternative_php.html
CodeIgniter の テンプレートエンジンを利用したくない場合は、ビューファイルで純粋なPHPを利用することができます。
CodeIgniterなら、テンプレートファイルに無理やりロジック(PHPコード)を入れられるんじゃないですか?
http://userguide.cilab.info/general/alternative_php.html
CodeIgniter の テンプレートエンジンを利用したくない場合は、ビューファイルで純粋なPHPを利用することができます。
CIってセッションデータ(非セッションID)をクッキーに格納するって読んだんだけどマジ?
クッキーなんて4Kくらいしかないし
それほど安全でもないし
毎回送信されるしでありえないんだが…
クッキーなんて4Kくらいしかないし
それほど安全でもないし
毎回送信されるしでありえないんだが…
>>202
PHP独自セッションは、スケーラビリティを考慮されていない設計になっていることと、
セキュリティの問題の2点からCIでは独自のセッションデータを保持するようにしていると思われる。
簡単に言うと、(うそ書いてるかも知れないからごめんね、一応自分で調べてみてください)
1.スケーラビリティの考慮漏れ
PHPはセッションデータをサーバの内部に保存する為、負荷分散を考えてサーバを2台に増設したと仮定した場合、
直接アクセスがあった1台のサーバには対象ユーザーのセッションデータが保存され、
もう一方のサーバにはセッションデータが保存されない、負荷分散時のロードバランサー、サーバなどの設定によっては、
2つのサーバ同士でセッションデータ共有がされずにセッション情報がうまく引き継がれない可能性がある。
なので、PHPのセッションを利用しているときに1度目と2度目のユーザーのアクセスが異なるサーバに行った場合にセッションデータが引き継がれない・・・。
2.セキュリティの観点
PHPSESSIONID(こんなんだったけ?)をキーにサーバにセッションデータを登録するから
適当な値で他人のセッションデータが簡単に盗めてしまう可能性がある。(改善されたのかな?)
例えば、ログイン情報をセッションに持っている作りのサイトで、
「http://????.com/login.php?PHPSESSIONID=aaaa」見たいなリンクが張られていてこのリンクをたどってログインした場合に、
他人が「http://????.com/info.php?PHPSESSIONID=aaaa」とアクセスすると
セッションタイムアウトが発生していない限り他人のセッション(この場合「aaaa」というPHPSESSIONIDでログインした人のセッション)をのっとる事が出来る脆弱性があってこれについて、
独自に解決をしていると思われる。
たしか、こんな感じだったと思う。
間違えているかもしれないので、申し訳ないですがPHP独自セッションのまずい点は色々なサイトに載っているからあさって調べてみて・・・。
俺も、だいぶ前に調べたから・・・。
PHP独自セッションは、スケーラビリティを考慮されていない設計になっていることと、
セキュリティの問題の2点からCIでは独自のセッションデータを保持するようにしていると思われる。
簡単に言うと、(うそ書いてるかも知れないからごめんね、一応自分で調べてみてください)
1.スケーラビリティの考慮漏れ
PHPはセッションデータをサーバの内部に保存する為、負荷分散を考えてサーバを2台に増設したと仮定した場合、
直接アクセスがあった1台のサーバには対象ユーザーのセッションデータが保存され、
もう一方のサーバにはセッションデータが保存されない、負荷分散時のロードバランサー、サーバなどの設定によっては、
2つのサーバ同士でセッションデータ共有がされずにセッション情報がうまく引き継がれない可能性がある。
なので、PHPのセッションを利用しているときに1度目と2度目のユーザーのアクセスが異なるサーバに行った場合にセッションデータが引き継がれない・・・。
2.セキュリティの観点
PHPSESSIONID(こんなんだったけ?)をキーにサーバにセッションデータを登録するから
適当な値で他人のセッションデータが簡単に盗めてしまう可能性がある。(改善されたのかな?)
例えば、ログイン情報をセッションに持っている作りのサイトで、
「http://????.com/login.php?PHPSESSIONID=aaaa」見たいなリンクが張られていてこのリンクをたどってログインした場合に、
他人が「http://????.com/info.php?PHPSESSIONID=aaaa」とアクセスすると
セッションタイムアウトが発生していない限り他人のセッション(この場合「aaaa」というPHPSESSIONIDでログインした人のセッション)をのっとる事が出来る脆弱性があってこれについて、
独自に解決をしていると思われる。
たしか、こんな感じだったと思う。
間違えているかもしれないので、申し訳ないですがPHP独自セッションのまずい点は色々なサイトに載っているからあさって調べてみて・・・。
俺も、だいぶ前に調べたから・・・。
>>202
DBに保存する方法もあるよ。
DBに保存する方法もあるよ。
一方、railsは2.0からデフォルトで
cookieにセッション情報を格納するようにした
cookieにセッション情報を格納するようにした
>>209
うん
cookieに突っ込むsession内容全体のdigestをアプリ固有のキーで生成して
そのdigest自体もcookieに入れておいて、サーバ側で受け付けた時には
そのdigestを検証して信用できるかどうかを調べてOKなら受け入れる、
という感じの実装みたい
うん
cookieに突っ込むsession内容全体のdigestをアプリ固有のキーで生成して
そのdigest自体もcookieに入れておいて、サーバ側で受け付けた時には
そのdigestを検証して信用できるかどうかを調べてOKなら受け入れる、
という感じの実装みたい
>digestを検証して信用できるかどうかを調べてOKなら受け入れる
ここがほんとに安全なら楽になるな。
ユーザ側保存に不安があって自前で作るの面倒だったから。
ここがほんとに安全なら楽になるな。
ユーザ側保存に不安があって自前で作るの面倒だったから。
でもさクッキーの容量は4Kしかないんだろ?
それに携帯だったらどうするんだ?
クッキー使える機種だとしても、一アクセスごとに
最大4Kものパケット料がかかるよな?
それに携帯だったらどうするんだ?
クッキー使える機種だとしても、一アクセスごとに
最大4Kものパケット料がかかるよな?
urlにセッションidくっつけるやりかたが、ユーザ会のサイトに載ってたな。
あと、バリデート済みのPOSTデータをセッションにつっこんで、
確認ボタン押したらそのままinsertとかができなくなるね。
データを一度ユーザ側に預けちゃってるわけだし。おっかない。
あと、バリデート済みのPOSTデータをセッションにつっこんで、
確認ボタン押したらそのままinsertとかができなくなるね。
データを一度ユーザ側に預けちゃってるわけだし。おっかない。
あ、セッションの内容をもういっかいバリデートすりゃいいだけだ。
吊ってきます。
吊ってきます。
PHP固有SESSIONの仕様に問題があるから独自セッションまがいの機能をCookie等を使って作ったり、
「PHPSESSIONID」をそのまま信用するようなことをしない対処を行うのはセキュリティ上今のPHPでは必要だと思うのだが。
それをやりやすくCIがやってくれていたはず。
DB使った場合だけだったかも知れないけど・・・。
「PHPSESSIONID」をそのまま信用するようなことをしない対処を行うのはセキュリティ上今のPHPでは必要だと思うのだが。
それをやりやすくCIがやってくれていたはず。
DB使った場合だけだったかも知れないけど・・・。
>>212
だからそういう携帯や4k超えるような
でかいセッションファイル抱えるような場合は
ファイルやDBのセッション使えばいいって事
でも基本はセッションで扱うデータ量なんてしれてるし、
だったらcookieだけでやってしまえばいいんじゃね、って事
だからそういう携帯や4k超えるような
でかいセッションファイル抱えるような場合は
ファイルやDBのセッション使えばいいって事
でも基本はセッションで扱うデータ量なんてしれてるし、
だったらcookieだけでやってしまえばいいんじゃね、って事
http://kohanaphp.com/tutorials/video/hello_world.html
コハナじゃなくてクワナって言ってるな
コハナじゃなくてクワナって言ってるな
config配下のファイルで
定数定義とかinclude_pathの設定するのはアリ?
ここで関数の定義とかまで出来ちゃうのがphpのすごいとこだけど
定数定義とかinclude_pathの設定するのはアリ?
ここで関数の定義とかまで出来ちゃうのがphpのすごいとこだけど
例外投げてもほったらかしじゃん
PHP4なんて脂肪してんのに
ハンドリングするのエラーだけってどんだけ~
PHP4なんて脂肪してんのに
ハンドリングするのエラーだけってどんだけ~
attachementのform mail、どうやってこさえてます?
なんだかんだ、uploadして一時ファイルをattacheさせてるんだけど。
もっといい方法ない?
なんだかんだ、uploadして一時ファイルをattacheさせてるんだけど。
もっといい方法ない?
>>217
扱うデータ量なんてしれてるならsessionの方がいいよ
cookieを使う利点はサーバー側に負荷がかからないことだよ
扱うテータ量が多いほどcookieを使えばサーバー負荷にならないんだよ
扱うデータ量なんてしれてるならsessionの方がいいよ
cookieを使う利点はサーバー側に負荷がかからないことだよ
扱うテータ量が多いほどcookieを使えばサーバー負荷にならないんだよ
>>231
オンラインマニュアルに載ってる事に補足を加えてウダウダ書いてるだけ
オンラインマニュアルに載ってる事に補足を加えてウダウダ書いてるだけ
でもなぁ。MVCで一番重要なモデルが軽視されているからなぁ。
まあ小規模向けだね。
まあ小規模向けだね。
安定版にならないとあんまり使う気にならないんだよなあ。
VerUPが頻繁だと遊ぶ分には楽しいけど実務じゃちょっと。
VerUPが頻繁だと遊ぶ分には楽しいけど実務じゃちょっと。
>>238
いや、安定してないと言ってるわけじゃないんだけど
更新が頻繁だと嬉しくもあるけどあんまり業務で使いたいと思わなくね?
あまりにも更新が頻繁=すぐ修正されるような問題点がまだまだある
と思えるし。
更新しないから安定してるってわけじゃないけどね。
中身バグだらけだけどただ単に更新止まってるだけとかあるし。
機能の追加の更新ならともかく、あんまり頻繁にBugFixで更新多いと心配になる。
致命的なのがあって、それを更新したから業務で使ってるのも更新しなきゃ→動かなくなった
とかが一番困るし。
いや、安定してないと言ってるわけじゃないんだけど
更新が頻繁だと嬉しくもあるけどあんまり業務で使いたいと思わなくね?
あまりにも更新が頻繁=すぐ修正されるような問題点がまだまだある
と思えるし。
更新しないから安定してるってわけじゃないけどね。
中身バグだらけだけどただ単に更新止まってるだけとかあるし。
機能の追加の更新ならともかく、あんまり頻繁にBugFixで更新多いと心配になる。
致命的なのがあって、それを更新したから業務で使ってるのも更新しなきゃ→動かなくなった
とかが一番困るし。
>あまりにも更新が頻繁=すぐ修正されるような問題点がまだまだある
これを書いている時点で何もわかっちゃないだろ
これを書いている時点で何もわかっちゃないだろ
>>242
オマエこそもう少し文章の書き方を考えたら?w
オマエこそもう少し文章の書き方を考えたら?w
ペチパーの質を物語っていますね。とか言われるぞ。
もうちょっと温厚になれないのか。
もうちょっと温厚になれないのか。
静かなこのスレが更新されていた!
と見に来たあなた。
書き込んでいるのは俺ですよ! 俺!
中身は何にもありません。ざーんねーんw
と見に来たあなた。
書き込んでいるのは俺ですよ! 俺!
中身は何にもありません。ざーんねーんw
いくつかご相談
1, CIってモデルはオマケと言われてるけど、
CLIベースでモデル開発して、あとはコントローラから呼び出すというスタイルは
一般的ではない?
理由:モデルの開発をわざわざCI上でやりたくない
2, プラグインからモデルのデータセット取得して表示を返すようにしておいて、
それをビュー上で呼び出すようにしようかと思うのだけど、無作法?
理由:表示を構築するだけのコードだったらコントローラに書きたくない
3, 定義されてないコントローラクラスがURIセグメントで指定されたら
「クラス名.html」を自動的に表示する方法ってない?
理由:ロジックがないページまでわざわざコントローラを定義するのは面倒
1, CIってモデルはオマケと言われてるけど、
CLIベースでモデル開発して、あとはコントローラから呼び出すというスタイルは
一般的ではない?
理由:モデルの開発をわざわざCI上でやりたくない
2, プラグインからモデルのデータセット取得して表示を返すようにしておいて、
それをビュー上で呼び出すようにしようかと思うのだけど、無作法?
理由:表示を構築するだけのコードだったらコントローラに書きたくない
3, 定義されてないコントローラクラスがURIセグメントで指定されたら
「クラス名.html」を自動的に表示する方法ってない?
理由:ロジックがないページまでわざわざコントローラを定義するのは面倒
CIだったら、フレームワークとアプリ機能の実装を分離した状態で開発して
後から乗っけるだけでいいのかなあと思ってたけど、
CIでもできる限りフレームワークの流儀には沿うのね。
確かに、自分がご相談で書いた内容は、
他人がメンテする上で解読が困難になるか・・・
後から乗っけるだけでいいのかなあと思ってたけど、
CIでもできる限りフレームワークの流儀には沿うのね。
確かに、自分がご相談で書いた内容は、
他人がメンテする上で解読が困難になるか・・・
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php スレッド一覧へ
みんなの評価 : ○類似してるかもしれないスレッド
- [PHP][フレームワーク]CodeIgniter Part2 (983) - [86%] - 2015/4/7 12:46
- 【PHP】フレームワークPharonスレ (306) - [60%] - 2022/10/10 20:00
- [PHPフレームワーク]Laravel (995) - [53%] - 2017/7/22 11:45
- 【PHP】PHPフレームワーク総合スレ14 (1001) - [50%] - 2010/12/11 10:32
- 【PHP】PHPフレームワーク総合スレ15 (989) - [50%] - 2013/9/27 6:00 △
- 【PHP】フレームワークMapleに舌鼓 (470) - [48%] - 2017/12/31 9:31
- 2ch有志がPHPフレームワークを作るスレ (81) - [45%] - 2019/5/9 7:46
トップメニューへ / →のくす牧場書庫について