私はそれを理解しましたが、その解決策はちょっとしたことです。
基本的には、必要に応じて、常に別の認証セッションを作成する準備が必要です。 1つの認証セッションを作成して有効かどうかを確認し、そうでない場合は、実際に使用する2つ目の認証セッションを作成します。
boxClient.Auth.SessionAuthenticated += Auth_SessionAuthenticated;
boxClient.Auth.SessionInvalidated += Auth_SessionInvalidated;
は私にとって、これは愚かなようだ - 私は一回/日私のアプリを実行しているので、私はちょうど私のトークンたびにリフレッシュしたい:あなたは、2つのイベントがトラップして、このためにテストします。ですから、私はいつも2つを作成します:
var config = new BoxConfig(CLIENT_ID, CLIENT_SECRET, new Uri(RedirectURI));
// Prior to this code snippet, I grabbed my starter access & refresh tokens from where I stored them in our db.
var auth = new OAuthSession(InitialToken, RefreshToken, 3600, "bearer");
var client = new BoxClient(config, auth);
/// Try to refresh the access token
var realAuth = await client.Auth.RefreshAccessTokenAsync(auth.AccessToken);
/// Create the client again
var realClient = new BoxClient(config, realAuth);
//going to just log/update tokens every time. This only runs 1x/day, so should be no harm.
LogNewTokens(realAuth.AccessToken, realAuth.RefreshToken);
そして、私は残りのBoxリクエストに対して "realClient"を使用します。
振り返ってみると、これらのリクエストをBoxに直接ポストし、返されたJSONを解析するためのコードを持ち上げるほうが速いのかもしれません。私は自分のトークンを自動的に更新して接続し、新しいものを簡単に利用できるようにする素敵なラッパーオブジェクトを持つことを期待していました。私は彼らがC#SDKでより良い仕事をすることができたと思います。
APIの拡張メソッドやアドオンがない場合、これはあなた自身のロジックやクラスをコード化して、このようなものを処理するように見えるでしょう。私の意見では... – MethodMan
私は、APIの一部が欠けているかどうか尋ねました。リッスンする必要があるイベント、変更されたリターンプロパティなどです。明らかに、ユーザー名とパスワードを保存してボックスに渡すことはできません監視されていないアプリケーションのログインWebページ。 – Quicksilver
アプリがコンソールアプリの場合は、App.Configファイルにユーザー名とパスワードを保存して、そのセクションを暗号化してもらえますか? – MethodMan