1

こんにちは、私は Google Apps ベースのソリューションを構築しています。基本的に私はそれを次のように設定しています：

  1. Google Apps アカウント所有者がそれをインストールするとき、使用する単一の Google Apps アカウントの認証の詳細を入力します。そのアカウントは、インストールされたシステムのインスタンスのすべてのユーザーが、そのアカウントに関連付けられた Google ドキュメントにアップロードするために使用されます。その Google Apps アカウントに関連付けられた Google カレンダーのエントリを管理します。

  2. 上記のユーザーは、他のユーザーを作成し、別のログイン画面からサインインするように招待できます。また、システムのインストールに使用された Google Apps アカウントに関連付けられたサービスとの対話を可能にするシステムの機能と対話できる必要があります。

  3. 元のユーザーと同じドメインの他のユーザーもシステムをインストールでき、同じドメインのユーザーによって作成されたインスタンスに自動的に関連付けられます。

パート 1 とパート 3 はすべてセットアップしましたが、パート 2 で行き詰まりました。一元化された Google Apps アカウントの資格情報をデータベースに保存していて、詳細を使用してシームレスに認証する方法が必要です。ユーザーがサインインの詳細を追加したり、アプリケーションが Google Apps サービスにアクセスできるようにするために許可を求められるプロセスを経たりする必要がないようにしたい - ユーザーがログインすると、自動的に透過的にまた、Google Apps アカウントにもサインインし、そのサービスを使用できるようにします。

「サインインするアカウントまたは Google Apps ログイン画面をユーザーに尋ねる」プロセスと、アプリケーションがアカウントにアクセスできるようにするための許可を求める 2 番目のステップを廃止したいのですが。

私はそれができることを知っています-私はたくさんのアプリケーションをインストールしましたが、それらのどれも、私がまったく不必要だと思うこの2つの認証プロセスを通過する必要はありません-どうすればよいですか? - 助けてください！

4

2 に答える 2

0

Zend Frameworksを見たことがありますZend_Gdataか？これは、GoogleデータにアクセスするためのPHP 5インターフェースであり、一見すると、必要なすべてのことを実行しているように見えます。

http://framework.zend.com/manual/en/zend.gdata.introduction.html

于 2010-05-06T13:38:12.157 に答える
0

Web セッションの認証を処理するには、認証プロセスを引き継ぐ必要があります。良いニュースは、実際にそれを行うことができるということです (SSO / SAML)。悪いニュースは、それが大変な作業になる可能性があるということです.

基本的には、独自の SSO プロバイダーを構築し、それをドメインの前に配置して (すべての認証を処理するように)、必要なだけシームレスにログイン プロセスを処理できるようにします。

より高いレベルでは、1 つのアカウントを使用してマルチユーザー アクセスを Google Apps にプロキシしているように思えます。眉をひそめていると確信しているので、TOSを確認することをお勧めします（トレーサビリティを殺します）。

于 2011-07-05T09:20:27.883 に答える