[PLUGIN] SQLサーバーにアクセスするデータベースアプリケーションを手軽に作る為のプラグイン†
- ページ: BugTrack
- 投稿者: 三浦克介
- 優先順位: 低
- 状態: 着手
- カテゴリー: プラグイン
- 投稿日: 2004-10-01 (金) 21:04:46
- バージョン:
メッセージ†
MySQLやPostgreSQLなどのSQLサーバー＋PHPやCGIでWebデータベースアプリケーションを作成するのは、なかなか厄介です。PhpMyAdminなどの汎用的なツールがありますが、複雑ですし、何でもできてしまうので、データベースの知識が乏しい人に使わせるのは危険です。凝った物でなくて良いから、簡単にWebデータベースアプリケーションが作れないかと考えてみました。
- 研究室内で使う簡単なデータベースアプリケーションを作る必要に迫られています。今のところ、MS-Access で対処しているのですが、しっくりこないので、SQLサーバー＋PHPでWebベースにしようかと考え、でも一から作るとしんどいので、PukiWikiのプラグインにしちゃえば少し楽かなと考え、そこから発展して、簡単なWeb-DBアプリを作れる汎用的なプラグインができないかな、と考えてます。こんな実験をしている人って、いませんか？ (Wiki的な使い方じゃないですけど‥‥) official:欲しいプラグイン/109 が関連してますね。レスが付いていない所を見ると、無いのかな。 -- 三浦克介
- MySQLで実験用のアプリを途中まで組んでますが、まだ動いてないです (^^; -- teanan
- 良かった。同じような考えの人がいて。私の方は、実装はこれからですが、次のようなものを考えています。 -- 三浦克介
id,name,address,tel,emailのフィールドを持つのDBがあり、任意のページ中に、
#dbap_search(DATABASE,TABLE,EDIT_FORM,id,id,name:名前,address:住所,tel:電話番号,email)
と記述すると、名前、住所、電話番号の検索フォームが表示される。検索文字
列を入れて送信すると、actionプラグインが呼ばれて、queryが発行れ、id,
name, address, tel, emailのフィールがテーブルで表示される。引数は、最
初から、DB名、テーブル名、編集フォームページ、レコードを一意に識別可能
なフィールド、表示フィールドリスト。フィールド名に ":TAG" を付けると、
検索フィールドになる。
テーブルに表示されたレコードをクリックすると、EDIT_FORMというページが
表示される。EDIT_FORM ページには、
#dbap_edit_field(BEGIN)
|フィールド名|値|h
|ID|&dbap_edit_field(id);|
|名前|&dbap_edit_field(name);|
|住所|&dbap_edit_field(address);|
|電話|&dbap_edit_field(tel);|
|メール|&dbap_edit_field(email);|
#dbap_edit_field(END)
といった感じに記述しておく。編集フォームは、任意にカスタマイズできる。
てな具合に考えています。一人で考えていると、なかなか良いアイデアが出て
こないので、teanan さんが作成中のものの仕様・アイデアとかを教えて
頂けると嬉しいです。
- 私の場合はまだ深く考えていません (^^; とりあえず
trackerbugtrackと同じ項目のものを機能限定で作ろうとしています。色々とカスタマイズできるようにしたいのですが、収拾がつかなくなりそうですので、まずは何かしらの形にすることが目標です。 -- teanan
- 設定等もtrackerのフォーマットを踏襲したいです*1。SQLとか使うと一気に敷居が高くなりそうですので、現状のものをできる限り簡単に移行できるような仕組みにしておいたほうが、興味をもってくれる方が増えるかなぁ、と・・・ :) -- teanan
- 折角なので、BugTrackを立てて専門的に取り組んでは＞SQL呼び出しプラグイン。最初は実現させるのが目標なわけですから、CSVなんて中間形式を考える必要もないと思いますよ。お気楽にどうぞ :) -- henoheno
たたき台†
とりあえず、たたき台として検索部分を実装してみました。雑談 に書いた仕様とはだいぶ違いますが。
http://www-ise3.ise.eng.osaka-u.ac.jp/miura/dbap/pukiwiki.php
仕様・実装に関するご意見をお待ちしています。
- 落ち着いた辺りで、pear DB化(抽象化)でしょうかね ;) -- henoheno
- そうですね。とりあえず、手とにあるのがMySQLなんでね。 -- 三浦克介
- PukiWiki2のページでは、実際にどうにかしようという検討にまでは話が進んでいませんでしたから、とても興味深いです :) -- henoheno
- Tracker互換ですか‥‥、うーん、私の欲っしている物とはちょっと違うような‥‥。ま、とりあえず、私は私の欲望の赴くままに、実装してみます。そこから、新たな可能性が見えてくることもあるかも‥‥。 -- 三浦克介
- 私の場合、業務で使用している自作のPHP+MySQLのBugTrackシステムをPukiWikiに取り込みたいということがことの始まりです*2。私ももうちょっと目処がついたらお知らせしますね。 -- teanan
- とりあえず、私は脱落ということで XD 。切羽詰っていないので、皆様の物を参考にさせていただきつつ、またーり作ります (^^; -- teanan
- えーと、SQLプラグインはわたしも昔チャレンジしたことがあります。:config で設定してとか色々考えたんですけど、セキュリティを確保するのがあまりにもつらすぎてやめました (^^; -- みこ
- なぜ確保するのがつらすぎるかというと、システムテーブルを覗かれるとそのデータベースにあるテーブルが全てばれてしまうということと、そのセキュリティを確保するにはデータベースユーザの権限を相当細かく設定しなければならないためです。 -- みこ
- ただ、そんなソースコードを見たいという人もいるかもしれないので（ほんとに？ (^^;）、ソースコードの残骸がどこかに残ってるので探してみます・・・ (..; -- みこ
- 誰も手を出さないというのは、それなりに理由があるということでしょうか・・・ (^^; -- teanan
- DBとtableはWikiで可変ですが、userとpasswdはPHPコードの中に書いてしまい、Wikiでは自由に変更できないようにするつもりです。userの権限を一部のDBやテーブルのみ操作可能にしておけば、システムテーブルを覗いたり、いじられたりする恐れはないと思いますけど、どうでしょう？ 場合によっては、DBも限定すればよいでしょう。それでも、リスクが排除できない場合は、部署内限定、一般公開サーバーでの利用不可、という限定的なプラグインにしちゃいます。私が作っている動機も、部署内用途ですし。 -- 三浦克介
- システムテーブルが読めるアカウントをPukiWikiに盛り込む危険性、というか必要性はないでしょう。多くのデータベースはユーザーと権限を必要に応じて使い分けることができます。また具体例としてMySQLであれば１つのサーバーの上にデータベースを複数持てるわけですし、やろうと思えばテーブル単位にアクセス制限がかけられるはずです (私なら面倒なので、アプリケーションごとに専用のDBを作っちゃいますけど) -- henoheno
- 汎用性と機能性とセキュリティの兼ね合いについては、(pear DB が実装している、SQLの)プレースホルダを利用することでどうにかなるのではないかと思います。 -- henoheno
- えーと、その細かな設定をやってみるとわかります。（とくに既存のDBを読み出したいときは GRANT をフル活用してデータベースの知識フル活用でロールしないといけません。） -- みこ
- 一例を挙げると SQLServerなら syscolumns, systables、 Oracleなら user_tables、 postgresなら pg_tables（中にはビューもある）をまず SELECT もできないように絞って（同様にビュー・ストアードプロシージャのシステムテーブルおよびビューも）きちんと制限をかけなければなりません。部署内用途でも、覗かれたくないテーブルがあったら同様だとおもいます。（わたしもそもそも用途がイントラネット向きで語ってるので） -- みこ
- ゆえに、henohenoさんがいわれている「アプリケーションごとに専用のDBを作る」というのが結局の現実解になることが多いです。 -- みこ
- ただ、わたしも実現したい１人なので（自分のblogみたらなんと9ヶ月越し*3で考えていたらしい (^^; ）アイディアを。あえて改造が前提のプラグインとして、「DBとテーブル(およびビュー、ストアード)はプラグイン内で配列で定義して、あるものしか使えないようにする」というのはどうですか？ -- みこ
- ↑はあえて、:config系にしていないのはサイト管理者(Wiki管理者)=ＤＢ管理者となることが多いからという理由と、これだけでセキュリティは（ちゃんと知ってれば）相応に守れるという理由です。 -- みこ
- そうですね。標準プラグインにしてもらうつもりはまったく無いですから、プラグインをインストールする権限が無ければ利用できません。user, passwd もプラグイン内で定義のつもりですし、DB、table もプラグイン内定義で制限できるようにして構わないでしょうね。 -- 三浦克介
- ちなみに、たたき台サイト のシステムテーブル、覗けます？ 一応、このプラグインのテスト用に専用のDBとユーザーを作って、それ以外のDBにはアクセスできないようにしたつもりなのですが・・・（SQLサーバーの管理経験は浅いので、あまり自信ない・・・。別のセキュリティーホールを突いて root アカウントを取得して・・・というのは無しね）。 -- 三浦克介
- 専用のDBを作り、ダミーユーザーに最低限の権限しか与えない様に作られた時点で大丈夫だと思います。MySQLはクライアントのホスト名も識別しますから、そのサーバーを乗っ取ったり、そこにPHPファイルを送り込んだりされなければ、例えユーザー名とパスワードが漏洩したとしてもテーブル操作はできないでしょう。SQLインジェクションが可能な脆弱性があった場合、破壊されるのはそのDBの中だけですが、このプラグインがDBのデータをそのまま表示している間はXSSが起こる可能性があるでしょう。叩き台の中に書かれているMySQLサーバー名からIPアドレスを引くことが可能だったりすると、学内学外からダイレクトアクセスを試みる輩が出かねないので別の意味でちょっと危ないですが、そういう風にはなっていない様ですね。・・・こういう検討をするとよろしいですか？ ;) -- henoheno
- 社内用途で、検索専用のモノを作っていました。とりあえず、接続先のホストとDB名だけプラグインの中で指定して、SELECTの後ろは全部スルーで、pear DBのプレースホルダだけかますという感じなんですけど、よさげですねdbap_search。覗けるテーブルをプラグイン側で限定するというのに一票です。trackerライクに:config使うのであれば、そこに[表示専用|修正可能|新規入力可能]みたいなフラグをつけるというのはどうでしょうか。 -- 草柳洋介
- henoheno さん、検討thanksです。みこ さん、たたき台サイト でのクラッキングテスト、ありがとうございます。デバッグのため、エラー時に mysql_error() のメッセージをそのまま出力してますので、DB やテーブルの有無がばれちゃいますね。エラーメッセージの出力方法にも気を配らないといけませんね（デバッグモード時のみ出力するとか）。 -- 三浦克介
- 最近、忙しくてたたき台サイトのテストも途中ですみません。報告としては、mysqlの場合システムテーブルがmysqlユーザに集まっているのでmysqlに限定するならば大丈夫かと思います。（他のデータベースはシノニムやリンクで一般ユーザでもシステムテーブル/ビューがみえてしまうのでデータベースを相当理解してないと、現行のdbap_searchではきびしいかもしれません。 -- みこ
- 皆さんのご意見のおかげで、単一テーブルに対する検索・編集操作は何とかものになりそうな気がしてきましたが、リレーションをどう扱ったらよいものか・・・。やはり、JOINを含んだSELECTを作れたり、入力・編集時にコード検索・選択用の別窓を開いたり、といったことができないと、実際の所、使い物にならないですよね。とは言っても、SQLを直書きできるようなプラグインはまずそうですし・・・。そこで、利用者が自分でプラグインを作成しなければ利用できないようにし、プラグイン作成を支援するためのクラスライブラリやテンプレートを整備する、って考え方はどうでしょう？ どういうAPIにしたら良いかはぜんぜん考えていませんが、SQLの組み立てと表示フォームだけ考えればサクサクとプラグインができてしまうようなライブラリができれば、PHP初心者レベルでも自由度の高いアプリが作れ、安全性も保たれるのではないかと思います。敷居が高くなってしまい、利用が限られるでしょうか？あるいは、プラグインを作るプラグインとか（某統合開発環境のように、ウィザード形式で質問に答えていくと、プラグインのベースが表示され、それにチョコチョコっとコードを足せば完成、後はアップロードするだけ、みたいな）。ちょっと、考えが発散気味・・・。 -- 三浦克介
- リレーションはビューかそれ相当のものを作っておくほうが妥当だと思います。現在ならばビューから条件付で検索してもオプティマイザが理解してくれるデータベースもあります。更新は・・・正直Wikiでおこなうのは戸惑いますね(^^; わたしなら素直にWikiを使わないPHPで作ります。（トランザクションかけるのは難しいし、セキュリティリスクを背負ってまでWikiにする必要はないとおもっていますし・・ (^^; ） -- みこ
- 今の三浦さんのニーズが満たせるものをお作りになれば良いかと思います :) JOINを含むSQL文の骨格は固定で、where句に与える部分だけはドロップダウンリストやテキストフィールドで変更できるようにするとか。対策を万全にするのと、とりあえず手を動かされたいなら、pear DB(およびプレースホルダ)を使う様に直すというのはいかがでしょう。 -- henoheno
- では、とりあえずは、好みのままにつくってみましょうかね。セキュリティが甘々になりそうな気がしますが‥‥。 -- 三浦克介
- これは自分で作ろうと思っていたそのものでした。SQLLiteと組み合わせて使ってみます。 -- 常盤亮太
- 素人が使うのだから、難しいことはいらない。住所録ていどが出来れば上出来。ただ、単語辞書のようにデータ量が多くなっても対応出来、外部からデータの移入抽出（CSVなど）が必要。単純でないと素人は扱えない。玄人は直接SQLを使うから素人向けにポイントを絞るべき。 -- ES
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
