We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 27086
    • 37 Posts
    こんにちは。

    ページの削除について少し奇妙な動作をするのですが、皆さんの環境でも同様でしょうか。

    1. Ver. 0.9.6において複数ユーザに対してそれぞれ専用のドキュメントやフォルダを用意してあげます。
    2. MODx設定の「インターフェースとその他の機能」にある「保護されたページの表示」をYesにします。
    3. 管理画面で何れかのユーザでログインします。権限の無いドキュメントもツリーに表示されています。
    4. 権限のないドキュメントをクリックすると警告が出てアクセスできませんが、ツリーでの右クリックメニューから削除は出来てしまいます。

    これはマズイですよね。。。まだ調べていませんが、削除処理の時に権限を調べていないんでしょうかね?
      • 19033
      • 892 Posts
      こんにちは。
      もう少し具体的に権限の設定内容などを教えて頂けますでしょうか。

      こちらでは、そのドキュメントを触る権限のないマネージャユーザで
      ログインすると、ツリーには表示されますが、削除はできません。

      右クリックのメニューでは、権限のないモノはグレーアウトされており、
      ドキュメント情報画面の上部には「削除」ボタンが表示され、
      クリックすると、「削除して良いか?」聞かれますが、OKすると、
      拒否され、結果的には、削除できない状態です。

      MODxのバージョンは096です。

      ---*---*---*---*---*---
        • 27086
        • 37 Posts
        こんばんは。

        チェック、ありがとうございます。MEGUさんの状態が正しいはずですよね。

        具体的に・・・というか権限の方は特に変わったところは無いはずです。
        元々はかなり限定した範囲だけをさわれるようにしたユーザで気づいたので、編集部分だけすべてチェックを入れてあります。

        MEGUさんと挙動が根本的に違うのは、ツリー上で権限のないドキュメントは左クリックしても権限がない旨ダイアログが出て情報画面が出てきません。なので情報画面上部の削除が出てきません。一応、そのドキュメントに権限を持っていないのは間違いないようです。

        右クリックメニューはグレーアウトされていますが、カーソルを当てれば反転して通常表示され、選択できてしまいます。削除もそうですが、権限のないドキュメントの下層に子ドキュメントを新規作成できてしまいました。

        ソースを追っていったのですが、一応削除前に権限のチェックを行っていました。
        adminでなければ現在ログイン中のユーザとヒモ付けされているドキュメントグループをセッションから取得してチェックしているようなのですが、このセッションからの戻りがいつも同じ・・・というか管理者と同じ値が戻ってきているみたいです。
        これは私の使っているサーバの環境の問題かなぁ。。。eAcceleratorとかかなぁ。明日、調べてみます。
          • 27086
          • 37 Posts
          こんにちは。

          まだ原因が分かりません。。。怪しい拡張は全て切ってみたのですが、状況は変わりません。

          ソースを追っているのですが、次の部分に引っかかっています。

          /manager/processors/user_documents_permissions.class.php 内に
          $sql = "SELECT DISTINCT sc.id 
                       FROM $tblsc sc 
                       LEFT JOIN $tbldg dg on dg.document = sc.id
                       LEFT JOIN $tbldgn dgn ON dgn.id = dg.document_group
                       WHERE sc.id = $document 
                       AND (1='' OR NOT(dgn.private_memgroup<=>1)".(!$docgrp ? "":" OR dg.document_group IN ($docgrp)").");";

          こういうSQLがあります。削除時には user_documents_permissions.class.php 内の権限チェック関数が実行され、このSQL文によってチェックされています。

          最後のdg.document_group IN ($docgrp)の条件のみならば、ログインユーザが権限をもつドキュメントのIDの一覧が戻ってきます。これと sc.id = $document とのANDをとって対象になっているドキュメントのIDのみ返ってくればそのドキュメントへの権限ありと判定しています。

          WHERE句の中に NOT(dgn.private_memgroup<=>1) という節があります。(テーブルの接頭字を触っていないならば)modx_documentgroup_namesのprivate_memgroupを見ているみたいなのですが、ここが問題になっているみたいなのです。

          このテーブルの意味がよく分からないのですが、ウェブユーザグループ、マネージャーユーザグループに存在する各グループがプライベート指定になっているかどうかを保持しているみたいです。先の NOT(dgn.private_memgroup<=>1) でorを取っていますので、このテーブル内の各ユーザグループの設定値は1である必要があると思いますが、全て0になっていました。select * from modx_documentgroup_names; などとすれば設定値を確認できます。

          何かを設定したときに、どこかの段階でこの値が1になるんだと思うのですが、それがどこの設定や操作によるものなのかが分かっていません。私の権限の付け方が何か間違っているのか・・・。編集権は設定できているので間違っていないと思うのですが。。。

          お手数でなければ mysql 上でselect * from modx_documentgroup_names; の結果(又はバックアップマネージャーでmodx_documentgroup_namesのみダンプして)を見せていただけないでしょうか?

          厚かましいお願いですがよろしくお願いいたします。
            • 19033
            • 892 Posts
            こんにちは。
            良くわかってないかも知れませんが、これでご希望のモノでしょうか??
            やり方がわかればご協力致します。

            #
            # MODX096 Database Dump
            # MODx 0.9.6 (rev 2767)
            # 
            # --------------------------------------------------------
            
            #
            # Dumping data for table `modx096_documentgroup_names`
            #
            
            INSERT INTO `modx096_documentgroup_names` VALUES ('1','Site Admin Pages','0','0');
            INSERT INTO `modx096_documentgroup_names` VALUES ('2','MEGU権限','0','0');


            phpMyAdminでテーブルを開いたり見たり、フィールドの値を変更したりとかはできます。
            (↑私のスキル。。)
              • 27086
              • 37 Posts
              MEGUさん、ありがとうございます。
              どうしても納得がいかなく、かといって対処方法も分からない(応急処置は出来そうなのですが他への影響が分からない)ので英語フォーラムに投稿してみました。

              頂いた内容でOKです。’MEGU権限’というドキュメントグループがあると思います。ここに含まれるドキュメントを他のユーザには触れないようにしても触れちゃうというのが今回の問題なんですが、’MEGU権限’の値が0,0になっていて前者がマネージャーユーザ(DB上ではprivate_memgroupというカラム名)、後者がウェブユーザの値のようです。

              先のSQLで権限をチェックしているみたいなんですが、private_memgroupが常に0のため、NOT(dgn.private_memgroup<=>1)が常にtrueになり、結果的には WHERE sc.id = $document だけが条件になってしまう気がしています。そうなると当たり前なんですけど、常に1つの結果($documentのID)が返ってきてこの先の処理で権限ありと見なされてしまいます。

              MEGUさんの環境では問題ないと言うことならば、この値は関係ないのかもしれませんが。。。他のコードでprivate_memgroupを操作している部分が見つかりませんでした。既に使われなくなったか、これから実装しようとしているのかのどちらかかもしれません。

              なお、NOT(dgn.private_memgroup<=>1)を取っ払ってあげるかprivate_memgroupの値を1にしてあげると、dg.document_group IN ($docgrp)の処理でログイン中のユーザが権限を持つドキュメントID情報と編集しようとしているドキュメントのIDを比較する形になり、期待した動作になります。
              私が思うに、0.9.6以前は権限外のドキュメントのツリー表示機能はなかったので、右クリックメニューからの削除やドキュメント作成について考慮されていなかったが、現状そのままになってしまっているのではないかなーと思っています。英語フォーラムでコアメンバーの目にとまることを期待しています。
                • 27086
                • 37 Posts
                度々すいません。

                まずは動作環境を変えてみるということで、http://www.opensourcecms.com/ のデモを使わせてもらいました。
                やはり現象が再現するので、もしかするとMEGUさんにはどのような手順なのかがうまく伝わっていなかったかもしれません。

                テスト風景をキャプチャーしてWINKを使ってFLASHで再現しています。よろしければ添付ファイルをご参照下さい。
                  • 19033
                  • 892 Posts
                  こんにちは。詳しくありがとうございます。
                  さっきちょっと勘違いしていたかも知れませんが、動画を
                  参考にさせたいただき、以下を実行しました。

                  1.Administrator 権限でマネージャにログイン
                  2.マネージャへのアクセス許可で、以下を作成
                    ユーザグループ test01
                    ユーザグループ test02

                    ドキュメントグループ test01group
                    ドキュメントグループ test02group

                    ユーザ/ドキュメントグループ リンク
                    ユーザグループ test01 --- アクセス可能なドキュメントグループ test01group
                    ユーザグループ test02 --- アクセス可能なドキュメントグループ test02group

                  3.ドキュメントを作成する
                    ・permissiontest01 --- ドキュメントグループ test01group
                    ・permissiontest02 --- ドキュメントグループ test02group

                  4.権限管理で権限を作成する
                    ・権限名 edit_save --- コンテンツ管理で「ドキュメントの編集」「ドキュメントの保存」にチェック(それ以外はデフォルト)

                  5.ユーザを作成する
                    ・ユーザ名 test01 /ユーザ権限 edit_save/グループ test01
                    ・ユーザ名 test02 /ユーザ権限 edit_save/グループ test02

                  6.マネージャをログアウトし、test01でログイン
                    ・permissiontest01 は、さわれるが、permissiontesst02は、左クリックで拒否される。
                    ・また、右クリックメニューの編集を選択すると拒否される(上記と同じ警告メッセージ)

                  7.test02でログインし直す
                    ・permissiontest02は、さわれるが、permission01は、左クリックで拒否される。
                    ・また右クリックメニューの編集を選択すると拒否

                  以上です。何か勘違いしているでしょうか。私。。
                    • 27086
                    • 37 Posts
                    4.権限管理で権限を作成する
                      ・権限名 edit_save --- コンテンツ管理で「ドキュメントの編集」「ドキュメントの保存」にチェック(それ以外はデフォルト)
                    の部分ですが、編集関係は削除、作成を含めて全てチェックしています。上記の場合は削除、作成はチェックしていないと言うことですよね?

                    それならば自分のドキュメント含めて作成や削除が出来ない(この状態だとMEGUさんの書かれているとおり選択自体ができませんね)状態で当然かと思います。自分が権限を持つドキュメントの下に子ドキュメントを作成したり、削除できないと不便ですよね。。。

                    本来は各ユーザに「削除」「作成」権限を与えても、自分に権限のある範囲でしか実行できないというのが正しい動作じゃないかと思います。
                    というところで悩んでいるわけです。
                      • 19033
                      • 892 Posts
                      こんにちは。
                      なるほど。。理解できました。
                      の部分ですが、編集関係は削除、作成を含めて全てチェックしています。上記の場合は削除、作成はチェックしていないと言うことですよね?
                      そうです。

                      言われたとおりに試してみましたが、
                      うちでも同じ様になりました。編集は拒否されますが、
                      削除や、そのドキュメントの下にドキュメントを作成したり、
                      できちゃいました。

                      警告メッセージが出るのに、できちゃうっていうのも、中途半端な
                      感じですね。