Engine続行するにはJavascriptを有効化してください。Realtimeインディーかプロのディベロッパーかを問わず、誰でもリアルタイムマルチプレイヤーゲームを開発してグローバルに配信可能です。PUNインディーかプロのディベロッパーかを問わず、誰でもリアルタイムマルチプレイヤーゲームを開発してグローバルに配信可能です。Quantumマルチプレイヤーゲーム開発の革新に参加しよう!MOBA、ブローラー、RTS、戦闘ゲーム、スポーツゲームを迅速な予測ネットワーキングエンジンで開発できます。Chat同時接続数をスケールできるクロスプラットフォームのチャットシステムをあなたのアプリに簡単に統合できます。Voice大規模かつインターナショナルな最先端のライブボイスチャット。すべてのマルチプレイヤーエンジンと併用可能。v3カスタム認証デフォルトではアプリケーションには認証メカニズムがなく、匿名ユーザーの接続が許可されます。Photonアプリケーションにはカスタム認証を実装するオプションがあります。Photonでのカスタム認証は非常に柔軟性が高く、サードパーティーの認証プロバイダや完全にカスタマイズされたソリューションに対応しています。弊社はGitレポジトリで認証プロバイダの実装例を提供しています。レポジトリをフォークし、プルリクエストを送信してください。GitHubでソースを確認してください。以下に、認証プロセスの一般的なフローを記載します。Serverに渡します。Serverは、必要な認証プロバイダをアプリケーションに取得し、以下の手順のいずれかへと進みます。認証は手順3に進みます。Connect()で渡された認証情報で、認証プロバイダを呼び出します。認証は手順4に進みます。該当するプロバイダの設定に応じて、クライアントは接続を許可されるか、または拒否されます。Serverに結果を返します。認証の結果に応じて、クライアントは正常に認証されるか、または拒否されます。Serverにセットアップカスタム認証はアプリケーション設定ファイルに設定可能です。LoadBalancingアプリケーションでは、こちらのファイルにおこなう必要があります。匿名クライアントの認証なしでの接続を許可するか否かを示すフラグ。設定された認証プロバイダの名前。認証プロバイダの種類。認証プロバイダのエンドポイント。認証サービスが作動していない場合にクライアントを拒否するか否かを示すフラグ。AuthProviderノードには2つのXML属性を追加することも可能です。これらのキー/値はクエリ文字列パラメータとして送信されます。CloudにFacebook認証を使用している場合には、この部分を飛ばしてください。APIでカスタム認証を処理します。関連するパラメータと対象のカスタム認証サービスの設定は、1回のみ必要です。セットアップが完了すると、接続してその後のエラーが処理されます。例:単純化するため、このスニペットでは非常に基本的なパスワードベースの認証証明書を選択しました。結果的に、クエリ文字列は以下のとおりとなります:?user={user}&pass={pass}。一般的に、これらの証明書は値のセットです。最初の値は固有の識別子(ユーザーID、ユーザー名、Eメールなど)で、もう1つの値は「信頼性の証明」(ハッシュされたパスワード、キー、秘密、トークンなど)です。セキュリティ上の理由から、プレーンテキストのパスワードは送信しないでください。Top認証オペレーション認証オペレーションによって、認証値が実際にサーバーに送信されます。これは通常、クライアントコードで直接使用されるのではなく、APIによって使用されます。留意すべき点は:サーバーへの接続には、常に認証ステップが含まれる点です。オペレーションは暗号化されたオペレーションとして実際の認証値を送信します。後に発生するサーバー切替では、Photonは暗号化され、かつ自動的に使用される独自のトークンを提供します。Topサーバー側Webサーバーが認証リクエストを受信した場合、クエリパラメータを確認し有効化する必要があります。現在の証明書とデータベース内に保存された既存の証明書を比較できます。Top高度な機能ユーザー認証以外にも、認証プロバイダーから補足情報を返すことができます。この設定をおこなうには、ユーザーは「認証者」の役割を担うWebサービスとクライアント間にプロトコルのようなものを設定する必要があります。クライアントに変数の静的な数を返すかどうか、選択してください。一部のユースケースでは、クライアントのリクエストへの「オンデマンド」ベースでWebサービスがデータを返す、さらに複雑なアプローチが必要になります。このサブセクションでは、クライアントからWebサービスにデータを送信する方法を説明します。このデータは、認証に必要な証明書や補足のパラメータです。補足のパラメータは、認証レスポンスで返されるサーバー側から利用可能になるデータをリクエストするのに使用されます。これは非常に有用で、余分なAPIコールが不要となりログインワークフローが単純化されます。認証に使用されるデフォルトのHTTPメソッドはGETです。このため、パラメータはクエリ文字列内でキー/値のセットとして送信することができます。最終的なURLには、クライアントやサーバー設定で設定されたキー/値のセットの「共用体」が含まれます。同じキーが両方の場所で使用されいてる場合、サーバーで設定された値のみが送信されます。ベストプラクティスは、クライアントに「不可視」で「機密」かつ静的なキー/値のセットをサーバー上で設定することです(たとえばAPIキー、APIバージョンなど)。サーバーのキー/値はクライアントをアップデートせずに即時に変更することが可能です。まれに、認証が多くのデータを必要とする場合があります。ほとんどのWebサーバーにはクエリ文字列で使用される文字数の上限や、URLの長さの閾値があります。AuthenticationValues.AuthPostDataフィールドに値を設定してHTTPメソッドをPOSTに変更できるようにしました。後者には、string型またはbyte[]型を設定することが可能です。クラスは、型ごとにそれぞれ2つのセッターを提供します。これが要件や制約となる場合があるため、WebサービスからPOSTメソッドとして認証要求を受信したいユーザー向けにPOSTメソッドオプションも提供されています。認証パラメータを送信する際にはクエリ文字またはPOSTデータ、もしくはその両方を自由に使用できます。下表に、設定可能な組み合わせを示します。Serverが処理できる変数に留意してください。Serverが受信するすべてのHTTP受信レスポンスと同様に、WebサーバはResultCodeと任意のMessageを含むJSONオブジェクトを返す必要があります。これは、認証自体のパラメータとして使用することができますが、クライアント側から要求することも可能です。Serverが受信すると必ずクライアントに転送されます。ランダムに生成されたUserIdがクライアントに返送されます。これによってクライアントのUserIdの値が上書きされ、その後変更できなくなります。これは、認証自体のパラメータとして使用することができますが、クライアント側から要求することも可能です。これがWebサービスから返されると、クライアント内のNicknameの値が上書きされます。Nicknameは、その後もクライアント側からアップデート可能です。セキュアデータとも呼ばれます。Webサービスによって返されるJSONオブジェクトですが、受信した暗号化トークンに埋め込まれるので、クライアント側からアクセスすることはできません。HTTPリクエストとともに、後で送信することが可能です。クライアントに返すべきその他の値が含まれているJSONオブジェクト。ネストされた配列やオブジェクトはサポートされません。ResultCodeは唯一必須となっている戻り変数で、他の変数は任意です。以下の表に、Webサーバーが返すことが可能なものを示します。