以下は JE2BWM ほかが作成した翻訳です。原文は University of California より GFDL で配付されており、この翻訳も GFDL に従います。
原文: New setup proposal (翻訳対象の更新日付は 5:20 PM UTC, August 14 2005 です)。

新しいセットアップの提案

はじめに

BOINC の新しいインストール・セットアップの仕組みを提案します。目標は、単純化と親しみやすいこと、そして、プロキシの設定が必要であってたとしても、セットアップがうまくいくことです。主な変更点は以下のとおりです。

参加者から見ると、アカウントを識別する手段が、参加者が指定した一意の識別子(E-メイルアドレスあるいは参加者の名前)と、これまた参加者が指定したパスワードの組合せに変ります。識別子にどちらを使うかは、プロジェクトごとに決めることができます。 BOINC 標準のソフトウェアでは、E-メイルアドレスが使われます。
E-メイルアドレスを使うに際して、確認は取りません。アクセスできない E-メイルアドレスを使ってアカウントを作ることに、なんの制約もありません。 E-メイルアドレスが使えるものであることを確認した、という意味の 'email_verified' というフィールドを BOINC のデータベースに追加し、確認のための仕組みも追加します。今のところ、この確認が必要になるのは、掲示板で使う E-メイルのためだけです。
上記のアカウントに付随する E-メイルアドレスとパスワードは、ウェブ画面で変更ができます。
セットアップの過程では、HTTP/SOCKS プロキシ設定の必要性を検出して、プロキシユーザの情報入力を促します。
アカウント・キーは依然として使いつづけますが、普通の場面では参加者に見えることはありません。アカウント・キーは、コア・クライアントがプロジェクトのサーバに、コア・クライアント自身を識別・認証させるために使います。アカウント・キーは変更されることは決してありません。 (ですから、コア・クライアントは E-メイルアドレスやパスワードが変更されても、そのことを知らなくて済みます)。

BOINC セットアップの過程

参加者はソフトウエアを手に入れて(ダウンロードするか CD-ROM から)、インストールします。 BOINC マネージャを走らせます。下記の手順を「ウィザード」に導かれて済ませます。 (ウィザードの中には、次へ/戻る(Next/Back)ボタンと、説明文がついた会話画面が順序よく並んでいます)。
参加者は、プロジェクトの URL を入力するよう促されます。
BOINC は該当するプロジェクトと通信して、設定のために構成情報を獲得します(下記をご覧ください)。
もし、サーバとの通信に失敗し、かつ、Google/Yahoo のどちらにもアクセスできないなら、ウィザードは、「サーバとの通信ができませんでした。プロキシ設定が必要かもしれません」と報告します。このときは、ウェブブラウザのプロキシ設定を見つける手順を参加者に示します。そして、プロキシ設定情報を入力する画面を表示します。
参加者は新しいアカウントあるいは既存のアカウントの入力を促されます。つまり、E-メイルアドレスあるいは参加者の名前(どちらであるかは構成情報に依存します) とパスワードです。「新規のアカウント」の場合は、参加者はパスワードを 2回打ち込みます。パスワードの有効性(たとえば、最小の長さ検査)は、 BOINC マネージャが実施します。
BOINC はサーバと通信して、アカウントを見つけるか新規に生成します。そして、プロジェクトにそのマシンを参加させます。
上記の処理に問題が何も無い場合：既存のアカウントの場合は既に処理が済んでいますのでやることはありません。新規アカウントのときには、 BOINC マネージャはウェブブラウザを立ち上げ、アカウント・セットアップのページを開き、参加者が追加のアカウント情報を入れられるようにします。つまり、名前、国名、その他好みの設定値などです。 (名前欄には、その計算機上でのユーザ名を便宜のために埋めた画面が出ます)。
新しいアカウント作成に問題が発生した場合: アカウントに指定した識別子がすでに存在していて、かつ、そのアカウンとは異なるパスワードを指定した場合には、アカウントを新しく作成できません。このときは、適切なウェブページに導いて、E-メイルでパスワードを受けとるよう、参加者に指示を出します。
既存のアカウントで問題が発生した場合: 誤っているパスワードが指定された場合は、適切なウェブページに導いて、E-メイルでパスワードを受けとるよう、参加者に指示を出します。

現状のセットアップ方法と比較してみると以下のようになります。

「ウェブサイトを使ってアカウンとを作成する」という操作がなくなりました。
「E-メイルメッセージの到着を待つ」という手順がなくなりました。
「アカウント・キー」をカット＆ペーストする操作がなくなりました。

ウェブサイトでの操作

ウェブサイトへのログインは、通常、E-メイルとパスワードを使います。クッキーはアカウント・キーを運びます。 (現在稼働しているログインの手段は、 E-メイルとパスワードが変更されたとしても動作します)。
アカウント・キーを使ってもログインできます。
一旦、ログインした参加者はそのアカウントの E-メイルアドレスとパスワードのどちらでも変更できます。 (E-メイルアドレスを更新すると、'email validated' というフラグがクリアされ、旧アドレス、新アドレスの両方に通知の E-メイルが送出されます)。
パスワード取り出すインタフェースは設けません。 E-メイルで送られるようなものも、ウェブで表示するものも作りません。
E-メイルアドレスを入力する画面を(ログインなしで使える)用意し、アカウント・キーをそのメイルアドレスに送ることができるようにします。
掲示板で使える「このスレッドに投稿があったらメイルで通知」という機能は、アカウントのメイルアドレスが確認済みのときだけ使えます。
E-メイルアドレスを確認するためのページがあります。このページをクリックすれば、アカウントの DB ID とアカウント・キーおよび E-メイルアドレスをハッシュしたものからなる URL が、あなたのE-メイルアドレスに届けられます。この URL を訪れれば、使われた E-メイルアドレスが確認されます。

データベースに関する注意

パスワードは、MD5(password, email) という計算結果の形で記憶され (通信にも用いられ)ます。 (MD5を使うことについては、後述のセキュリティに関する注意をご覧下さい)。
E-メイルアドレスを原形がわからないように改変して記憶する方式は消え去ります。
E-メイルアドレス確認済みフラグ(email_validated)を追加します。

パスワードの値の制限

パスワードに使う値への規則:

パスワードは、大文字小文字を区別します。
パスワードの最短長はプロジェクトごとに決定できる項目です。最大長は32文字です。
ASCII 文字の 32 から 126 までのどの文字も使えます。 (この中には、空白と全ての区切り文字が入りますが、制御コードはどれも含まれません)。

問題が生じた場合

密猟 (Poaching): 参加者 X は、参加者 Y の E-メイルアドレスを使ってアカウントを作成できます。 Y さんがのちほど登録しようと試みると、エラーメッセージを受けとることになるでしょう。しかし、Y さんはプロジェクトのウェブサイトに行って、自分へアカウント・キーを送る手続きをすることができます。すると、そのアカウントの E-メイルアドレスを(すきな値に)変更することができます。 Y さんには、そこで登録し直してもらいます。すると Y さんは、自分の E-メイルアドレスのついたアカウントを得ることができるでしょう。そのアカウントには Y さんしかアクセスできません。参加者 X は、古いアカウントにアクセスすることができますが、新しいアカウントにはアクセスできません。
E-メイルアドレスの誤記入: もし参加者が自分の E-メイルアドレスをタイプするときに間違えていたら、 (あるいは、入力した E-メイルアドレスを忘れてしまったら)、プロジェクトのウェブサイトにログインすることは無理です。この場合には、(BOINC マネージャを使い)、アカウント・キーを取り出すことができるので、それを使ってログインしてもらいます。そして、E-メイルアドレスを修正します。
E-メイルアドレスが使えなくなった場合: E-メイルアドレスが使えなくなった場合、その参加者は E-メイルアドレスを、プロジェクトのウェブサイトを使って変更できます。パスワードを忘れてしまっている場合には、 BOINC マネージャからアカウント・キーを得て (前述と同様)、それを使ってログインしてもらいます。

移行

第1期

データベースの参加者のテーブル(user table)に、パスワードの欄を作ります。初期値は(既存の参加者については)、アカウント・キーの値を入れます。
追加のサーバー側機能を揃えます(アカウントの検索・作成の RPC、 PHP のコード)。ログインのページで、E-メイル/パスワードの組を受け入れるように変更します。 E-メイル/パスワードの値を変更するためのページを新設します。
すべてのプロジェクトに更新をかけます。
全てのプラットフォームについて新しいクライアントを公開します。

第2期

ウェブサイトに載せてあるセットアップ手順を変更します。
「アカウント作成」のページを変更し、「以下の手順は、xxxより昔の版のクライアントをお使いのときのみ、実施する必要があります」と記述を入れます。

第3期

プロジェクトのウェブサイトで、「アカウント作成」ページへのリンクを消します。 (古い版のクライアントはまだ走らせることができますが、新しくセットアップを行うには、新しい版のクライアントを使わねばなりません)。

セキュリティに関する注意

一般に、パスワードというものは厳重に守られねばなりません。というのは、参加者のうちのいくらかの人達は、 BOINC プロジェクトに使うパスワードに、より重要な目的のためのパスワードと同じものを使うことがあるからです。アカウント・キーの保護はわずかですが、重要度は少なめです。なぜなら、特定の1つのプロジェクトの1つのアカウントについてのみ、アクセスを提供するものだからです。
パスワードは MD5(password, email) の形式で計算した値を使って記憶され (また、通信に用いられ)ます。 (つまり、E-メイルアドレスの値を、「塩」として使います)。この記憶している値あるいは通信で運ばれる文字列を、ハッカーが (たとえば、サーバーをハックしたり、パケットを盗み見したりなどして) 手に入れたとすると、目的のパスワードを得るのに力ずくの解読方式を使うことができます。しかし、「塩」を付加しているので、あらかじめ計算済みのハッシュ値一覧を一つ使うだけで、その解読を行うことはできません。
「E-メイル/パスワードを使うログイン」のページと、「パスワード変更」のページには、HTTPS を使います。
アカウント・キーは平文のままメイルに載せて運びます。この代わりに、プロジェクトのウェブサイトでアカウント・キーを見せるようにして、その画面にアクセスさせるトークン付き URL をメイルで送るというやり方に変更できるかもしれません。しかし、そうしてもセキュリティは向上しないと私は思います。スケジューラ RPC の要求は平文であり、上記のアカウント・キーを含んでいることを思い起こしてください。

その他のコメント、要望、アイデア

(Korpela): E-メイルまたはパスワードをアカウント・キーと役目を交代させるべきではないか？ (しかしそうしたら、E-メイルアドレスの誤記とそれが使えなくなった場合の解決法が働かなくなります)。
各計算機にはアカウントの操作ができる情報を持たせずに、それでも参加しているアカウントのもとで計算を走らせることが可能になるようにしよう (John Keck)。それを実現するには、参加者テープルにフラグを新設し、アカウント・キーを使ってのログインは不可、という意味を持たせればできます。

BOINCの訳のメインページに戻る | (原文のメインページに戻る)

最終更新時刻 00:36:15, 2006年08月12日(JST)
Copyright © 2012 University of California. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
Copyright © 2012 Komori Hitoshi(je2bwm at jarl.com). Japanese translation from English web pages on BOINC. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.