captcha-r-j2 問題定義型?
Posted by amayadori on 2007/05/16(水) 15:35
5/15のブログまだやってるCaptchaの改造(;^_^A アセアセ…において、0829@drupal.orgさんの初期の改造アイディアをローカルに問題と答えを記述したファイルを用意しすることで実現してみた。
今日の成果は、Google AdSenseモジュールを参考にプロフィールで問題と答えを記述しておくフィールドを作成して、認証に使うようにしてみた。
これによって、問題を変更するときはFTPなしでオッケーとなる。
問題と答えをセットにして記述するのである意味ユニークな組み合わせが可能となる。
「とうきょうと」を漢字で書け
とか
「大阪府」の読みをひらがなで書け
のような問題が作れる。
試してないけど、ＴＯＫＹＯを半角小文字(tokyo)で書け…なんて言うのもありかもしれない。
ランダムに変わる計算式というのはできないけれど、その代わり、組み合わせは自由にできるし、問題の変更も簡単である。
トリセツ
使えるようにするまでの手順。
- このバージョンはDrupal本体に同梱のモジュールであるprofileのフィールドを利用します。profileモジュールが有効である必要があります。
- 管理→ユーザー管理→プロフィール 画面で、「新しい項目の追加」より「複数行のテキストフィールド」を選択してフィールドを追加します。
- 「フォーム名」項目には「profile_captcha_qa」を入力してください。このフォーム名以外は認識しません。それ以外の項目は決まりはありませんので、わかりやすいものを入力してください。ただし、最後の「表示可否」項目は「非表示項目」がおすすめです。
- プロフィールのフィールドを保存したら、管理者(uid=1のユーザー)の「自分のアカウント」→「編集」を開き、先ほど作成したプロフィール項目にCaptcha認証用の「問題=答え」の形式で入力します。1行に付き、1セットです。「=」は半角文字です。
認証Q: 問題
のようなイメージで表示されますので
５×６の答えを全角数字で入力してください
などのように入力してください。この場合のセットは
５×６の答えを全角数字で入力してください=３０
と言う風にフィールドに記述します。
2つめの問題以降は改行して新たな行に入力してください。認証時にはランダムに選ばれた問題が出題されます。
問題の数に、制限はありません。
前後の空白除去の処理をしていますので、(半角の)空白文字は使わないようにしてください。
| 添付 | サイズ |
|---|---|
![[file]](http://drupal-j.com/sites/all/modules/webfm/image/icon/zip.gif "download as file"){kind=icon} captcha-r-j2.tar.gz | 16.99 KB |
トラックバック
URLから "-notspam" を削除してトラックバックを送信してください。トラックバックポリシーは こちらに提示しています。
確かに、おっしゃるとおりですね。
こういった形で商業利用されると使う(関わる)人が増えてきます。使う人が増えると言うことは集まる情報量も増えると言うことですから、是非ともそのようになって欲しいモノですね。
別に、4.6.xとか4.7.xは使わないので4.6.x→5.xの直行便を利用したいので(笑)
段階を踏むことを考えるととたんに萎えてしまいました(笑)
統合版は作れたらいいなくらいには思ってますが、選択するという機能を実装するとなるとDBを使わなければいけなくなる?のではないかと思うと、選択ではなく、問題の傾向をランダムに切り替える･･･という形が一番楽ですね。
モジュールにしてしまったらどうでしょうか?
CCK対応となるとちょっと、レベルが高そうですけど。
通常のコンテンツにもフィルターとして機能させられるようになれば使えそうですね。
AdSenseモジュールに、そんな機能があったので、参考になるかもしれません。
私は、逆にjスクリプトは鬼門という雰囲気がしています(^_^;)見ただけで頭が痛くなってきます(^_^;)
図解ということは本当に技術的な感じなのでしょうね。当たり前でしょうけど…
日本語で説明されても判らないような気がします。それよりも使い方の書籍の方が先に必要かもしれませんね。
4.6 系のモジュールは 4.6.x → 4.6.10 → 4.7.x → 4.7.4 → 4.7.5 → 5.x と、少しずつ変更があったようなので（たぶん）、ちょっと大変かもしれませんね。
コードはどうせ英語なので、Updating your modules を参考にすると、多少は明るくなるかもしれません。ほとんどコードの新旧が比較してあるだけなので...
Captcha は時間があれば、「問題出題タイプ」と「ランダムひらがな入力タイプ・画像認証版」を選択して切り替えられるようにできればいいな...くらいには思っていましたが、特に何もしていないので気にしないでください。
基本的には、誰かが作成してくださる方がありがたいですから...
今のところは、Google AJAX Feed API に新しい FeedControl というクラスが追加されたので、それを使って何かできないかな...と、ちょっと思っているくらいです。
あとは、jQuery Interfacwce を使って楽しいことができたらな...とか、結構 JavaScript 好きなのかもしれないです。
あー、なるほど。私はみたことがないので、そんなページは存在しないという前提になっていました(^_^;)
そう言うページもあってもいいとは思うのですが、やはり、とっかかりとなる易しいページがあってからじゃないと立ち入れないですね。
どうなのでしょうね?図解が多いとはおっしゃっていましたが･･･、既購入者の皆様は。
どちらにしても、わざわざ英文をタイプして翻訳ソフトに掛けてまで読む気にはならないので手を伸ばす気にはなりませんけどね。
でも、他のCMSなんかでもそうなのですが、モジュールなどを作る人もどんどん新しい人が流れ込んでこないと、使う側の視点というのがどんどん薄れていってしまうので、チャレンジャーが挑みやすい環境というのは重要だと思います。
えっ！？そんな裏技があるのですか？し、知りませんでした･･･(^_^;)
でも、私が熱望しているCSSモジュールは4.6.x対応なので･･･。
実は4.6→5.xのAPIの解説も密かに期待しているのであったりして(ヲイをい)
あっ、別にリクエストではないので(^_^;) しかも、そんなネガティブな労力使うのなら5.xのAPIを解説してもらった方が遙かに有意義ですし(^_^;)
申し訳ありません･･･0829@drupal.orgさんの、Captchaのアイディア、横取りしてしまいました<(_ _)> これで作る予定だったのでしたら大変申し訳ないです<(_ _)> 埋め合わせは何か別なときにでも･･･<(_ _)>
こういうことについての日本語の情報は、あったとしても、技術的な知識を持った方が書かれているので、読んでもよくわからないことが多いんですよね。
Pro Drupal Development もよい書籍のようですが、きっとそんな感じなのでしょうね...
info ファイルは簡単に作成できますし、info ファイルを用意するだけで動作する 4.7x 系のモジュールもあるようですので、そういう使い方もありだと思います。
私も何か作ってみようとは思っているのですが...課題はまだまだ多そうです。
早速、ありがとうございます。
参考にして、別モジュール化に挑んでみたいと思います(笑)
こういった文献って、確かにそれなりに詳しい人が記述すべきだとは思いますが、現状で、そう言う人が文献を記述してくれていない以上は必要だと思った人がやるしかないと思います。
ここは知らないけど、ここは知ってるよと言う人から判る範囲でアドバイスいただいて、その都度修正を加えて行けば、いつか立派なモノになるんだと思いますから、まずは、とっかかりが大事なんですよ。
だから、0829@drupal.orgさんは、ご自分で判る(判った)範囲内で記述されたのでしょうから、後は、突っ込みだのアドバイスをお待ちしましょうよ。
それで、いいと思います。
それとは関係なく、私は、十分に助かってます(笑)
本当に、いつもありがとうございます。
info ファイルについてリクエストいただいたので、モジュールの構成ファイル | Drupal.0829.info にまとめてみました。
基本的には ini ファイルと同じコーディング方法らしいです。（多分）
といわれても、ini ファイルについてもよく知らないので、書いてあること以外はよくわかりませんが...
知識のない人間が解説のようなものを作成していいのか甚だ疑問ですが、自分のためのメモとして書き残しているということで、ご容赦ください。
いや、ポリシーと言うよりは、改造を加えている部分以外はまるで理解できていないので(笑)別モジュールにしてしまうと自分の首を絞めてしまう…というわけです(^_^;)
改造版であるうちは、オリジナルの不具合があろうがなんだろうが責任回避できますからね(^_^;)
一番いいのはオリジナルが取り込んでくれることですが(笑)オリジナルの作者のモジュールの作り方をみると、認証部分と、認証のための問題を作る部分は分離したいのでしょうから、ま、あり得ないですけどね(笑)
後は、私がモジュール全体をスクリプトレベルで理解できるようになるか、ソースを読んで理解できる人がメンテナンスをしていただけるとか言うのであれば別モジュールにしても良いのではないかと思いますけどね。
ま、私が別モジュールという道を歩まないのもこういった情けない理由からです(T.T)
現実問題として*.infoファイルの中身も知らないし(笑)DBやSQLのことも知らないです。
モジュール作成の先人の皆様のソースからそれっぽい部分を拝借して、改造しているレベルですからね(^_^;)
ロジックだけは考えられますけど、プログラムという成果物にするのには知識も技術力もありませぬ。
かなりスゴイことになってますね。別モジュールにしてもいいくらいの感じですよね。
それだと amayadori さんのポリシーに反するのかもしれないですけど...