土日にコツコツとWordPressプラグインを作って、WordPress.orgへのプラグイン申請と公開が通りました。
Agenda
プラグインについて
WP Similar Basic Auth
プラグイン名は「WP Similar Basic Auth」という名前です。
WordPressで「Basic Auth」と検索すれば見つかります。
なにができるのか
Basic認証風にログインをかけることができるプラグインです。
つまり、Basic認証ログインとWordPress管理画面ログインと、2段階のログインにすることができます。
WordPressの利用率が世界的に多いことやWordPress管理画面のデフォルトURLが決まっているため(補足:URL変更できるプラグインもあります)、だれでも簡単にアクセスできてしまいます。そのため、WordPress管理画面のログイン突破が狙われることが多いです。
WP Similar Basic Auth プラグイン では、ログイン突破に関して少しだけセキュリティ強化をすることができます。
利用シーン
以下に該当する方はお役に立てます。
- ホスティングサーバー上で.htaccessやssl.confを設定変更できない
- Basic認証を設定したいが技術的な知識がない
注意点
WordPress管理画面に2段階のログインを設定するだけで安心ということはありません。根本的なセキュリティ対策は、WordPressやプラグインの脆弱性を即時になくすことが最優先になります。
また、 WP Similar Basic Auth プラグイン は、アプリケーションレイヤーで実装しているため、Basic認証とは仕組みが異なります。そのため、Basic認証に置き換わってセキュリティ強化できるわけではありません。
【(参考)実装レイヤー】
Fronts-end (ex: CSS, Javascript)
Application Plugin <--- WP Similar Basic Authプラグイン
Application (ex: WordPress)
Programming language (ex: PHP)
Middleware Web (ex: Apache, Nginx) <--- .htaccess Basic 認証
Middleware DB / OS
やむをえない事情がない限りは、Basic認証を設定されることをおすすめします。
WordPressプラグイン開発の利用技術
フロントエンド
- HTML, CSS, JS
アプリケーション
開発ツール
テストフレームワークは、本業で Behat を利用していますが、PHPUnitも思ったより利用しやすかったです。今回はPHPUnitとTravisCIの組み合わせを利用しました。
VCCW でのWordPress環境構築作成が、MAMPに比べて「かんたん」「速い」「いくらでも環境が作れる」という仕組みのため、開発環境として必須となりました。
WordPressプラグイン開発の参考情報
書籍
- サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル
プラグインの開発知識は、ほぼこの本のみです。この本と書いてある内容を検索して調べる、というのを繰り返しました。
ソースコード
WordPressのプラグイン開発は、 Ruby on Rails や Laravel のように体系的に整理されたベストプラクティスが見つからず、どういう設計にしたらよいのかわからなかったため、それが一番困りました。
WordPress流(?)のプラグイン開発に従いたかったため、MVC化などはせず、著名なプラグインのソースコードを参考にしました。
- wp-premium /advanced-custom-fields-pro
プログラミング全体の設計方法は定番プラグインのACFを参考にしました。 - Automattic / sensei
Automattic社のSenseiというソースコードも設計や思想を参考にしました。 - benhuson /password-protected
パスワード認証の仕組み自体はこちらを参考にしました。 - WordPress /two-factor
同様にこちらの2段階認証のプラグインもパスワード認証の仕組みを参考にしました。 - WordPress / wp-includes / pluggable.php
Cookieにログイン状態を管理するためのデータを格納する仕組みは、WordPressのコアモジュールを参考にしました。
開発コード一式
以下に全ソースコードを設置しています。
256hax / wp-similar-basic-auth
プラグインの申請
サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル のバイブル本と 開発したWordPressプラグインを公式サイトで公開する手順 - まちゃの休息 を参考にしました。
申請1回目
12/31深夜に1回目の申請をしたところ、1/1(なんと!)に以下の返信がありました。
要約すると、「サニタイズは早く、エスケープは遅く、そして常にバリデーションを」という実装と、「不要なファイル郡の削除」が求められました。
There are issues with your plugin code.
Please read this email in its entirety, address all listed issues, and reply to this email with your corrected code attached (or linked).
Remember in addition to code quality, security and functionality, we require all plugins adhere to our guidelines. If you have not yet, please read them:
Detailed Plugin Guidelines
You will not be able to submit another plugin while this one is being reviewed, so please read the email carefully. We know it can be long, but you must follow the directions at the end as not doing so will result in your review being delayed. It is required for you to read and reply to these emails, and failure to do so will result in significant delays with your plugin being accepted.
## Data Must be Sanitized, Escaped, and Validated
When you include POST/GET/REQUEST/FILE calls in your plugin, it's important to sanitize, validate, and escape them. The goal here is to prevent a user from accidentally sending trash data through the system, as well as protecting them from potential security issues.
SANITIZE: Data that is input (either by a user or automatically) must be sanitized as soon as possible. This lessens the possibility of XSS vulnerabilities and MITM attacks where posted data is subverted.
VALIDATE: All data should be validated, no matter what. Even when you sanitize, remember that you don’t want someone putting in ‘dog’ when the only valid values are numbers.
ESCAPE: Data that is output must be escaped properly when it is echo'd, so it can't hijack admin screens. There are many esc_*() functions you can use to make sure you don't show people the wrong data.
To help you with this, WordPress comes with a number of sanitization and escaping functions. You can read about those here:
Securing Input
Securing Output
Remember: You must use the most appropriate functions for the context. If you’re sanitizing email, use sanitize_email(), if you’re outputting HTML, use esc_html(), and so on.
An easy mantra here is this:
Sanitize early
Escape Late
Always Validate
Clean everything, check everything, escape everything, and never trust the users to always have input sane data. After all, users come from all walks of life.
Example(s) from your plugin:
wp-similar-basic-auth/includes/class-cookie.php:151: $cookie = $_COOKIE[ $cookie_name ];
## Included Unneeded Folders
Your plugin includes folders and files that are not required for the running of your plugin. Some examples are:
vendor folders (bower, node, grunt, etc)
documentation
demos
unit tests
The entire library isn't going to be used by your users, and having all those files included is just extra weight to a plugin.
If you're trying to include the human-readable version of your own code (in order to comply with our guidelines) remember that we permit you to put links to them in your readme.
Detailed Plugin Guidelines
If you’ve made a Block plugin and used npm and webpack to compress and minify it, you can either include the source code within the published plugin or provide access to a public maintained source that can be reviewed, studied, and yes, forked.
But you can, and should, safely remove those other folders from your plugins.
Example(s) from your plugin:
wp-similar-basic-auth/tests/
You should remove that as those could be harmful to your users.
---- ---- ---- ----
Please make sure you've addressed all issues brought up in this email. There is no timeframe on this review, however if we have no response from this email address in 6 months, we will reject this submission. To keep your review active, all we ask is that you make corrections and reply.
When you've corrected your code, reply to this email with the updated code attached as a zip, or provide a link to the new code for us to review. If you use gmail, you won’t be able to send a ZIP file if it contains any JS files (yes, we know it’s stupid, blame Google).
If you have questions, concerns, or need clarification, please reply to this email and just ask us.
(While we have tried to make this review as exhaustive as possible we, like you, are humans and may have missed things. As such, we will re-review the entire plugin when you send it back to us. We appreciate your patience and understanding in this.)
--
WordPress Plugin Review Team | plugins@wordpress.org
https://make.wordpress.org/plugins/
Detailed Plugin Guidelines
申請2回目
1/6に全体的に修正して再送付しました。またしても翌日に以下の回答があり、「レビューが通りましたよ」とのこと。
Your review has been successfully completed. Details on how to access your SVN repository will be emailed within 24 hours to the address from which you submitted your plugin.
なお、1点注意事項があり、JSファイルが含まれているとGmailで送信できないのです。そのため、自分の場合はGitHubのRelease機能でリリース用ファイルを置いて送付しました。以下のような感じです。
Hello WordPress Plugin Review Team,
Happy new year!
I fixed my plugin code. Could you review again?
Here is my plugin code zip link.
https://github.com/256hax/wp-similar-basic-auth/releases/download/v0.1.1/wp-similar-basic-auth.zip
Thank you!
あとはSubversionのお作法に則ってWordPress.orgに公開しました。
マイハンドブック
WordPressプラグイン開発で、VCCWの起動からPHPUnitの実行、i18n対応、Subversionのアップ方法など、覚えないといけない手順書が多かったため、自分用ですがハンドブックを作りました。