カスタマ・ポータルのオープン・ログインとは、どのようなものですか。

環境:  

カスタマーポータルのオープンログイン, February 2011 and newer  

解決策:

February 2011以降のリリースでは、FacebookやTwitterなど別のIDプロバイダからすでに所有しているアカウントを使用して、エンドユーザー・ページにログインできます。

これは事実上、Facebook、TwitterまたはGmailのアカウント、あるいは(サービスのサポートを受けた場合に)OpenIDまたはOpenAuth 2.0をサポートするIDプロバイダで可能なログインを使用して、CPページで認証できることを意味します。

February 2011リリースにアップグレードしても、自動的にはこの機能は取得できません。アップグレードしたら、新しい機能を含む標準ページをコピーして、これらのページをCPデプロイメントに取り入れる必要があります。

IDプロバイダの選択 – Facebookの例:

1. 「Facebook」ボタンをクリックしてFacebook認証ページ(および操作に関する簡単な説明)を開きます。
2. "Login with Facebook" ボタンをクリックして、Facebookログイン・ページにアクセスします(通常の場合)。
3. すでにFacebookにログインしているがプロファイルでEメールアドレスを公開していない場合、権限要求ページが表示され、ユーザーは「許可」をクリックする必要があります。
   次の2つの場合を除き、すべての場合でこの使用をお薦めします。
   
   ケース1:すでに連絡先レコードを含めた多数のユーザーのユーザー・ベースをカスタマが所有している場合。
   
   ユーザーがすでに連絡先レコードを伝えており、ユーザーにFacebookなどでログインするオプションを付与している場合、ユーザーは(潜在的に)2番目のアカウントを作成できるようになっています。これは、ユーザー側で別のEメール・アドレスを指定して行います。これにより、個々のカスタマのビューが複数の連絡先レコードに断片化されます。この問題をカスタマと検討することをお薦めします。「質問をする」ページへのアクセスをカスタマに許可する前にログインを要求するインストール・ベースのカスタマは、この機能を利用者に提供する前にページ・フローを変更するようにお薦めします。
   
   ケース2:ハウスホールディング(Eメール・アドレス共有)を使用するカスタマの場合
   
   - 信頼された実証済みのすべての連携ログイン・プロバイダは「1つのEメール=1人のユーザー」という想定に基づいているため、この想定をこちら側でも受け入れる必要があります。
   - Eメール共有が有効な場合、連絡先の作成と更新は同じです。
   - プロバイダから付与されたEメール・アドレスのある連絡先が存在しない場合、1つの連絡先が作成されます。
   - Eメール・アドレスのある連絡先が存在する場合、データベース内でそのEメール・アドレスに最初に一致する連絡先が使用されます。
   - 追加または更新されるチャネル・タイプまたはopenid_accounts行はすべて、その最初の連絡先に関連付けられます。プロダクト(contact_match)全体で使用されるものと同じAPIがここで使用されます。したがって、ユーザーのEメールと氏名(氏名がプロバイダから提供されている場合)を使用してcontact_match()を呼び出して返される連絡先はすべて、使用されている連絡先です。
   
   この結果、意図したユース・ケース(たとえば、最後の連絡先を「ライブ」カスタマ・レコードにしてアカウントを「バージョン」する場合)以外にEメール共有を使用する場合は、この機能の使用はお薦めしません。