ユーザーが別のWebサイトにログインしている場合は、現在のWebサイトに自動的にログインします

私は約100のWebサイトをASP classicでコーディングしています。各ウェブサイトは注文を受け取り、それらをデータベースに格納する。しかし、これらの注文の支払いは、別のウェブサイト上で行われなければならず、ASPクラシックでもコードされています。すべてのWebサイトは同じ会社が所有し、同じIISサーバー上でホストされ、同じSQL Serverデータベースを使用します。ユーザーが別のWebサイトにログインしている場合は、現在のWebサイトに自動的にログインします

ここで、ユーザーはいくつかの個人情報を入力して登録し、これらのウェブサイトの1つ（例えばwebsite-for-newjersey.com）にログインして注文する。その後、支払いフォームに個人情報（住所、都市、配送の状態、クレジットカード名義人の名前など）の一部が表示される支払いウェブサイト（httpsのpayments.master-website.com）にリダイレクトされます。クレジットカード固有の情報がそのページに入力されます。

が事前に入力された支払いフォームを表示するには、そのページに表示される情報の機密性のため、ユーザーは支払いウェブサイトにログインする必要があります。ユーザーに2回ログインさせたくない（各ウェブサイトに1回）。ユーザーがにログインしているかどうかを確認する信頼できる方法は、従来のASPを使用してウェブサイトを参照してください。

かいつまん BIをチェックする必要がウェブサイト上で

訪問者がウェブサイトにログインしている場合、BIは、ウェブサイトからIDのセッション変数を必要とするウェブサイトで
両方ウェブサイトは同じデータベースサーバーを使用しています
明確な説明が必要です
PHP/ASP.NETソリューションは汎用/携帯であれば受け入れ可能です

出典

2011-12-23 Salman A

ロバーツの提案にどうぞ。それは優れたアプローチであり、異なるドメイン間でセッションを共有することはできません。そうしなければ、誰かのFacebookのセッションや何かを盗むことができます。あなたが支払いしようとしているときはいつでも、ロバートは言ったようにしてください。そのユーザーに関連するデータベースにランダムな文字列を格納します。それを暗号化し、SSLを使って新しいWebサイトに行き、解読してデータベース内のユーザーを確認します。また、時間とともに確認する（作成後1-2分以内など） – Muqito

セッションブリッジと呼ばれることについて聞いたことがありますか？ – TechGirl

@TechGirl：いいえ私はしていない。 –

guidや他のランダムに生成された値を作成することができます。ユーザーレコード（指定された期間内に期限切れに設定）をデータベースに格納し、暗号化してSSL経由で支払いサイトに渡し、暗号化された後、データベースと比較します。一致する場合はログインし、一致しない場合はログインするように求められます。

別の方法として、別のドメイン名で実行できるかどうかはセッションを使用しています。彼らはすべて同じマシン上にあるので可能かもしれませんが、私は100％確実ではありません。

出典

2011-12-23 14:52:30 Robert

サブドメインであっても、異なるドメイン名を使用すると、セッションの有効期限が切れます。 – TheCarver

これは動作します。しかし、誰かがウェブサイトAから正当な（暗号化された）トークンをコピーし、別のブラウザ/コンピュータでウェブサイトBを開き、（暗号化された）トークンを投稿すればどうなるでしょうか？ –

暗号化された値の一部のコンピュータ/ブラウザ情報を使用して、復号化するときにその人物が同じマシンに存在することを確認することができます。 SSLで公開するには別の暗号化レイヤーが必要です。 – Robert

あなたが聞いたことは、シングルサインオン（SSO）と呼ばれ、いくつかの方法で実装できます。この問題については、例：What's your favorite cross domain cookie sharing approach?のように多くのトピックがありますが、それらはすべて個々の要件によって異なります。

異なるドメインを持っているため（Cookieを共有できないため）、httpとhttps（問題の可能性があります）を混在させ、多くのアプリケーションを使用して多くの変更を加えることはありません。

だから私はロバートの提案を検討することをお勧めします：ユーザーが初めて（サイトA）を使用すると、データベース内のGUIDを保存するために認証され

。 GUID、userid、ip、timestampの列を持つセッション用の新しいテーブルを追加するか、それを注文データの一部として保存します。セッションオブジェクトにGUIDを格納します。
支払いサイトへのリンクを持つページでは、クエリ文字列または隠し変数（フォームの場合）として設定します。
他のドメイン（WebサイトB）でGUIDを確認し、データベースで検索します。あまり古すぎない場合は、ユーザーを認証し、そうでなければログインページにリダイレクトします。

支払いサイトへのリンクを変更できない場合は、手順2をスキップして自分のIPでユーザーを検証しようとする可能性がありますが、これは危険すぎる可能性があります。

出典

2014-06-09 19:51:51 Alex

これは簡単です。しかし、誰かがウェブサイトAから正当なトークンをコピーし、別のブラウザ/コンピュータでウェブサイトBを開き、トークンを投稿すればどうなるでしょうか？ –

（IP +チェックリファラー+ POSTの使用を検証する）の組み合わせで実行する必要があります。ユーザーが検証されたときにデータベースからGUIDを削除して、同じGUID（URL）を再度使用できないようにすることもできます。 – Alex

@SalmanA：GUIDを保存しません。むしろリダイレクト時にソースサイトが毎回生成したランダムなUUID *を*保存して更新します。次に、UUIDをターゲットサイトで受け取ったDBからパージします。これはあなたの悪意のあるユーザーが自分のリダイレクトをブロックしなければならないことを意味します（そうでなければUUIDは無効になります）**と**は5秒以内に別のコンピュータからGUIDをコピーして投稿する必要があります。通常の302リダイレクトはこの時間がかかりませんので、数秒より古いすべてのUUIDは安全であるとみなされます。 – LSerni

Pass-port based authenticationは、マイクロソフトが提供する集中認証サービスであり、メンバーサイトに対して単一のログオンおよびコアプロファイルサービスを提供します。詳細については、次のマイクロソフトWebサイトを参照してください。

Passport Authentication Provider

出典

2014-06-13 08:04:24

Passport認証は廃止され、Live IDによって置き換えられました。ここで尋ねられたものとは異なるLive IDアカウントが必要です。 – Alex

あなたは、インフラストラクチャレベルでのシングルサインオンを実装することができない場合は、別の信頼パーティのアプリケーションが認証を共有することができますIdentity Federationを使用する必要があります請求を通して。

これはSecurity Assertion Markup Language（SAML）を使用して行うことができ、直接などの製品/標準に：あなたはOAuthまたはOpenIDを見てみることができます

SSOまたはIDフェデレーションよりも多くの共有認証スキーム

出典

2014-06-13 16:18:01 JoeBilly

ユーザーが別のWebサイトにログインしている場合は、現在のWebサイトに自動的にログインします

答えて

関連する問題