login履歴とセッション調査

KUNAI 3.1.5までのAPI呼出し方法をひとまず説明します。
その上で発生現象を理解しやすいだと思います。
・Step③画面のログイン処理
　WSDL→BaseGetUsersByLoginName
・シンク処理は共通なので、初回かどうかとは関わらず
　WSDL→UtilLogin(dailyに)→BaseGetApplicationInformation(常に)→ ...（各アプリシンクAPI）

WSDLへのアクセスはGETプロトコルで、ユーザー名とパスワードが特にいらないで、
Slash側のセッションとログインにとっては特に影響ないとのことで、
API呼出し方法を簡単に以下のように認識しても大丈夫です。
・Step③画面のログイン処理
　BaseGetUsersByLoginName
・シンク処理は共通なので、初回かどうかとは関わらず
　UtilLogin(dailyに)→BaseGetApplicationInformation(常に)→ ...（各アプリシンクAPI）

■KUNAI for iPhone 3.1.5

㈰office もしくは Garoon を設定した KUNAI で、接続情報の再設定(設定内容変更なし)を行うと、シンクする度にログイン履歴が増えていく
1. office または Garoon にログインし、初回シンクを実施した状態にする
→ slash で有効なセッションとログイン履歴を確認する
2. 手動でシンクを実施する
→ slash で有効なセッションとログイン履歴を確認する
3. アプリ一覧 > 個人設定 > 接続設定の変更 > を開く
4. 接続設定を行う（設定内容は変更しない、すでに設定してある内容で「次へ」をクリックしていく）
5.「閉じる」をクリックして完了する
6. 手動でシンクを実施する
→ slash で有効なセッションとログイン履歴を確認する
7. 自動シンクを設定し、シンクされるのを待つ
→ slash で有効なセッションとログイン履歴を確認する

手順1. office の場合は有効なセッションが1件、ログイン履歴が2件増える（office API の挙動で、正常）
　　　 garoon の場合は有効なセッションが1件、ログイン履歴が1件増える（正常？）

Step③で BaseGetUsersByLoginName をコールした後、もらった認証セッションCookieをローカルに保存して、
　その後Step④で初回シンクを行う時に、ひとまずUtilLoginを叩くという処理プロセスです。
　初回シンクのUtilLoginを叩く前に、認証セッションのキーは知らずに、BaseGetUsersByLoginNameでもらった認証セッションCookieは普通なCookieとしてUtilLoginのリクエストに設定する現状です。
　Garoonの方は、UtilLogin以外の普通なAPIを叩くと、生成しれくれる認証セッションCookieは有効なものであり、UtilLoginのリクエストに設定したら、ログインは発生しない、セッションは１回発生する。
　Officeの方は、UtilLogin以外の普通なAPIを叩くと、生成しれくれる認証セッションCookieは無効なものであり、UtilLoginのリクエストに設定しても効かないで、ログインとセッション両方とも１回発生する。
　GaroonでもOfficeでも、Step③で BaseGetUsersByLoginName をコールする場合は、リクエストに認証セッションCookieを強制的に設定しない現状（仕様）であり、ログインは１回発生する。
　纏めて、上記の現象と合ってます。

手順2. 有効なセッション、ログイン履歴ともに増えない（正常）
手順6. 有効なセッションは増えないが、ログイン履歴が1件増える（不具合？）

ログイン履歴が1件増える現象は不具合ではないはずです。「BaseGetUsersByLoginName」APIの役目はパスワードの検証です。（仕様に記載あり）

手順7. 有効なセッションは増えないが、ログイン履歴が大量に(10件以上)増える（不具合？）

手順6.まで、接続設定の変更の経由で再度Step③で BaseGetUsersByLoginName をコールした後、もらった新しい認証セッションCookieをローカルに上書き保存する。
　元のUtilLoginからもらった認証セッションCookieはなくなった状態となる。UtilLogin以外の普通なAPIからもらった新しい認証セッションCookieのライフサイクル（有効期限）に関しては、
　こちらは把握できていないが、現象を見ると、手順6.までは期限切れが発生してなかったが、30分後、期限切れが発生したので、シンクの各APIはクッキー認証モードから、
　パスワード認証モードへ切替（GW側の挙動）、ログインがAPIごとで大量に発生する。

㈪office もしくは Garoon を設定した KUNAI で、カスタムアプリもしくは掲示板にアクセスすると有効なセッションとログイン履歴が1件ずつ登録される
1. office または Garoon にログインし、初回シンクを実施した状態にする
2. カスタムアプリ、もしくは掲示板を KUNAI で開く
→ slash で有効なセッションとログイン履歴を確認する

手順2. 有効なセッションとログイン履歴が1件ずつ増える
KUNAI for Android の場合は発生しません

KUNAI for iPhone の現状は、カスタムアプリもしくは掲示板などのモバイルアプリへアクセスする前に、UtilLoginを１回コールした後、24時間内コールしないような仕組みです。
　有効なセッションとログイン履歴が1件ずつ増える現象とは合ってます。

㈫Garoon を設定した KUNAI で、セッションを削除したあとに手動 or 自動シンクを行うと、有効なセッションとログイン履歴が1件ずつ登録される
1. Garoon にログインし、初回シンクを実施した状態にする
2. slash で有効なセッションに登録されている2件のセッションを削除する
3. 手動シンク、もしくは自動シンクを設定してシンクを行う
→ slash で有効なセッションとログイン履歴を確認する

手順5. 有効なセッション、ログイン履歴ともに1件ずつ増えている
セッション削除後のシンクでは1件ずつ増えるのは正常でしょうか。

有効なセッションとログイン履歴が1件ずつ登録される原因は、daily sync のUtilLoginをコールしたのです。
　これは特に問題ないと思いますが。

★現状の現象だと、.com接続ならば、Step③で BaseGetUsersByLoginName をコールする時に、以下の改善をした方がよいだと思います。
・Step③でBaseGetUsersByLoginNameのリクエストに認証セッションCookieを必ずに設定しないように変更する
・Step③でBaseGetUsersByLoginNameからもらった新しい認証セッションCookieをローカルに上書きしないように変更する
・カスタムアプリもしくは掲示板などのモバイルアプリへアクセスする前に、UtilLoginを24時間ごと叩く処理の実行タイミングは独自管理ではなく、dailyシンクのUtilLoginと合わせるように変更する。

kunai