アカウント名:
パスワード:
応急処置として、これだけ実施する機転が利くと良いのですが…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
apacheだとすると (スコア:1)
# 対策のために鯖を増強する金が惜しいというのが本音なような気がする。
Re:apacheだとすると (スコア:1, 興味深い)
http://mixi.jp/show_picture.pl?img_src=http://ic**.mixi.jp/photo/diary... [mixi.jp]
みたいに、cgiを介してるんですよねえ。
なのに、パラメータ指定されているURLに直接アクセスできる謎仕様。
Re:apacheだとすると (スコア:2, おもしろおかしい)
/* Kachou Utumi
I'm Not Rich... */
Re:apacheだとすると (スコア:1)
# その場合QUERY_STRINGは空になってるから代わりにURLの方をパースする。
その場合の処理って軽いの？ (スコア:2)
1. クッキーよりセッションキーを取得
2. セッションキーよりユーザーIDを取得
3. ユーザーIDに基づき、可視性を判断
3-1. 画像のURL (path) より表示されている場所を特定
3-2. 表示されている場所がコミュニティの場合
3-2-1. if (コミュニティが公開されている) 表示
3-2-2. else if (コミュニティにユーザーIDが属している) 表示
3-2-3. else 不表示
3-3. 表示されている場所がユーザースペースの場合
3-3-1. if (ユーザースペースは画像を公開する設定) 表示
3-3-2. ユーザーIDとユーザースペース所有者の関係の特定
3-3-3. if (ユーザーIDとユーザースペース所有者が友人の場合) 表示
3-3-4. ユーザーIDとユーザースペース所有者が友人の友人の場合
3-3-4-1. if (ユーザースペース所有者は友人の友人に表示を許可している) 表示
3-3-4-2. else 非表示
...というのを日記やプロフィール表示の場合は毎回やりますが、それを画像にまで広げるとさすがに負荷が高くなり過ぎないですかね？
URLの類推可能性はそんなに高くなく、画像が格納される場所のURL空間もかなり広いので脆弱ではあってもそんなに大きな問題にはならないのではないかと思うのですよね。
ここを保護してもダウンロードしてバラまかれたら意味ないわけですし。
もちろん、mixi運営部にもわかるようなブルートフォース攻撃をかければmixi内の全ての画像はゲットできますが、それには404 not foundを連続して出しているIPアドレスにペナルティを課す等の別の対策で十分何とかなるのではないかと思います。
Re:その場合の処理って軽いの？ (スコア:1)
応急処置として、これだけ実施する機転が利くと良いのですが…
Re:その場合の処理って軽いの？ (スコア:0)
Re:その場合の処理って軽いの？ (スコア:0)
そこまで考えないといかんがな。(塵山)
Re:その場合の処理って軽いの？ (スコア:0)
Re:apacheだとすると (スコア:0)
Re:apacheだとすると (スコア:1)
そしてたぶん見えなくすると特定ブラウザでログインできなくなるという謎仕様。