サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
ドラクエ3
tokkono.cute.coocan.jp
「セキュリティ」のタグが付いたプラグイン は、公式サイトに1000個程もあり、その中から「1本」を選び出すのは至難の業でだと思います。 そもそも「セキュリティ対策」と一口に言ってもその範囲は広いわけで、健康管理に例えるなら「予防」や「診断」、「治療」とったカテゴリがあるワケで、さらに「予防」的なものには、 「定期的にバックアップをとっておきましょう」的な「定期検診」系 「常に最新版にアップデートしておきましょう」的な「うがい励行」系 「パーミッションやパスワードを強化しましょう」的な「体力増強」系 「2要素認証やファイアウォールを導入しましょう」的な「マスク着用」系 とまぁ色々あるワケです（ヘタクソな例えでスミマセン）。 一方、WPScan の脆弱性データベース には、プラグインやテーマが毎月10個ほど、続々と登録され続けています。 そこで私が最近こだわっているのが「未知の脆弱性という病巣
2014年12月、NTTコミュニケーションズが「Zero day Attack Protection（仮称）」を開発、今年4月からのサービス開始を発表しましたが、我が WordPress プラグイン IP Geo Block も独自の仕組みにより一部の ゼロデイ攻撃 を防御する機能を追加しましたので、その告知とバグ出しの協力願いをしたいと思います 。 背景 拙作の「プラグイン作者必読！実例に学ぶ脆弱なWordPressプラグインの作り方、又はwp-adminを守る理由」では、脆弱性を持つプラグインの多くで「重要な処理」を行う際、「権限と nonce の検証」が欠落していることを明らかにしました。またその後も 同様の例 が後を絶ちません。 本来なら WordPress 自体が本質的にセキュアな仕組みで出来ていて、この手の脆弱性を作り込む余地がないのが理想でしょう。一方で、もしそんな作りになっ
セキュリティ・コンサルティング Sucuri の 2014年11月の記事 によると、WordPress プラグインの3大脆弱性は、SQL インジェクション（SQLi）、クロス・サイト・スクリプティング（XSS）、ファイル・インクルージョン（FI）とのことです。 冒頭のグラフ は最新の分析結果で、この事実を裏付けています。プラグイン開発の チュートリアル や 手引き には、脆弱性を作り込まないためのポイントが上手にまとめられているのに、なぜ無くならないのでしょうか？ 「ヒトが作るものだから、バグがあって当然」と言ってしまえばそれまでですが、 Sucuri のブログ を読み漁っていると、こと脆弱性に関する限り、 WordPress に特有の「思い込み」や「見過ごし」といった、ヒトの心理的・認知的な盲点が原因の多くを占めているんじゃないかと思えてきます。 だから単に PHP のセキュリティ Ho
昨年末、一晩で15000余りの パスワード辞書によるクラッキング を受けました。その時のログを分析してみて改めて思ったのは、「これだけランダムで長けりゃ大丈夫」的なパスワードも、「漏れたら終わり」って事です。 「ランダムで長いパスワード」をアカウント毎に頻繁に変えるのは面倒なワケで、長い間変えずに使い続けと、漏洩時のリスクが極めて高くなるってことだと思います。 おっと、何も パスワードの定期変更は必要か の議論へ乱入しようというワケじゃありません。 IPアドレスのジオロケーション情報を元に海外からの投稿を弾くスパム対策プラグイン IP Geo Block に、wp-login.php や wp-admin/admin.php、xmlrpc.php へのアクセスを遮断するセキュリティ機能、さらにはログを記録する機能を追加したので、その告知が本記事の主題です 。 IP Geo Blockの制作
AngularJS の勉強、始めました。 最初はそのプログラミングに関する独特のお約束事項にイラッとしましたが、キモであろう DI を「疎な関係のクラスを（実行時に）結びつけるのに必要な仕組み」と割り切り、DI – 猿でも分かる! Dependency Injection: 依存性の注入 で引用されている ITpro 記事 の クラス図 をコードから想像できるようになったところで、それなりに面白くなってきました。 何より「jQuery が要らなくなる！」のがとっても快感なんです （つらい時もあるけど…）。 さて今回は、jQuery まみれのページを AngularJS で書き換えた時に気付いた Ajax の動作 − 非同期通信の戻り値をいつどこで DOM に反映するか − に関する話題を書いてみます。 jQueryの場合 検索のクエリを渡すと Github のリポジトリを返す関数を例にとっ
ここ数日間、本サイトではスパムの連投が流行っています 。 こいつらに貴重なサーバー資源を食われるのは1ミリたりとも許せないワケで、かつては日本以外の IP アドレスを .htaccess に手作業で書き込んでいましたが、あまりにも量が多く、馬鹿げているので止めました。 そんなワケで作ったのが、海外からの投稿を Akismet の起動前に弾く IP Geo Block というプラグインなんですが、スパムは激減するものの、IP アドレスの検索に少々時間がかかるのが気になる点でした。 で、この度、一度検索した IP アドレスをキャッシュに保持する機構を付けたところ、思いの外、効果があったので、バージョン 1.1.0 として告知したいと思います 。 バージョン 1.1.0 での変化点 主に次の3つです。 一度検索した IP アドレスと国コードを一定期間キャッシュする機能を追加。 サービス提供元で生
ある記事 によれば、レスポンシブ Web デザインを採用するサイトの 72% が、デスクトップとモバイルに同じリソースが使われているそうです。またそれらリソースの 60% 以上が画像 という統計や、モバイル用に画像を最適化すれば、データ量を 72.2% 削減できる という調査結果もあります。 ということで、レスポンシブ画像のことを調べていていましたが、その技術進化というか、紆余曲折も含めて色々とある様です。 最新技術を素早く取り入れることはもちろん大事ですが、特に過渡期においては、変化に強いサイトを作るためにも技術の先行きを見極めることが重要です。そこでタイトルのような視点で、これまでの経緯をつらつらと辿ってみました。 自分としてのテーマは、「じゃあ、今、どうするか？」だったのですが…。読んで下さる方の何かに役立つかどうかは甚だ心もとない記事です。 ちなみに今回記事で取り上げた話題について
WordPress は、プラグインで手軽に機能が拡張できる反面、あちこちに css や js が散乱し、放っておくとベスト・プラクティスからは程遠い状態になりがちです。 もちろんこういった問題の解決を図るプラグインも多数リリースされていますが、ページ単位の処理なので、サイト全体の構成を通して最適にはなりません。 そこで第1部「サイト高速化の「戦略」と「戦術」- GradeAのその先へ」、第2部「サイトに適したリソース配置とasync/defer完全マスター – レンダリング優先のグッド・プラクティス」では、数あるベスト・プラクティスの全体を俯瞰し、個々の Tips やテクニックからは見え難い、最適化の考え方や道筋を提案しました。 その総仕上げとして今回は、WordPress サイトを例題に、必ず結果の出る HTTP リクエストの削減方法を提案したいと思います。 実践的手法の概要 HTTP
タイトル、少し変えました 😉 。 第1部「サイト高速化の「戦略」と「戦術」- GradeAのその先へ」では、YSlow や PageSpeed がアドバイスする Tips のうち、HTTP リクエストの削減を優先すべしという「戦略」の話をしました。 また css や js を束ねて結合し、HTTP リクエストを削減する時の「戦術」の話もしました。 今回は、「サイトの特性に適したリソースの配置を行う」ために、「束ねたリソースをドキュメント中にどう配置するのが適切か」を見い出したいと思います。またそのポイントとなるブラウザの基本的な挙動についても言及します。 ブラウザごとの挙動が確かめられる、実験サイト contentloaded.com を立ち上げたので、以下、同サイトから幾つかの例を引きながら話を進めたいと思います。 リソース配置を決める戦術 基本的な戦術 第1部 では、css や js
サイト高速化をネタにした記事は星の数ほどありますし、YSlow や PageSpeed、あるいは両方同時にチェックできる GTmetrix のおかげで、アドバイスに従って問題点を一つ一つ潰し込んでいけば、着実にスコアを「Grade A」に近づけられるようになりました。 またベスト・プラクティスなんて知らなくても、「CloudFlare 導入、一発 OK！」なんていうお手軽なサービスもあります。 一方、これら個々の Tips、テクニックを断片的に積み上げていくアプローチやブラックボックス方式では、サイト全体を通して「本当に最適なの？」という疑問も生じます。 別な言い方をすれば、「Grade A は取ったけど… その先は？」に対する処方箋が必要なんじゃないかと思っています。 そこで今回は、「スコア」だけでは見えてこない、サイト高速化の「戦略」と「戦術」の話にチャレンジしてみたいと思います。これ
スパム投稿を選別して弾くプラグインは、Akismet はもちろん、CAPTCHA を使うタイプ、日本語を含まない投稿を禁止するタイプ、ロボット投稿の裏をかく隠しフィールドを備えたタイプなどなど、数多くあります。 それぞれに一長一短がある中で、投稿者の国を選別するプラグインがあっても良いんじゃない？ ということで、これまた一長一短のあるプラグイン IP Geo Block を作りました。島国ニッポンならではの割り切りができる人なら、お試しください 😀 。 IP Geo Block 原理は単純で、投稿者の IP アドレスが属する国を、ローカルのデータベースまたは外部 API を利用して調べます。受け入れOKな投稿はさらに Akismet で選別される手はずとなっています。 また特徴の1つとして、スパム投稿自体を減らしてくれるかもしれない機能を搭載しています。 インストール プラグイン公式ペー
IP アドレスからサーバーの地理的位置情報（Geolocation）を調べてくれるオンライン・サービスは、ちょっと検索すればすぐに見つかりますし、有料のサービスも山ほどあります。が、サーバーから任意の IP アドレスが引ける無料のサービスとなると、ちょっと時間をかけて検索しなければなりません。 今回は、海外からのコメント・スパムをブロックする WordPress プラグインを作りたくて、タイトルの様なサービスを調べてみました。 IP Geolocation の歴史も調べてみましたので、雑学系としてもご覧ください。 IP Geolocation の歴史 IP アドレスから ISP の位置情報を推定する技術は、1990年後半から研究されていました。DARPA がメインスポンサーの非営利団体 CAIDA（インターネット・インフラの発展のために、産学官が管理面・技術面で協力し合う非営利団体）が N
zenback の読み込みコードが非同期化され、かつ 平均20%+の速度アップが図られた そうで、ユーザーとしては嬉しい限りです。 zenback に限らずソーシャルメディアの導入は、必然的に外部サービスを多用することになります。どのサービスも、スクリプトや画像、トラッキング用コードなどのリソースを、その特性に合わせて 2〜4 程度のホスト／ドメインに分散させているのが普通です。 こういった分散化は並列に読み込みめるリソース数を増やし、クッキーのあり／なしを区別できるので高速化に寄与します。が、利用するサービス数が多くなると、いわゆる「DNS ルックアップ」にかかる時間が無視できなくなり、さすがにデメリットの方が目立ってきます。 例えば本サイトの場合、最終的に25以上の異なるホスト／ドメインから 有象無象 のリソースを読み込んでいるのですが、「DNS ルックアップ」の合計だけで1秒を超える
sitepoint から「本当にjQueryが必要ですか？」とタイトルのついた3本の記事を紹介します。 Do You Really Need jQuery? Native JavaScript Equivalents of jQuery Methods: the DOM and Forms Native JavaScript Equivalents of jQuery Methods: Events, Ajax and Utilities 言うまでもなく著者の Craig Buckler さん の趣旨は、「jQueryを使うのは止めよう」ではありません。ネイティブ関数で代替えできるのは、古い IE のサポートが必要なく、ごく簡単なケースに限られます。その代わりに得るものは「速さ」です。そこで、どの程度「速い」のかを所々 jsperf の結果で補ってみたいと思います。 また JavaScri
単にウケ狙いなら「革新的！GAのページ平均読み込み時間を劇的に速くする方法」とか「もう3rdパーティーに邪魔させない、超高速スクリプト読み込み術」（笑）とかの煽りタイトルを付けるところですが、今回はもっと本質的なことを論じてみたいと思います。 「プログレッシブレンダリングでUXを向上させるJS非同期読み込みのベストプラクティス」では、スクリプトの読み込みと実行を window.onload 対象から切り離し、見た目のページ速度を速くする方法について書きました。この方法は既存のスクリプトを書き換える必要があるため、Stoyan Stefanov によって 実験的に実装された Facebook SDK か、自前のスクリプトにしか適用できませんでした。 しかし今回、Hatena や Twitter、Pocket、Disqus など、他の 3rd パーティ製スクリプトにも適用できる方法 − “進化
意外と要注意… なんて記事を書いておきながら、実際に HTML5 のカスタム・データ属性にオプションを指定する jQuery プラグインを作っていて、かなりハマってしまいました。 data-* 属性に書いた複雑なオプションを jQuery Data API で処理するには、JSON で指定しなくちゃダメなんですネ。ちゃんと ドキュメント にも書いてありました 😉 。 ということで、「もっと簡単に記述できるようにしたい！」を叶える 簡易な data-* 属性パーサー を作りましたので、ここに発表します。 ついでに data-* を使った jQuery オプション指定のユースケースを整理し、その実装方法をまとめてみたいと思います。 jQuery オプションと data-* のユースケース プラグインの設計段階では、オプションの構造とその指定方法を想定しておくことが重要です。そこでまず、想定し
本ブログでは、サイトの高速化に直結する「JavaScript 非同期読み込み」の話題を多数取り上げてきました。タイトルに釣られてこの記事を見てくれている方なら Google Analytics の非同期コードスニペット はご存知でしょうし、規模の大きいサイトやアプリ用に RequireJS などのフレームワークを使っている方もいるでしょう。 GA も RequireJS も、動的に生成したスクリプト要素を DOM に埋め込む「DOM 挿入法」が用いられています。さらに遡れば、Steve Souders が 2009年4月の記事 ノン・ブロッキングなスクリプト読み込み で、6つの手法に分類しています。 果たしてこれらの方法は、サイトの高速化にとってベストなのでしょうか？ 答えは2012年12月の海外記事にありました。そこで本エントリーでは、日本ではほとんど取り上げられていない Frame i
キャッシュ系プラグインを入れて速くなった気がしていても、Google Analytics の「サイト速度」が思ったほど速くなってない、なんて言う経験はないですか？ 今年の4月に発覚した WP Super Cache と W3 Total Cache の、心底ヤバイ 脆弱性騒動 も乗り切り、懲りもせずタイトルの様なことを試しています 😉 。 特に共有サーバーで運営しているよいこの皆さんは、絶対にマネしちゃイケナイ、本サイトのヒミツを暴露しちゃいますネ 😉 。 キャッシュを導入しても速度が上がらない理由 そもそも WordPress のキャッシュ・プラグインは、下の図のように、ページが要求されてから最初の HTML ドキュメント生成までの時間を短縮するものです。 かつ、速度的には 圧縮して応答するのが効果的 です。それ故、ページを丸ごと圧縮しておく「ページ・キャッシュ」が、応答時間と転送時
*2: 管理画面のページを含みます *3: ログインユーザーと非ログインユーザーを両立させるには、キャッシュ・プラグインの使い方に注意しなければならないでしょう *4: CSRF 攻撃だけでログインユーザーの秘密情報が漏洩することはありませんが、他の脆弱性との複合を考えれば、使用すべきかと思います *5: 公開ページであっても、ログインユーザー専用の情報を表示する場合には *4 と同様、使用すべきかと思います。 Ajax には Ajax の セキュリティ上の注意すべき事項 が多数あります。特に XSS 脆弱性 があると秘密情報が漏洩し、せっかくの CSRF 対策が台無しになる可能性もあります。使われる文脈と目的に合わせ、抜け目なく実装しましょう 😛 。 nonceを組み合わせたAjaxの実装方法 やっと本題です 😉 。ここからは myajax プラグインの実装を想定し、5つのステップと
WordPress のプラグインを作って公開すべく、基礎からみっちり学習しています。 Codex 日本語版 の プラグインの作成 の項には、外部リソースとして Ozh さんの2009年記事 「WordPress プラグインのコーディングでよくある10個の間違い」 が紹介されています。 Professional WordPress Plugin Development の著者でもある Ozh さんは、WordPress プラグイン・コンペティションの審査員を努めて来た関係上、今までに相当数のプラグインをレビューしているそうです。 私も色々なプラグインのコード・リーディングをしてみましたが、古いけど良質なこの記事が、必ずしも広く認知されてるわけではないことを感じています。 ということで、古くなっている部分を新しい情報で補いながら、この記事を翻訳で共有してみたいと思います。 タイトルにある通り、
これまでも サービスAPI の更新や、それに伴う UI の変更など、小刻みな機能向上が図られていましたが、昨年11月、GitHub の ヘッダ、フッタが新しくなった のを皮切りに、12月には Gist のリニューアル と GitHub トップページのリニューアル が立て続けに行われました。 また今年1月には、ユーザー数が、アカウントベースで300万人を超えた そうです。 小さくかつ素早く、不断のサービス向上を図る姿勢が、ここまでユーザーを惹き付けた理由なのでしょう。 一方、公式ブログ を追いかけていくと、単に Git のリポジトリ・サーバーとして便利で使い易くする以上に、「自然に人が集まる魅力的なコミュニティ」を目指し、「誰もが気軽に参加できるオープンソース・コミュニティを創る」という意気込みのようなものを感じました。 人が集まれば、それだけビジネスの機会も増えるというワケです。 そこで今
WordPress の WPtouch や Ktai Style とキャッシュ系プラグインを 併用 する場合には、キャッシュさせないように設定するのが一般的でした。なぜなら、同じ URL のページを、デスクトップ用とモバイル用のキャッシュに分ける事が難しく、両者が混在しちゃうという問題が発生するからです。当然、ケータイやスマートフォンは、キャッシュの恩恵が受けらないですよネ。 ところが Quick Cache なら、オプションでたった1行のコードを設定すれば、それぞれのページを別々にキャッシュできちゃうんです。 ということで、前回記事 では wp-config.php にコードを追記しましたが、今回はもっとスマートに、Quick Cache 側に設定する Tips として紹介したいと思います。 設定 まずは、ユーザーエージェント文字列がスマートフォンなら "smartphone" を、ケー
つまりブラウザ側でのキャッシュを許容しておらず、有効時間内であっても、常に 200 OK と共にフルコンテンツを返します。 一方 True ( Allow ) に設定した場合、上記ヘッダフィールドは一切送られません。その結果ブラウザは、キャッシュの扱い方に関する情報が得られず、単にリクエストするだけとなり、レスポンスも 200 OK のままとなります。 スマホのためにも、少しでも通信量を減らす設定が欲しい所だと思いますが、どうでしょうか？ プリロード 予めキャッシュを生成しておくプリロードは、「Sitemap Auto-Caching」 で設定します。 設定のポイントは、次の通りです。 キャッシュ有効時間の推奨値は86400 （24時間） で、3600 未満だと動作しません。 プリロードするページのリストをサイトの sitemap.xml から得るので、Google (XML) Sitem
Lacoocan が重たい腰を上げ、今年３月末から MySQL5 が利用可能 になったのを機に、WordPress を 3.4.2 に上げると共に、プラグインを1から見直しています。 すぐに キャッシュ系プラグイン に手を出すのではなく、なるべく素の特性を観ながら、選ぶ楽しさを味わうのもイイかなと。 そんな中、Google Analytics （以下 GA） の集計結果を読み込み人気記事として表示する Google Analytics Popular Posts （以下 GAPP） というプラグインを使いたいと思ったのですが、そのキャッシュ設定をオンにしても、GA との通信で更新に数秒かかってしまうという問題に直面しました。 つまり、たまたま更新のタイミングに当たった運の悪い人にとっては、重たいブログとなってしまうのです。 そこで今回は、そういったプラグインに起因する重たい処理を訪問者のア
LaCoocan の ZEUS サーバー では apache_request_headers() が動作しません。恐らく IIS も、です。なのに WordPress のプラグインとかで、Apache を前提にしたコードを使うのって、反則だと思いません？ なぜこの話題かというと、LaCoocan で WP Super Cache 0.9.9.6 を導入したんですが、コードを眺めていたら幾つかの箇所で使われているんですヨ、コレが。 実は、特定のユーザーエージェントにはキャッシュの静的ページではなく、通常の動的ページを送りたい、というワケがありまして…。apache_request_headers() が動作すれば、「除外するユーザーエージェント」 に設定した文字列を含む相手には、動的ページを送りそうなことが分かったんです。 そこで、本来の W3 Total Cache の仕様 （キャッシュが
ここ最近、jekyll に関する記事を目にする事が多くなりました。 以前から WordPress でオリジナルなブログを作ってみたいと思いながらも、なかなか重い腰が上がらなかった私が、なんとなく jekyll でブログを作り始めてみたら、以外にオモシロかった、という話をまとめてみたいと思います。 本来生まれも育ちも違う、WordPress と jekyll を比べる こと自体はナンセンスなので、jekyll でどこまでできるかが本記事のメイン・テーマです。 大抵は 「ブログなら、最低このぐらいの機能が欲しいよネ」 というのがあると思います。例えば、私も使っている Octopress では、カテゴリとタグを使い分けることが出来ません。またカテゴリを階層化したい人もいるでしょう。「続きを読む」的な機能だって、欲しいですよネ。 一方海外では、「WordPress から jekyll に乗り換えま
2012年2月、Modernizr 2.5 の カスタム・ビルダー から Respond.js が外されました。理由は、HTML5 Boilerplate （以下 H5BP） コミュニティでの決定です。Respond.js は、IE8 以下などのメディアクエリ未対応なブラウザにもその代替え機能を提供するスクリプトで、レスポンシブ Web デザイン を支えるスクリプトとして、H5BP に長らく （8ヶ月） 採用されてきた経緯があります。 ではなぜ、Respond.js は外されたのでしょう？ 今回は、その決定を下した長～い議論 Issue #816: Revert mobile-first media queries and remove respond.js から、ベスト・プラクティスの要点と、Paul Irish の考える H5BP の理想像を読み解いてみたいと思います。 ヘタクソで読み
2010 FIFAワールドカップ の開催に合わせ、今や ウェッブトラフィック全体の10%～20%を配信している といわれるコンテンツ配信事業の最大手、Akamai が 特別ページを開設 し、ネットワークトラフィックをヒートマップ表示しています。ワールドカップ開催中はトラフィックの増加が見込まれるため、通常の Real-Time Web Monitor よりスケールを拡大して模様です。試合の開催国と開催日を FIFA.com で調べ、トラフィック増加の様子を逐一眺めてみるのも、ワールドカップの別の楽しみ方かもしれません （ナイナイ 😉 ）。 ちなみに、ワールドカップのカレンダーはこちらが抜群に美しくて見やすいです。 さて、今回は Akamail をはじめ、世界の 今 をビジュアルに知ることが出来るような統計情報を公開しているサイトを幾つか集めてみました。 Akamai: The Leade
6月22日未明、Twitter のサーバーがダウン し、全世界でサービスが停止しました。一部マニアの方々は、動いていた ケータイ用サーバー から この状況を楽しんでいた (?) ようですが、OMG..twitter was down….closest thing to living without oxygen for most of us…. （なんてこった、オレたちに酸素なしで生きろっていうのか） という声に代表されるように、世界各地で悲鳴が上がったようです。 さて純正の Twitter ウィジェット を貼っているあなたのサイトは、この障害でページが真っ白になったり途中で引っかかったりせず、無事にコンテンツを提供できたでしょうか？ ということで、前回 と同ネタですが、こういった フロントエンドの単一障害点 （SPOF） をより簡単にチェックできる Chrome エクステンション SPO
次のページ
このページを最初にブックマークしてみませんか？
『とっこの「お絵描きが好きっ♪」』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
