Sessions: ゴリラ/セッションv2はどのように見えますか？

私はこれらのほとんどすべてに同意します。

すごい。 また、これの一部としてgorilla / securecookieを単純化する可能性があります。内部は時間の経過とともに成長し、現在のAES-CTR + MACアプローチからHMAC-SHA-512 / 256またはChaCha20 + Poly1305（https：// godoc.org/golang.org/x/crypto/chacha20poly1305）、したがって暗号を簡素化します。

それ以外の場合、securecookieは小さなlibです。 私たちのようにエラーインターフェイスを拡張するのは間違いだったと思いますが、残念ながら。

これらのほとんどすべてに対して+1。

おそらくすでにこれを検討していると思いますが、 SCSの構築から学んだことの1つは、デフォルトのエンコーディングにJSONを使用することはパフォーマンスの観点からは賢明ですが、ユーザーにとってはより複雑になる可能性があるということです（ map[interface{}]interface{}想定）

たとえば、以前に保存されたtime.Timeオブジェクトを取得します。 gobエンコーディングを使用すると、ユーザーはinterface{}値を取得して、それをtime.Timeアサートできます。 それはかなり単純で簡単です。 基盤となるJSONエンコーディングでは、ユーザーはinterface{}値を文字列に打ち込むことを知ってから、 time.Parse(time.RFC3339, ...)を呼び出してtime.Timeオブジェクトに戻す必要があります。

同様に、整数と浮動小数点数とjson.Numberを扱うのは少し面倒です。

ヘルパーを実装することもできます（SCSで行ったように）。または、カスタムJSONアンマーシャラーで実行できる賢い方法があるかもしれません。 いずれにせよ、gobエンコーディングの場合と同じように使用を難しくしない方がよいでしょう。

さらにいくつかの提案。

絶対タイムアウトとアイドルタイムアウトの両方をサポートできれば便利です（ OWASPの推奨事項に沿って）。

Cookie以外のストアの場合、セッション固定攻撃を防ぐために、ログイン/ログアウトなどの後にセッションIDを更新するための明確で焼き付けられた方法があるのが理想的です（おそらく、新規、保存などとともにインターフェイスの一部として）。 現時点では、別の名前で新しいセッションを作成し、データをコピーするという不格好な回避策がなければ、これは（少なくとも私が見る限りでは）不可能です。

入力してくれてありがとう@ alexedwards-

• ゴブは（です！）最も互換性があったので、私はまだそれを維持し、それらの間の変更を少し簡単にするかもしれません。

絶対タイムアウトとアイドルタイムアウトの両方をサポートできれば便利です（OWASPの推奨事項に沿って）。

はい、同意しました。 いくつかのopts.MaxAgeとopts.IdleTimeoutが役に立ちます。 すべての応答に対してSet-Cookieも実行せずに、それをどのように使用するかを考える必要があります。

Cookie以外のストアの場合、セッション固定攻撃を防ぐために、ログイン/ログアウトなどの後にセッションIDを更新するための明確で焼き付けられた方法があるのが理想的です（おそらく、新規、保存などとともにインターフェイスの一部として）。

同意する-ここではRefreshメソッドが役立つか、同じ効果を達成する（新しいIDを発行する） Saveへの引数が役立ちます。

https://github.com/gorilla/securecookie/issues/43は、この作業の一部を支えるsecurecookieの「v2」を追跡します

これは素晴らしく見えます。 1つの質問：stdlib以外のインポート（cookie、boltdb）を含むインクルードストアを別々のパッケージに入れることのトレードオフを検討しましたか？

お疲れ様でした！

@ccahoonストアはそれぞれ個別のパッケージ（「サブパッケージ」）に含まれるため、BoltDBを使用しない場合はインポートされません。

Redis、MySQL、Postgresのバックエンドはすでに存在し、Redisストアは
かなり洗練されています。 すべてのサードパーティストアはREADMEでリンクされています。
16:47カイルテリーの木、2017年3月23日に[email protected]書きました：

Redisとデータベース（sql）のサポートもすばらしいでしょう。 nを実行している場合
ゴリラ/セッションを使用するアプリケーションのインスタンスは、次のことができる必要があります
ラウンドロビンのためにセッションを一元化します。

—
あなたが割り当てられたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/gorilla/sessions/issues/105#issuecomment-288893992 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AABIcDfaPALfkjOw5FzdDoM_MHs9RbCYks5rowSIgaJpZM4LwM5f
。

特にgolangコンテキストパッケージをサポートすることは大きな前進になると思います。 すべてのインターフェースが値を取得する要求をすでに受け入れているため、下位互換性もあります。

これに関するタイムラインはありますか？

@Niondirタイムラインはありません。 golang / depが1.0に達するまで待ちたいので、既存のユーザーは2.0より前に固定する明確な方法があります。 現状では、マスターから引っ張っている人はすぐに大量の破損が見られます。これは、ゴリラ/セッションが幅広い開発者（初心者のGopherから経験豊富な人）からの使用を見ているため、苦痛になります。

インメモリキャッシュを無効にする方法は素晴らしいでしょう。

ここで詳細を共有できますか？ キャッシュは1つだけ存続する必要があります
リクエスト; それ以外の場合、セッションはリクエスト間でメモリに保存されません。
5:16ロマン・メンケで月、2017年12月18日には[email protected]
書きました：

インメモリキャッシュを無効にする方法は素晴らしいでしょう。 このパッケージは
複数のインスタンスを実行するアプリケーションでは使用できません。

—
あなたが割り当てられたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/gorilla/sessions/issues/105#issuecomment-352422398 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AABIcETDijyILlKONBJDuBlr6REcQgK6ks5tBmWTgaJpZM4LwM5f
。

@elithrar残念ながら、リクエスト間で共有されるメモリ内キャッシュを利用するパッケージが多すぎます。 ソースコードを調べたところ、レジストリが単一のリクエストに分離されていることがすぐにはわかりませんでした。 これを指摘してくれてありがとう！

dep 1.0はまだブロッカーですか？ readmeのステータスによると、depは本番環境での使用に安全です： https ：
つまり、マニフェストファイルとロックファイルは安定しています。 参照： https ：

私の理解では、gorilla / sessionsがdepの使用を開始した場合、ダウンストリームパッケージは影響を受けないはずです。 参照： https ：

マスターブランチを使用しているダウンストリームパッケージは、下位互換性のない変更にサインアップしていることに注意する必要があります。 もう1つのオプションは、下位互換性を維持することが最も重要な場合は、新しいリポジトリ/パッケージを作成することです。

マスターブランチを使用しているダウンストリームパッケージは、注意する必要があります
彼らがサインアップしたこと

それは現状ではなく、ツールチェーンにオプションがないことです
通常のユーザーにとっての問題点です。

使用する前に、Goツールチェーンに含まれていることを強くお勧めします。
ここでAPIを壊します。

それよりも早く行うこともありますが、慎重に検討する必要があります。

他のオプションは、保存する場合は新しいリポジトリ/パッケージを作成することです
下位互換性が最も重要です。

それは結局、古いユーザーを孤立させ、多くの混乱を引き起こします。 私はしていません
これまでうまく機能していることがわかりました。
水では、2018年1月10日23:19デールホイで[email protected]は書きました：

dep 1.0はまだブロッカーですか？ readmeのステータスによると、depは
本番環境での使用に安全： https ：
つまり、マニフェストファイルとロックファイルは安定しています。 見る：
https://github.com/golang/dep/wiki/Roadmap#timeline

私の理解では、ゴリラ/セッションがdepを使い始めたら、ダウンストリーム
パッケージは影響を受けないはずです。 見る：
https://github.com/golang/dep/blob/master/docs/FAQ.md#my -dependers-dont-use-dep-yet-what-should-i-do

マスターブランチを使用しているダウンストリームパッケージは、次のことに注意する必要があります。
彼らは後方互換性のない変更にサインアップしました。 他のオプション
下位互換性を維持する場合は、新しいリポジトリ/パッケージを作成することです
最優先です。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/gorilla/sessions/issues/105#issuecomment-356847518 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AABIcO-Q_kwTZCommIiIm02ce7dd2afRks5tJbYWgaJpZM4LwM5f
。

dep ensure -add github.com/gorilla/sessions@^1.0.0はパッケージを適切に固定する必要があります。
しかし、ええ、 go getを使用している（または使用している）人は誰でも問題が発生し、すべてのダウンストリームパッケージにdep使用を強制するには時期尚早だと思います。

すべてのv2作業を開始するためにv2ブランチを作成し、v2ブランチから新しいリリースにタグを付け、v2ユーザーにdep使用を要求することについてどう思いますか？ depがツールチェーンの一部である場合、v2ブランチをマスターにマージして戻すことができます。

はい、それは私が検討したオプションです。

セッションは依存しているので、最初にsecurecookieの作業を開始する必要もあります
securecookieで、そのライブラリを更新したいと思います。

木の上に、2018年1月11日は11時45分AMデールホイで[email protected]書きました：

dep sure -addgithub.com/gorilla/sessions@^1.0.0が正しく固定されている必要があります
その包み。
しかし、ええ、使用した（または使用している）人は誰でも問題が発生し、私は
すべてのダウンストリームパッケージの使用を強制するには時期尚早だと思います
部門

すべてのv2作業を開始するために、v2ブランチを作成することについてどう思いますか。
v2ブランチから新しいリリースにタグを付け、v2ユーザーに使用を要求する
dep？ depがの一部である場合、v2ブランチをマスターにマージして戻すことができます
ツールチェーン。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/gorilla/sessions/issues/105#issuecomment-357039763 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AABIcFVJM02Np6zhOehopNPu2dmzUwPkks5tJmTEgaJpZM4LwM5f
。

sessionsまたはsecurecookie問題についてタグを付けることで、どこで支援できるかを知っています。

ご意見がございましたら：

• securecookie v2パンチリスト：
  https://github.com/gorilla/securecookie/issues/43
• 更新されたセッションAPIはどのようになりますか（読んでください：どのような問題がありますか
  現在のAPIを変更して解決しますか？ 私たちもする必要がありますか？）
• ストアAPIに変更が必要かどうか。

「v2」とタグ付けされたいくつかの問題があります。
背景/ユーザーフィードバックですが、どちらか新しいものを確実に解決したいと思います
APIを壊して、問題を解決したり、古い問題をより適切に解決したりします。 のために壊す
壊すためにはあまり意味がありません;）

木の上に、2018年1月11日4:20 PMデールホイで[email protected]書きました：

かっこいい、lemmeは、
セッションまたはsecurecookie

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/gorilla/sessions/issues/105#issuecomment-357104851 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AABIcOppAU5Mj8YyU6US-lRBQ14wgb8oks5tJqVJgaJpZM4LwM5f
。

問題の説明に記載されている改善点のほとんどは、良いものだと思います。
私が最も役立つと思う変更（順番に）は次のとおりです。

1. ストアインターフェイスの強化
   
   
   
   • ストアAPIを刷新し、再設計する必要があります。 セッションストアの実装者は、応答にHTTPCookieを設定する責任を負わないようにする必要があります。 Cookieの管理とセッションのライフサイクルは、ストアではなくsessionsパッケージで処理する必要があります。
   
   
   • セッションストアには、セッションデータの永続性という1つの懸念事項のみが必要です。 コア機能（その一部でも）をストアにプッシュすると、サードパーティストア間で動作に一貫性がなくなり、将来的にコア機能を変更することが難しくなります。
   
   
   • Storeレシーバーメソッドを単純化してhttp.Requestとhttp.ResponseWriterないようにすると、重大な変更になります。
   
   
2. supporting request.Context（のみ）
   
   
   
   • request.Contextが使用された場合でも、レジストリ/キャッシュは必要ですか？
   
   
   • セッションをキャッシュするよりクリーンな方法は、既存のセッションストアを「ラップ」するセッションストアとしてキャッシュを実装することです。 次に、開発者はさまざまなキャッシュ実装から選択するか、複数のキャッシュレイヤーを使用できます。 例：インプロセスメモリキャッシュ、memcached、SQLストア
   
   
3. セッションを利用可能にする箱から出してすぐに使えるミドルウェア
   
   
   
   • また、ミドルウェアにセッションを保存してもらい、この改善に対処します。「ユーザーエクスペリエンスをSave前後に改善します（サックを保存するのを忘れて、十分に一般的です！）」
   
   
   • そして、「ストアインターフェースの充実」の改善を支援します
   
   
4. 改善された暗号インターフェース
   
   
   
   • 私は安全なデフォルトを持つのが好きですが、開発者がユースケースに合わせてセキュリティをカスタマイズできるようにしています。 これを行う良い方法は、別の「安全でない」または「危険物」パッケージを公開することです。 https://golang.org/pkg/unsafe/およびhttps://cryptography.io/en/latest/に触発されました
   
   
5. デフォルトのエンコーダーとしてのJSON

「sessions.Valuesをより良くする（マップではなくセッター、ゲッター）」に関しては、 sessions.Valuesマップを維持するだけでなく、型キャストのゲッターとセッターも公開したいと思います。 開発者は、型キャストの失敗を処理する独自の方法を持っている場合があります。

フィードバックをありがとう@dhui

ストアAPIを刷新し、再設計する必要があります。 セッションストアの実装者は、応答にHTTPCookieを設定する責任を負わないようにする必要があります。 Cookieの管理とセッションのライフサイクルは、ストアではなくセッションパッケージで処理する必要があります。
セッションストアには、セッションデータの永続性という1つの懸念事項のみが必要です。 コア機能（その一部でも）をストアにプッシュすると、サードパーティストア間で動作に一貫性がなくなり、将来的にコア機能を変更することが難しくなります。

同意します。 ストアには、セッションID（ルックアップを許可するため）、TTL（有効期限を許可するため）、およびセッションペイロード自体が必要です。 ここにはいくつかのアプローチがあります-さらなる議論が必要なため、今のところ署名からcontext.Contextを省略します。

type Store interface {
    Get(id string) (*Session, error)
    Save(session *Session) error
    Expire(id string) (bool, error)
}

ストアは*Sessionを正しい形式にマーシャリングすることに注意する必要があります。代わりにdataがすでにマーシャリングされている場所にid string, exp time.Time, data []byte送信することもできますが、マーシャリングはストアの範囲内であると感じています。 。

supporting request.Context（のみ）
request.Contextが使用された場合でも、レジストリ/キャッシュは必要ですか？

いいえ、しかしそれはより大きな、破壊的な変化に戻ります。 gorilla/contextは、リクエストのクローンを作成する方法が原因でrequest.WithContextと一緒に使用すると連携しないため、v2ではcontext.Contextのみをサポートします。

セッションを利用可能にする箱から出してすぐに使えるミドルウェア

どのようにそれを利用可能にしますか？ リクエストのコンテキストでは？ もしそうなら、そこからそれをフェッチすることは、context.Valueがinterface{}である場合を除いて、 sessions.Get(ctx, name)呼び出すのと同じ量のコードです。

一方、保存は（ほとんど）自動的に実行できますが、ミドルウェアが実行される前にユーザーが応答本文に書き込むと、問題が発生します。 ミドルウェアはhttp.ResponseWriterを乗っ取り、書き込みを延期してSaveできるようにする必要があります。 すべてのリクエストでSaveを望まないかもしれないという事実もあります。

改善された暗号インターフェース
私は安全なデフォルトを持つのが好きですが、開発者がユースケースに合わせてセキュリティをカスタマイズできるようにしています。 これを行う良い方法は、別の「安全でない」または「危険物」パッケージを公開することです。 https://golang.org/pkg/unsafe/およびhttps://cryptography.io/en/latest/に触発されました

私はこれについて非常に説得力のある議論を見る必要があるでしょう。 開発者がセッションライブラリの暗号化プリミティブをカスタマイズする必要がある理由について、賢明なユースケースは見当たりません。 CSPRNGを交換する必要はなく、AEADを変更する必要もありません。 認証専用モードにはHMAC-SHA-512を使用し、暗号化モード（AEAD）にはXSalsa20-Poly1305を使用します。

デフォルトのエンコーダーとしてのJSON

はい！

「sessions.Valuesをより良くする（マップではなくセッター、ゲッター）」については、sessions.Valuesマップを維持するだけでなく、型キャストのゲッターとセッターも公開したいと思います。 開発者は、型キャストの失敗を処理する独自の方法を持っている場合があります。

同意する！

どういたしまして！ オープンでさまざまなアイデアを受け入れてくれてありがとう！

ストアは、* Sessionを正しい形式にマーシャリングする必要があります。代わりに、id string、exp time.Time、data [] byteを送信することもできます。データはすでにマーシャリングされていますが、マーシャリングはストアの範囲内であると感じています。

同意しました。 []byte以外にも、ストアのより効率的なストレージメカニズムがある可能性があるため、ストアがデータの保存を担当する必要があると思います。 Sessionは、マーシャリングとアンマーシャリングをサポートするために、ストアにエクスポートされたすべての関連フィールドを必要とします。

どのようにそれを利用可能にしますか？ リクエストのコンテキストでは？

ええ、私はrequest.Context()エクスポートされていないコンテキストキータイプを使用してSessionを設定するミドルウェアのファンです。 そうすれば、消費する開発者向けのボイラープレートコードが少し少なくなります。
sessions.SessionFromRequest(http.Request) (*Session, error)ようなもの。 ミドルウェアなしで使用した場合、 errorを削除して、新しいSession errorを作成することもできますが、同じリクエストを使用する複数の呼び出しがある場合、微妙なバグが発生する可能性があります。

ミドルウェアは、保存できるようにhttp.ResponseWriterを乗っ取り、書き込みを延期する必要があります。

私はHijackerインターフェースに慣れていませんが、HTTP / 2接続との互換性が必要なようです。 WriteHeader()呼び出された後にCookieを設定するためにResponseWriterをラップすることが、最適なルートであるかどうかはわかりません。

すべてのリクエストで保存したくない場合があるという事実もあります。

ミドルウェアに関する良い点。 2つのミドルウェアを持つことができます：

1. クッキーを保存して設定するもの
2. 1つはセッションを検証するだけです）。

私はこれについて非常に説得力のある議論を見る必要があるでしょう。

ははは、私は持っているとは思いませんが、試してみます...私の最善の議論は、セキュリティのためにすべてに適合する1つのサイズはないということです。 セキュリティとは、使いやすさ、パフォーマンス、および予想される攻撃ベクトルに対する保護の間でトレードオフを行うことです。 その決定を下すのに最適な人はアプリ開発者です。 クリーンな暗号インターフェース（正常なデフォルトと十分な警告付きのカスタマイズを可能にする）を提供することで、開発者はユースケースのセキュリティをカスタマイズできます。 たとえば、セッションでは多分やり過ぎですが、必要に応じてHSMやTRNGを使用できます。

暗号インターフェースに関するもう1つのこと：アルゴリズム、キーサイズ、および作業係数を変更/アップグレードする方法があることを確認してください。 これらは常に変化するため、アルゴ、キーサイズ、および作業要素を自動アップグレードできるシステムは、将来の多くの頭痛の種を軽減します。

この問題は、最近の更新が確認されていないため、自動的に古いものとしてマークされています。 数日で自動的に閉鎖されます。

この問題は、最近の更新が確認されていないため、自動的に古いものとしてマークされています。 数日で自動的に閉鎖されます。

これを再開する必要がありますか？