Gumiki::Official Site
大小さまざまな規模のWebサイトをブラウザ上から容易に構築できるCMSシステム"Gumiki"の公式サイトです

認証設定ガイド

 管理者ガイドでもある程度触れていますが、こちらでも改めて。
 ここでは.htaccessの記述の仕方について触れています。実はGumiki専門の話ではなくて、cgi一般に適用できるお話です。たとえば認証の仕組みを持っていないFreeStyleWikiLiteなどもここの記述を参考にすると認証をかけられるようになります。

認証の必要性

 Gumikiは閲覧ページと編集&管理ページから成りますが、閲覧ページからは常時「レルム編集 | ページ編集」というリンクが表示されており、ここを押すと編集&管理ページに移動します。
 さて問題なのは、あなたのサイトはどういう利用者を想定しているかということです。誰が閲覧できて、誰がページの編集ができるかという事の切り分けが必要となります。

項番閲覧権編集&管理権用途および注意事項
1誰でも閲覧できる人全てWiki的な「みんなで作り上げるページ」用途。但しGumikiはPukiWikiのようなバックアップや編集ロック機能はありませんので消されたページは元に戻せません。そういうリスク込みで運用することになるでしょう。一応、月に1度バックアップを手動でとるなどの決まりごとを儲けておけば、いざと言う時にも被害は最小限に食い止められますが、誰でも管理ページにアクセスできてしまうので、悪意ある人間が一人出てしまうと、サイト運営が破綻してしまいます。正直現状のGumikiではこの用途はお薦めできません。
2誰でもあなたのみごく標準的な個人ホームページはこのケースに当たるはずです。
3誰でもあなたを含めた少数複数人でホームページを管理する場合
4特定の人たちあなたのみあるコミュニティ専用ページを作り、あなたがその代表としてページを提供する立場の場合
5特定の人たち閲覧できる人全てあるコミュニティ専用ページを作り、そのコミュニティメンバー内で自由に編集してもらう場合。項番1と違い特定の人間しか編集できないわけですから、悪意ある人が紛れ込む恐れは低く、善意の運用ができます。
6あなたのみあなたのみホームページではなく、あなた専用の作業ページとしてGumikiを活用する場合

 恐らくこのいずれかの運用になるものと思われます。
 そして、項番2〜6で運用するためには、閲覧ページあるいは編集&管理ページにアクセスする際に、パスワードによって認証をかけておく必要が出てきます。
 このパスワード認証機構として、Gumikiは2種類の方法を提供しています。そのひとつがBASIC認証と呼ばれるものです。これはホームページの世界ではそれなりに一般的な認証の仕組みになっており、Webサーバ上に .htaccess と .htpasswd といったファイルを設置することによって実現できます。
 しかし、プロバイダによってはこの .htaccess が使えないところなどが存在しています。(OKな例:SAKURA Internet / NGな例:BIGLOBE)
 この場合は、Gumikiが独自に持っている認証システム(Gumiki認証)を用いることになります。

 以下はBASIC認証を用いた場合の設定方法となります。

項番1(オープンアクセス)の場合

 誰でもアクセスでき誰でも管理ページにアクセスできる=認証を必要としない場合です。よって、.htaccessなどの設置は不要です。

項番2、3(個人サイト)の場合

 閲覧にあたっての制約は無く、編集に際してパスワードを求めることになります。
 つまり、編集用cgiであるedgumiki.cgiのみが認証管理対象ファイルとなります。

◆.htaccess 設定例
<Files edgumiki.cgi>
AuthUserFile /home/******/www/********/.htpasswd
AuthGroupFile /dev/null
AuthName "Can edit Gumiki page only administrator"
AuthType Basic
require valid-user
</Files>

<Files .htaccess>
order deny,allow
deny from all
</Files>

 こういう内容の.htaccessファイルと共に.htpasswdファイルを設置し、Gumikiのcgiの置いてあるディレクトリにパーミッション755で配置します。.htpasswdファイルの詳細については管理者ガイドを参照してください。
 これにより編集ページにのみパスワード認証が掛けられたサイトとなります。

項番4(管理者を置いたコミュニティサイト)の場合

 閲覧するためにパスワードで聞いたうえで、さらに編集に際しては別のパスワードを求める事になります。
 閲覧cgiである gumiki.cgiと、編集cgiである edgumiki.cgiに別々の認証管理を行うことになります。

<Files edgumiki.cgi>
AuthUserFile /home/******/www/********/.htpwedit
AuthGroupFile /dev/null
AuthName "このページの編集には特別な権限が必要です"
AuthType Basic
require valid-user
</Files>

<Files .htaccess>
order deny,allow
deny from all
</Files>

AuthType Basic
AuthName "閲覧するにあたってはパスワードの入力が必要です"
AuthUserFile /home/******/www/********/.htpwview
require valid-user

 .htaccessの記述は以上のようになります。
 この場合、2通りのパスワードファイルが必要になります。
 名前は何でもいいのですがここでは .htpwedit と .htpwview としました。これらのファイルの作成方法は .htpasswdの時と同じように行ってください。

項番5(全員に編集権を与えたコミュニティサイト)の場合

 閲覧するためにパスワードを聞きますが、閲覧者=編集可能者、というケースの場合は、フォルダ全体が認証管理対象となります。

AuthType Basic
AuthName "このページは認証情報を入力する必要があります"
AuthUserFile /home/******/www/********/.htpasswd
require valid-user

 .htaccessの記述は以上のようになります。
 もちろん別途.htpasswdファイルを準備し、それぞれをcgiと同じディレクトリに配置することになります。

項番6(自分の秘密ページ)の場合

 項番5の、権利者があなた1人であるという限定状況であり、項番5と同じ方法で認証をかけます。
 余談ですが、あなた専用ということは、.htaccessによる認証をしなくても、隠しページにcgiを設置すれば、一応あなただけしか知らない以上問題ないという考えがあります。しかし、いつどこでその隠しページが発見されるか、Webの世界は分かったものではありません。そしてひとたび見られてしまえば、項番1と似たような状況になりえるわけです。運用は自己責任でお願いします。


トピックガイド