Cookie（セッション情報）の取り扱い
momentspace momentspace momentspace そもそもCookieの入ったインスタンスはアプリケーションが保持するんだから、ライブラリへのアクセスを自分でラッピングしてやればいいだけな気がしてきた。
public class Application {
private NicoAPI api = new NicoAPI();
public NicoAPI GetAPI() {
return api; // これはやっちゃダメ
}
}
サービス別の情報取得クラスからは見えないようにして、Cookieを取り出せるクラスだけプラグインに公開を外せば解決するような設計がいいかな
public class Application {
private NicoHogeInfo info;
private NicoSession session;
public NicoHogeInfo GetNicoHogeInfo() {
session = info.Login("id", "pass"); // Sessionはアプリだけ取れる
info.deleteInfo(session); // コミュ削除とか権限が必要な操作はセッション情報を再度渡す。
return info; // 情報はプラグインも触れる
}
}
// 以下NicoLibの設計サンプル
public class NicoSession {
public Cookies GetCookies();
}
public class Nico {
NicoSession Login(string id, string pass) {
return new NicoSession("セッション設定して返す");
}
}
public class NicoHogeInfo {
//GetCookies(); //情報クラスには取得する仕組みを持たない
}
momentspaceさん
早速ご検討いただきありがとうございます。
Cookieの入ったインスタンスはアプリケーションが保持という設計なら問題ないです。 このことがすでに決まっていることだったなら、そのことを考慮せずに話を進めてしまい申し訳ありませんでした。
ただCookieの入ったインスタンスを作ってしまうと、 APIにアクセスできるのはこのインスタンスだけということになってしまい、 ライブラリの実装や利用するときに若干面倒になるんじゃないかという懸念があります。
そこで静的な領域にセッションをおいてライブラリ内からならどこからでも利用出来るようにしようという発想になったのですが、 その”ライブラリ内からなら”が実現できなさそうだったので、IRCであのような話をしていまいした。
momentspace Cookieに関しての振る舞いが上記のサンプルである必要はありません。上記のような方法で回避できそうな話に聞こえたので一例をあげたまでです。 SessionはAPIが内部的にもって、外向きに返すI/Fを用意しないようにしておけば、ログインを呼び出したらアプリケーションだけがSessionを受け取る 事が出来て、認証が必要そうな操作の呼び出しだけ渡す必要があるようにしておき、それ以外の操作は内部に保持してるCookieを使用するような方向で 解決出来そうでないかなと思っていますが、如何でしょうか。
Cookieをライブラリから自由に取れる仕組みにすると、作っているアプリがプラグインを用意した際にセキュリティホールになりかねないのではないかという問題。 ライブラリの概念としてはセキュリティ的にそのまま返す仕組みで実装することの危険性を記載したい。 実装としては各言語に任せるか、設計断面で推奨される実装を明示するようにしたい。
ex.) 下記のようなメソッドで返すようにすると、DLLの呼び出しを共有するアプリケーション全てから容易に承認情報が取得出来てしまうため問題がある。
下記のように取得にワンクッション置くような仕組みを用意するべきではないか