Drupalで人間の顔をしたOpenID

Drupalのバージョン6以降、OpenIDモジュールにはシステムが付属しており、OpenIDプロトコルを介して認証を提供します。 しかし、モジュールには非常に深刻な問題があります。 特に、モジュール自体はIvan Sagalaevのブログで説明されているアンチパターンを実装しています。 モジュールの2番目の問題は、使いやすさの観点から、OpenIDによる非透過的な認証です。さらに正確に言うと、OpenIDアカウントを介して初めて認証しようとすると、システムはいくつかのフィールドに入力するように要求します。



一般に、少数のフィールドに入力することについて本当にひどいことはありません（特に、場合によっては一部のフィールドが自動的に入力されますが、それについては以下で詳しく説明します）。この理由はDrupalアーキテクチャです。 OpenIDアカウントは、実際のDrupalアカウントに関連付けられています。 OpenIDプロバイダーでの認証が成功すると、DrupalはOpenIDアカウントとDrupalアカウントの対応を見つけようとします。 そのような一致が見つからない場合-システムは新しいアカウントを登録することを提案しますが、そのためにはいくつかの必須フィールドに入力する必要があります-一般に、これはシステムとメールアドレスの一意のユーザー名です。 一致が見つかった場合、ユーザーはログインします。 プロファイルでは、ユーザーは自分のDrupalアカウントに関連付けられるOpenIDアカウントをいくつでも追加できます。







DrupalのOpenIDの原理により、すべてが多かれ少なかれ明確になります。 しかし、ユーザビリティに関する質問は消えていません-承認ブロックの下部にあるリンクは、非常に便利なソリューションとは言えません。 上記で書いたIvanのブログの投稿で、この問題を解決するための可能なプロトタイプの1つが提示されました。これはDrupalで取り上げました。



どのように、何が書かれたか-この場合、それは本当に重要ではないと思います-最終的に、すべてがソースコードの形で配布されます。 ポイントに直接行きましょう-何が起こった=）



そして、特定のAPIのセットを使用して、特定のOpenIDプロバイダーのフレンドリな（可能な限り）サポートを接続できるシステムが判明しました。さらに、プラグインブロックデザインテーマの形式で追加機能を追加しました。



すべてについてもう少し詳しく、写真で=）



Drupalでのモジュールのインストール方法について説明する必要はないと思いますが、必要に応じて、このシステムの操作の基本について説明した前回の記事を読むことをお勧めします。 したがって、 OpenID Extenisionsモジュールをダウンロードしてインストールするだけです（OpenIDモジュールに依存することに注意してください）。 これでセットアップできます。



[ユーザー管理] -> [ OpenID拡張機能 ]に移動し、OpenIDプロバイダーの設定に入ります。







設定（ Blocks =モジュールからコピーした機能）で、利用可能なプロバイダーを接続/切断したり、シーケンスを設定したりできます。 後者は、リソースのほとんどのOpenID認証が、たとえばLiveJournalからのものであることを知っている場合に便利です-LJを最初に配置すると、ブロックが表示されるページを読み込むときにデフォルトで選択されます。 また、そこにある[ テーマ ]タブには、使用可能なトピックのリストが表示されます。 テーマは、OpenID認証フォームの外観を決定します。 基本的な配信（およびこのブログ投稿を書いている時点での他の配信は存在しません=）には、2つのトピックがあります。

• ドロップダウン デモ
  
  
  
  
• アコーディオン デモ
  
  
  
  
  
  

お気に入りのデザインテーマを選択し、OpenIDプロバイダーを構成したら、ブロック設定（ サイトビルディング -> ブロック ）に移動し、 OpenID Extensionsというブロックを目的の領域に追加し、その位置を設定し、必要に応じてページにブロックを表示するためのフィルターを構成できます。 ロールごとに可視性フィルターを設定しても意味がありません。いずれの場合も、ブロックは権限のないユーザーにのみ表示されます。



OpenIDプロバイダーでの認証に成功した後、上記で書いたように、初めてログインしようとすると、Drupalはユーザーを登録ページにリダイレクトし、そこでフォームフィールドにプロバイダーから受け取った値を入力しようとします。 OpenIDプロバイダーがSRE（Simple Registration Extension）を実装し、プロファイルに必要なフィールドが入力されている場合、登録フォームのこれらのフィールドは自動的に入力されます。 たとえば、Yandexアカウントでは、必要なすべての情報が入力されています-ログインしようとすると、Yandexはexample.comリソースの承認を許可するかどうか、およびこのリソースへの2つのフィールド（エイリアスとメール）の転送を許可するかどうかを尋ねました。 登録手順が自動モードで正常に完了した場合（つまり、必要なすべてのデータが受信され、検証に合格した場合）、ユーザーのDrupalアカウントが作成され、OpenID識別子が自動的に関連付けられ、ユーザーがシステムに自動的にログインします。



必要なデータが入力されていない場合、またはプロバイダーがそのようなデータを提供していない場合（たとえば、SREを実装せず、DruapalのOpenIDモジュールでサポートされていないAXのみ）、Googleはエラーを生成し、不足しているフィールドを手動で入力するよう求めます。 また、OpenIDプロバイダーがエイリアスを提供しない場合、「ユーザー名」フィールドにはOpenID識別子の値が入力されます。 この問題を解決するために、モジュールは小さな回避策を提供しますが、それは特定のプロバイダーでのみ動作します-LiveJournalおよびYandexを使用した基本配布でのみ。 一般に、 OpenIDモジュールにパッチを適用することで、Googleからメールアドレスを取得することができたため、将来的にはモジュールの機能を少し拡張し、一部のプロバイダーでは標準のハンドラーを置き換える必要のある独自のハンドラーを作成します。 また、最近機能凍結モードに入ったDrupal 7の一部であるOpenIDモジュールに手を加える計画もありました。 それまでの間、それは動作する方法で動作します。



また、 OpenID拡張モジュールは、 OpenIDモジュールの背後にあるいくつかのポイントを「クリーンアップ」します。つまり、これらのフォームをOpenID認証モードに切り替えるログインブロック（ブロック内および別のページ）からリンクを削除します-プロバイダーは標準モジュールの動作を繰り返しますモジュールのインストール時にデフォルトで有効になっている任意のOpenID 。



それだけです。DrupalでのOpenID認証の使いやすさの改善についてお話しすることはすべてです。 これまでのモジュールは、 プロジェクトセクションの私のWebサイトでのみダウンロードできます 。 モジュールが少しクリーンアップされた後、 drupal.orgで対価が支払われます（ロシア語でこの言葉に似ているとは思えません）。



そして最後に、ちょっとした陰謀-このモジュールはもともとプロジェクトのために開発されたもので、近い将来に光を見るはずです。 プロジェクトの発表は公開されます=）



これですべてが確実になりました=）コメント/バグレポート/提案/コメントのお願いを楽しみにしています。



脅威現在、いくつかのDrupalテーマでのアコーディオンの外観の表示にはいくつかの問題があります。 特に、デザインはLightWordテーマでは正しく機能しません。



UPD：このモジュールは現在drupal.orgでコードレビューフェーズを実施中です。



UPD2： Googleでログインしようとするとエラーが発生する場合、Googleはhttpsを使用するため、OpenSSLサポートを使用してPHPを構築する必要があります（ubuntでは、opensslパッケージをインストールするだけで十分です）。



UPD3：バージョン0.6.5に更新、その中：

-新しいプロバイダー「Chi.mp」を追加しました

-プロバイダーの可用性を確認する機能を追加

-googleとchi.mpのチェックを実装しました-プロバイダーの管理で通知されるopensslサポートがない場合、両方とも利用できなくなりました。