のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:126,368,550人
昨日:no data人
今日:
最近の注目
人気の最安値情報

    元スレ[PHP][フレームワーク]CodeIgniterスレ

    php覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : - Rapyd + 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

    201 = :

    >>199
    CodeIgniterなら、テンプレートファイルに無理やりロジック(PHPコード)を入れられるんじゃないですか?

    http://userguide.cilab.info/general/alternative_php.html
    CodeIgniter の テンプレートエンジンを利用したくない場合は、ビューファイルで純粋なPHPを利用することができます。

    202 :

    CIってセッションデータ(非セッションID)をクッキーに格納するって読んだんだけどマジ?
    クッキーなんて4Kくらいしかないし
    それほど安全でもないし
    毎回送信されるしでありえないんだが…

    203 = :

    どこで読んだんだ?

    204 = :

    いろんなところで。たとえばこれとか。
    http://lists.sourceforge.jp/mailman/archives/codeigniter-users/2007-December/000048.html

    205 = :

    >>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独自セッションのまずい点は色々なサイトに載っているからあさって調べてみて・・・。
    俺も、だいぶ前に調べたから・・・。

    206 = :

    >>202
    DBに保存する方法もあるよ。

    207 = :

    >>205
    クッキーに入れるなんて解決になってないよ・・・
    珍妙としか言いようがない実装

    209 = :

    まじで?

    210 = :

    >>209
    うん
    cookieに突っ込むsession内容全体のdigestをアプリ固有のキーで生成して
    そのdigest自体もcookieに入れておいて、サーバ側で受け付けた時には
    そのdigestを検証して信用できるかどうかを調べてOKなら受け入れる、
    という感じの実装みたい

    211 :

    >digestを検証して信用できるかどうかを調べてOKなら受け入れる

    ここがほんとに安全なら楽になるな。
    ユーザ側保存に不安があって自前で作るの面倒だったから。

    212 = :

    でもさクッキーの容量は4Kしかないんだろ?
    それに携帯だったらどうするんだ?
    クッキー使える機種だとしても、一アクセスごとに
    最大4Kものパケット料がかかるよな?

    213 = 211 :

    urlにセッションidくっつけるやりかたが、ユーザ会のサイトに載ってたな。

    あと、バリデート済みのPOSTデータをセッションにつっこんで、
    確認ボタン押したらそのままinsertとかができなくなるね。
    データを一度ユーザ側に預けちゃってるわけだし。おっかない。

    214 = 211 :

    あ、セッションの内容をもういっかいバリデートすりゃいいだけだ。
    吊ってきます。

    215 = :

    >>207
    CIもただCookieに単純に入れてOKとしてるわけじゃなかったと思うよ。
    セッションの信頼性のチェックとかしてたと思う。

    216 = :

    PHP固有SESSIONの仕様に問題があるから独自セッションまがいの機能をCookie等を使って作ったり、
    「PHPSESSIONID」をそのまま信用するようなことをしない対処を行うのはセキュリティ上今のPHPでは必要だと思うのだが。

    それをやりやすくCIがやってくれていたはず。
    DB使った場合だけだったかも知れないけど・・・。

    217 = :

    >>212
    だからそういう携帯や4k超えるような
    でかいセッションファイル抱えるような場合は
    ファイルやDBのセッション使えばいいって事

    でも基本はセッションで扱うデータ量なんてしれてるし、
    だったらcookieだけでやってしまえばいいんじゃね、って事

    218 = :

    kohanaってもう実用レベルに達してるの?

    219 = :

    http://kohanaphp.com/tutorials/video/hello_world.html
    コハナじゃなくてクワナって言ってるな

    221 = :

    >>210
    ダイジェスト生成のロジックが割れたら
    いじったデータをセッションに入れられるかもしれない
    ユーザには知られたくないデータをセッションに入れることもありうるから
    やっぱり抵抗あるなー

    222 = :

    http://d.hatena.ne.jp/stilo/20080123/p2
    ciの本が出るらしい
    売れるのかな…?
    個人的には好きだが

    223 = :

    例外投げてもほったらかしじゃん
    PHP4なんて脂肪してんのに
    ハンドリングするのエラーだけってどんだけ~

    226 :

    >>217
    扱うデータ量なんてしれてるならsessionの方がいいよ
    cookieを使う利点はサーバー側に負荷がかからないことだよ
    扱うテータ量が多いほどcookieを使えばサーバー負荷にならないんだよ

    227 = :

    cookieをやり取りする為の
    データ転送量が増えるけどな。

    228 = :

    でも携帯と別処理にしたら汚くならないか?

    230 = :

    流行ってないね

    231 = :

    CIの本っていつでるんだ?春にでるみたいだけど心待ちにしてる。

    232 = :

    >>231
    オンラインマニュアルに載ってる事に補足を加えてウダウダ書いてるだけ

    233 = :

    まあオンラインマニュアル充実してるし、
    機能もシンプルだしねぇ

    234 = :

    でもなぁ。MVCで一番重要なモデルが軽視されているからなぁ。
    まあ小規模向けだね。

    235 = :

    ???
    どのあたりでモデルが軽視されていると思ったの?

    236 = :

    必須じゃないってとこじゃない?
    わからんけど

    237 = :

    安定版にならないとあんまり使う気にならないんだよなあ。
    VerUPが頻繁だと遊ぶ分には楽しいけど実務じゃちょっと。

    238 = :

    今でも結構安定してね?

    240 = :

    >>238
    いや、安定してないと言ってるわけじゃないんだけど
    更新が頻繁だと嬉しくもあるけどあんまり業務で使いたいと思わなくね?
    あまりにも更新が頻繁=すぐ修正されるような問題点がまだまだある
    と思えるし。
    更新しないから安定してるってわけじゃないけどね。
    中身バグだらけだけどただ単に更新止まってるだけとかあるし。
    機能の追加の更新ならともかく、あんまり頻繁にBugFixで更新多いと心配になる。
    致命的なのがあって、それを更新したから業務で使ってるのも更新しなきゃ→動かなくなった
    とかが一番困るし。

    241 = :

    >>240
    リリースの頻度で安定している、していないを判定しているやつは素人
    中身で判断しろ

    修正でも不具合でも深刻具合による
    リリーススケジュールの話ならここでしても無駄だ
    本家で議論してこい

    242 = :

    >>241
    お前はもう少し>>240の書き込みをよく読め。
    文盲か。
    リリースの頻度で安定度してるかどうかを判断してるなんて書いていないだろ。

    243 = :

    >あまりにも更新が頻繁=すぐ修正されるような問題点がまだまだある

    これを書いている時点で何もわかっちゃないだろ

    244 = :

    >>242
    オマエこそもう少し文章の書き方を考えたら?w

    245 = :

    ペチパーの質を物語っていますね。とか言われるぞ。
    もうちょっと温厚になれないのか。

    246 = :

    ぺちぱーだもの
       みつを

    247 = :

    静かなこのスレが更新されていた!
    と見に来たあなた。

    書き込んでいるのは俺ですよ! 俺!

    中身は何にもありません。ざーんねーんw

    248 = :

    いくつかご相談

    1, CIってモデルはオマケと言われてるけど、
    CLIベースでモデル開発して、あとはコントローラから呼び出すというスタイルは
    一般的ではない?
    理由:モデルの開発をわざわざCI上でやりたくない

    2, プラグインからモデルのデータセット取得して表示を返すようにしておいて、
    それをビュー上で呼び出すようにしようかと思うのだけど、無作法?
    理由:表示を構築するだけのコードだったらコントローラに書きたくない

    3, 定義されてないコントローラクラスがURIセグメントで指定されたら
    「クラス名.html」を自動的に表示する方法ってない?
    理由:ロジックがないページまでわざわざコントローラを定義するのは面倒

    250 = :

    CIだったら、フレームワークとアプリ機能の実装を分離した状態で開発して
    後から乗っけるだけでいいのかなあと思ってたけど、
    CIでもできる限りフレームワークの流儀には沿うのね。

    確かに、自分がご相談で書いた内容は、
    他人がメンテする上で解読が困難になるか・・・


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : - Rapyd + 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド


    トップメニューへ / →のくす牧場書庫について