Joomler!.net - Decided on Joomla!

Wiki or Wordpress? No it is JContentPlus.

 

Archives

Blog

Demo

Home » Blog » モジュール
1 votes
Written by:Joomler! 7733 hits Thursday, 12 June 2008 16:56

Joomla!のエクステンションで$_SERVER['REQUEST_URI']をそのまま使っているエクステンションを見かけたので問い合わせから連絡しておいた。私も恥ずかしいこといっぱいしているのでお構いなしです。Thinking

なぜ、そのまま使ってはいけないのかは「REQUEST_URI クロスサイトスクリプティング」ででも検索したら出てくるので書きませんが、mod_QRcodeを作成時に自動でURLを作成できるようにしようと思ったのですが、断念した覚えがあります。Joomla!1.5では使えそうなメソッドが用意されていますが、1.0.xでは自分が開いているサイトのURIを知ることは非常に難しいです。(もちろん、スクリプト付きでも良いなら別ですよ。)Joomla!標準のエクステンションだけならやりようもあるでしょうが、サードパーティーのエクステンションをもカバーしようと思うとはっきり言って至難の業です。$_SERVER['REQUEST_URI']ってユーザーがリクエストしたそのままが得られるだけなのでスクリプトがくっついていようが、SQLインジェクションをねらったクエリが付いていようがおかまいなしです。

簡単な例:Joomla!1.5で例えば下記のようなURLが正しいURLとすると

http://demo.joomler.net/the-news/1-latest-news/86-example-go.html

以下だとどうでしょう・・・

http://demo.joomler.net/the-news/1-latest-news/9999999999999999999/86-example-go.html

のように異なるURLでも同じページにアクセスできてしまいます。この場合はクエリの間に数字を入れただけですが、このように正しいURLでは無くても該当ページにアクセスできます。

なので、そのREQUEST_URIを使ってブックマークなんてとんでもないですよね。

サニタイズしてクリーニングすればと思うかもしれない。でもそれが本当に、そのサイトの管理者が意図するJoomla!の正しいURIってわかりますか?(もちろん使っているエクステンションが限定されていればそれ相応にサニタイズできると思います。)

Joomla!1.5で用意されているメソッドを使っても上記の例のような場合はそのまま出力されてしまいます。

結果、mod_QRcodeでは、モジュールのコピーを可能にして個々にURLの指定をするようにしましたので外部のリクエストに左右されません。

私も気をつけようっと・・・。Party

 
0 votes
Written by:Joomler! 10040 hits Thursday, 01 May 2008 17:20

昨日発見した点

  • 記事を単独で表示するとmoovoteにデータが反映されていない。
    後で直す。
  • Support Forum(Fireboard)のリンク先のリダイレクト
    今回Itemidを変更してしまったのでそれが反映されていない。

まず2点。Fireboardへのリンクは、先ほどリダイレクトのメソッドを追加したので解決した。

Joomla!は、Itemidでの管理が多用されていてItemid(メニューIDのことです。)が無い場合内部では99999999などと勝手にItemidをつけて処理しているようです。ですが、これだとItemid無しでアクセスまたは、異なるItemidでのアクセスの場合、Itemidで表示を管理するモジュールなどが正しく表示されません。Allにしていれば問題ないでしょうが、Itemid(メニューID)ごとに異なるモジュールを割り当てている場合は、Allのもののみ表示されるだけで意図した表示にはならないです。

小さなことかもしれませんが、サイトを移転したりメニューIDを変更したときには重要かもしれません。

今回の場合、Itemidが異なるため表示はされるのですが、ComibineコンポーネントでFireboard用に出力されるはずのJavascriptが出力されていませんでした。

指定した(存在するメニューID)Itemidでのみアクセスを許可し、それ以外ならリダイレクトさせるような処理をしてくれるエクステンションが、必要かもしれませんね。それがあれば、サイト移転しても楽じゃないかな。

 
0 votes
Written by:Joomler! 8120 hits Monday, 21 April 2008 16:32

そういえば、ブラウザのOperaがいつの間にか無くなっていた。最近頻繁にFirefoxが応答不能になるので新しいテンプレートの検証ようにも入れて置こうと思い、何気なくインストールしてみた。

Joomla!の管理画面ではお薦めかもしれない・・・・。

インストールしてJoomla!の管理画面を開いたら速いではないですか。Surprised何しろ応答が速い。はじめて開く管理画面でこの速さはないだろうって感じでした。モジュールの設定やコンポーネントの管理画面でも応答が速いのでたくさんアドオンを入れてFirefoxが、「動かざる事山のごとし」となっている方は一度試して見ることをお薦めします。

サイト編集の事やブラウザの管理の事を考えると豊富なアドオンのあるFirefox以外をメインで使って見ようとは思っていませんが、バックエンドのみを考えると使ってみるのも一考です。また、Prismの記事を先日書きましたが、バージョンアップで起動がかなり遅くなってしまって、あれ?クリックしたっけ・・・くらい遅くなっているのでOperaに替えちゃうかもしれません。(私の環境だけかもしれません。)

結局、Operaで表示してみたらFirefoxやIEには無い対応が必要となってスタイルや、HTMLを書き直す必要があったので良かったのですが、ちなみにうちのサイトのビジターでOperaを使用されている方は、2.46%です。なので極わずかなユーザーでしかありません。そして、これを書きながら管理画面をFirefoxで開いたら・・・・・・・・やっぱり速いではないですか・・・・なんだそれ。ブラウザトップは、依然Firefoxが首位を保っています。これは私を含んでいない数値なので確かな数値です。IEは、37.70%、これはIEすべての数字です。私が管理している別のサイトでは全く異なる割合を示しているのでこれはサイトの内容に多分に影響されていると言えると思いますが、IEユーザは確実に減っていると言えるのではないでしょうか。browser_share開設して間もないころはFirefoxが50%くらいあったのですが、IEもなかなか。

で・・・・

「Firefox  アドオンの入れすぎには注意しよう。」

これがオチですか・・・・

ちなみにうちのブラウザ別上位表を・・・

全く知らないブラウザもありますね。

結局Operaを使うのかというと・・・鈍いときには使ってみたりします。はい。


 
0 votes
Written by:Joomler! 6913 hits Saturday, 01 March 2008 00:09

私もはめ上手ですが、担当者も”か・な・り”はめ上手です。

携帯で出力してもmainbody()が出力されるとさんざんひっぱり回されました。まあ、お互い自分に原因があると思わない性格だからでしょうけど。

結局、モジュールの設定が悪かったのですが朝9時前からまだやっています。まだ他にもあって・・・・。

・・・私のミスタイプも重なって危うく全然関係ないコードまで変更してしまうところでした。お互いはめあって似たもの同士ってとこですか・・・。

$mobcount) が $mobcountJ って・・・。

「タイピング練習をしよう!」

・・・・でも・・・まだやってます。

 
Dec
23
2007

Joomla!の Cache

EMailPrintPDF
0 votes
Written by:Joomler! 21697 hits Sunday, 23 December 2007 23:15

昨日ある問い合わせがあってCacheのことでJoomlaのソースを眺めていました。

 Joomla!のCacheは、パーツごとにCacheファイルを作成し、それをパーツごとに読み込むようになっているようです。たとえば記事なら記事ごとにファイルが作成されます。モジュールならモジュールごとに。そうすることのメリットは、Cacheされては困るパーツは、Cacheさせないようにすることができるからだと思います。たとえば、このサイトで使用している!JoomlaCommentもその一つですが、Cacheされてしまうと投稿した内容はすぐに反映されません。明示的にCacheをクリアするしかありません。また、このサイトで配布しているPluginの中でもJavascriptをヘッダーに出力しているもの(SyntaxHilighter, CodePress Plugin, GreyBox)は、Cacheに対応していません。というより、Joomla!のCacheがヘッダーとともにCacheしないからです。その理由もわかります。パーツごとに管理しているため、Cacheしないパーツがヘッダー内の出力を変更することを考慮しているからだろうと想像します。Pluginは、記事内の設定された文字により、ONになります。Cacheから読み込まれた場合はPluginを通過した後の記事となるためPlugin自体を通過しません。よってヘッダーには出力することができません。

 サードパーティーのCacheエクステンション(ヘッダーを含めすべてをCacheしてくれる。)をひとつ試してみましたが、すべてのエクステンションに対応しているわけでは無いのでサイトで使用しているエクステンションによっては、自分で対応するように工夫しなければなりません。このサイトではCacheはオフにしていますが、Cacheの応答性を考えるとやはり対応していかなければならないと考えています。

 そこで対応の方法を考えてみました。

  • Joomla!のコアを変更してしまう。
    ソースを詳細に見ているわけではないので、もしかしたらそうできるように用意されているかもしれない。
  • サードパーティーのCacheエクステンションを使う。
    今回試したエクステンションは、うちのPluginはすべて正常動作していました。まるごとCacheされるので当然といえば当然ですが。

 と、そうしなくても簡易対応ならできます。

  • CacheがONならヘッダー内に出力せず、記事内にタグを出力。
    記事内にJavascriptや、CSSを出力するわけです。(あまり好きではないですが・・・さんざんGoogleのモジュールを作成しておいて何を言うって感じですか・・・)

対応していないPluginは、次のバージョン(マイナー)で簡易対応するつもりです。

 XML-RPCですが、Joomla!1.5ではどうもbloggerAPIのみの対応っぽいですね。他のAPI対応の動きは盛んなようですので最終的にはサードパーティーからになるかもしれませんが、公開されるような気はします。私も密かにつくりかけてたり・・・。


 
7 / 11

JContentPlus for Joomla!1.5 powered by Joomler!.net

joomler.net is not affiliated with or endorsed by the Joomla! Project or Open Source Matters.
The Joomla!(R) name is used under a limited license from Open Source Matters in the United States and other countries.
joomler.net is not affiliated with or endorsed by Open Source Matters or the Joomla! Project.