問題タブ [database-permissions]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
django - django-guardianのサンプルソースコード
誰かがdjango-guardianを使用する優れたオープンソースアプリを提案できますか?APIを理解するのに問題はありませんが、実装のベストプラクティス(データベース設計など)を理解するための例を見てみたいと思います。
mysql - MySQL テーブルの権限を編集するためのツール?
MySQL データベースでユーザー権限を簡単に編集できるツールはありますか? 私は 4 人のユーザーのために 100 近くのテーブルを処理する必要があり、それぞれに異なるテーブルごとの付与があり、phpMyAdmin を介して面倒になっています。後でデータベース構造とユーザー リストを変更すると、さらにイライラすることになります。また、MySQL Workbench でそれを行う方法もわかりません。
テーブル権限の管理を容易にする権限管理ツールはありますか?
更新:明確にするために、ユーザーのスキーマごとおよびテーブルごとのアクセス許可を管理できるツールが必要です。後でアクセス許可を変更するので、既存のアクセス許可を完全に管理し、新しいアクセス許可を付与できる必要があります。MySQL Workbench では、スキーマごとの権限を管理できますが、テーブルごとには管理できません。
php - ACLモデリング-アクセス制御リストの「階層」を管理する方法は?
私はまだACLプロジェクトに取り組んでおり、次の問題についていくつかのアイデアが必要です。
MySQLを使用して、ユーザー、ロール、および権限を保存しています。最初に、TABLEロールにフィールド「parent_id」を作成し、これを介して各ユーザーの権限を管理しようとしていました。新しい役割を追加すると、階層を管理し、誰がどのリソースにアクセスできるかを制御するのが非常に複雑であることに気付くまで、それは一種の作業でした。いくつか検索を行ったところ、リレーショナルデータベースを使用して階層を操作するのは非常に複雑であることがわかったため、階層の使用をあきらめました。
ユーザーの作成を管理するための最適なソリューションを見つけるためにあなたの助けをお願いします:私には4人の異なるユーザーがいます:SuperAdmin、CustomerAdmin、Technician、client。新しいユーザーを作成するページにいるとき、技術者にCustomerAdminやSuperAdminなどのタイプの新しいユーザーを作成させたくありません。
SuperAdminだけに新しいユーザーを作成させることを考えましたが、私の制約の1つは、CustomerAdminにも技術者であるユーザーを作成させる必要があるということです。
より教訓的になるように努めて、SuperAdminは私になることができます。顧客管理者は私のクライアントであり、彼には企業があります。彼の企業では、技術者とクライアントの2種類のユーザーを作成できます。
これは単なる例ですが、彼に新しい権限を与える新しい種類のロールを作成する場合は、彼よりも強力なユーザーを作成する権限を拒否する方法を見つける必要があります。
私の質問が客観的であったかどうかはわかりませんが、これについて私と話すことができる人なら誰でも歓迎します。
database - OracleSQLDeveloperで自分のテーブルにのみアクセスするようにユーザーを制限する
SQL Oracle Developerの権限、権限に混乱しています。作成されたユーザーは、すべてのスキーマ/ユーザーのテーブルにアクセスできます。データベース内の特定のユーザーが自分のテーブルにのみアクセスするように制限したい(ALTER、DROP、UPDATEなど)。誰かが私にこのタスクを実行する方法を指定できますか?
つまり、ユーザーが自分のテーブルにのみアクセスするためのシステム特権から選択する特権を意味します。ありがとうございました
oracle - 別のスキーマで作成したばかりのパッケージでプロシージャを実行するにはどうすればよいですか?
セットアップ: Oracle 11g で実行する 2 つのスクリプト ツリーがあります。1 つのセットは正しいインスタンス構成を保証し、すべての DBA プロキシ アカウントが dbadmin アカウントに接続するようにします。もう 1 つのセットはデータベース環境を構築および変更します。
問題: DBADMIN アカウントにプロキシすると、2 番目のスクリプト セットが正常に実行されます。データのロードを許可するプロシージャは、適切なスキーマの下で問題なく作成され、データをロードするスクリプトは、SYS AS SYSDBA として実行された場合に問題なく実行されますが、プロシージャを作成した直後に DBADMIN として実行しようとすると、I が呼び出されます。PLS-00904: insufficient privilege to access object schema.package
呼び出しごとに取得します。GRANT EXECUTE ON schema.package TO DBADMIN
(もちろん)予想されるORA-01749: you may not GRANT/REVOKE privileges to/from yourself
エラーが生成されるため、スクリプトを作成することさえできません。
もっと簡単に言えば:
(DBADMINとして:)
(成功し、テスト可能に動作しています)(後で、同じ親スクリプトによって呼び出された別のスクリプトで、まだDBADMINとして:)
(上記の PLS-00904 を発生させます - 権限が不十分です)
DBADMINアカウントにまだ作成していないパッケージへのEXECUTEアクセスを与える方法、またはDBADMINがスクリプトストリーム全体を停止せずに自分自身にアクセスし、ログアウトしてSYS AS SYSDBAとして再度ログインしてGRANTする方法についてのアイデアはありますか? (ここでの要点は、最初の「このスクリプト ツリーを実行する」以外の手動ステップをゼロにし、SYS AS SYSDBA を使用する前に 1 回だけにすることです。)
tfs - TF246017 TFS 管理コンソールを開くときのエラー
自分のドメイン アカウントを使用して TFS サーバーにログオンし、TFS 管理コンソールを開こうとすると、次のエラーが表示されます。
TF246017: Team Foundation Server はデータベースに接続できませんでした。データベースをホストしているサーバーが動作していること、およびネットワークの問題によってサーバーとの通信がブロックされていないことを確認します。
TFS データベースは、TFS サーバー上でローカルに実行されます。ローカル コンピューターの管理者アカウント (おそらく TFS のインストールに使用したアカウント) を使用して TFS サーバーにログオンすると、管理コンソールはエラーなしで正常に読み込まれます。そのため、SSMS を使用してローカル TFS データベースとそのログインを調べたところ、ローカル TFS サーバーのユーザー アカウントが完全な権限でリストされているのに、私のドメイン アカウントはそうではありませんでした。したがって、エラー。
最後に、私の質問です。私がやりたいのは、ローカルの管理者アカウントのように、特定のユーザーに TFS データベースへのアクセス許可 (したがって、エラーなしで管理コンソールを実行できる機能) を提供することです。これらの各ユーザーを SSMS を介してログインとして追加するのではなく、TFS DB に対するアクセス許可を自動的に付与する追加できる TFS グループはありますか? それは少しきれいに見えるでしょう。
ありがとう。
php - mysql コマンド ラインが機能しているときに、PHP PDO が "SQLSTATE[42000] [1044] Access denied for user" を取得するのはなぜですか?
ここ数時間、この壁に激しくぶつけていたので、頭が血まみれです。:(
タイトルが示すように、データベース サーバーの mysql コマンド プロンプトからデータベースに正常にアクセスできる MySQL ユーザーを作成しました。ただし、同じユーザーでデータベースにアクセスするために新しい PDO オブジェクトをインスタンス化しようとすると、次のようになります。
ユーザーを作成した方法は次のとおりです。
ここで何が問題になる可能性がありますか?! 誰か私に骨を投げてください!(参考までに、新しい PDO オブジェクトを作成しようとすると問題が発生します... PDOException をキャッチすると、それがメッセージです)。
付与後に FLUSH PRIVILEGES を実行しました。SHOW GRANTS の出力は次のとおりです。
このユーザーの mysql.db は次のようになります。
重要な場合、これは Ubuntu 12.04 LTS で実行されている 4 ノードの MySQL クラスターです。
編集: Zend AMF を使用してサーバーにアクセスしようとしたときにのみ問題が発生することがわかりました。PDO が Zend AMF で動作しない理由はありますか? Zend AMF のセットアップで何かを見逃したのではないでしょうか?
java - java.sql.SQLException: ユーザー 'xx@xx.xx' のアクセスが拒否されました (使用するパスワード: YES) インストールから 2 年後に表示されます
もらい始めました
データベースに新しいデータを追加しようとするときにサーブレットから。エラーに関係なく、データは引き続きデータベースに書き込まれます。データベースは 2 年以上使用されており、データベースやユーザーなどは更新されていません。
私は mysql の再インストールを絶対に避けようとしています。
mysql ログ ファイル /var/log/mysql.log が空のようです。tomcat5.5 ログには、いくつかの情報行しかありません。
MySQL 5.0.51a-24+lenny1 (Debian) で Tomcat 5.5 を実行しています。
ありがとう!
sql-server - SQLServer2012-ネットワークアクセス用のファイルテーブルのアクセス許可
ネットワークサーバー上のファイルストアとしてSQLServer2012インスタンスを設定しています。ファイルテーブルを表すファイルシステムを参照できるようにするには、同じネットワーク上のコンピューター上のすべてのユーザーが必要です。ただし、すべてのユーザーはサーバーと最上位ディレクトリを表示できますが、アクセス/開く権限はありません。
アクセスを有効にするには、どの権限を確認する必要がありますか。
sql-server - SQL Server のプリンシパルを理解するには?
これはばかげているように聞こえますが、非常に紛らわしいと思います。MSDN では、定義は SQL Server リソースを要求できるエンティティです。基本的に、Windows レベルのプリンシパル、SQL Server レベルのプリンシパル、データベース レベルのプリンシパルの 3 種類のプリンシパルがあります。ここまでは問題ありません。1 つのプリンシパルの識別子は、このプリンシパルがどのようなタイプであっても、他のものとは異なる必要があるという印象を与えるだけです (これら 3 つのタイプのすべてのプリンシパルを 1 つのテーブルに配置できれば、一意の識別子を持つことになります)
紛らわしい部分は、以下の 3 つのクエリから来ています。
1)
(注:1つのデータベースで実行します)
2)
これで、最初のものはデータベース ユーザー プリンシパルを返し、2 番目のものはサーバー ユーザー プリンシパルを返すことがわかりました (間違っている場合は修正してください)。しかし、最初のクエリの 1 つの行が、2 番目のクエリの行と同じ principal_id を持つことができるのはなぜでしょうか? たとえば、データベース プリンシパルの 1 行は次のようになります。
名前:INFORMATION_SCHEMA、principal_id: 3
一方、2 番目のクエリの 1 行は
名前:sysadmin、principal_id: 3
これら 2 つの principal_id は何ですか? 前述したように、2 つのプリンシパルの識別子は、1 人が DB ユーザーで、もう 1 人がサーバー ユーザーであっても、異なると思いました (名前から、principal_id が識別子であると想定しています)。
その場合、principal_id がすべてのプリンシパルに対して一意ではなく、各クエリの範囲でのみ一意である場合 (最初のクエリの principal_id はデータベース ユーザーの識別子にすぎないため、サーバー ユーザーのものと同じになる可能性があります)、 3番目のクエリがあり、それが何を意味するのか理解できません:
3)
2 つの principal_id がその範囲内でのみ一意である場合、両方の principal_id で内部結合を行うとはどういう意味ですか? 内部結合は、この列が共同で一意であることを意味しますよね?
私が誤解している非常に初歩的なことがあるに違いありません。それについて助けてくれてありがとう!