タグ付けされた質問 「session」

IPアドレスを介してCookieを使用することでいくつかの追加の利点があることはわかっていますが、私の質問は、クライアントがサイトに再度アクセスしたときにクライアントを識別する際にクライアントのIPアドレスを記憶できないのはなぜですか？コンテナがIPアドレスを使用してクライアントを記憶することは可能ですか？

26 http  session  networks  cookies  client-server 

Web開発者として、私たちは皆、セッションがHTTPのステートレスな性質に関連する問題を克服するのに役立つことを知っています。一意のセッションID を作成してブラウザーに送信します。ブラウザーが同じIDを送り返すと、ユーザーを簡単に識別できます。 これらはすべて簡単に聞こえますが、どの言語でも実装するのはそれほど複雑ではありません。 いま 私が撮った次のスクリーンショットを見てください。これらは、人気のあるWebサイトが保存するCookieの種類を示しています。複数のセッションIDを保存しているように見えるか、非常に多くのCookieを設定して実際のIDを非表示にしようとしているようです。または、何でも。 Gmail（ログイン前） Gmail（ログイン後） フェイスブック StackExchange （心配しないでください、あなたは私のセッションを盗むことはできません-それは古くて不完全です:)） だから、私の質問は-この複雑さはどのような目的に役立つのでしょうか？これらの異なるCookieの意味（一般的に）と、それらが設定されている目的を説明してください。最後に、自分のアプリでそれをどのように行うことができるか（そして、そうすべきかどうか）のヒント。 もう1つの質問：多くの場合、Cookieの値はURLエンコードされているように見えますが、なぜですか？

19 session 

ショッピングカートの設計に取り組んでおり、セッションまたはデータベースのいずれかにショッピングカートを保存する必要がありますが、どちらのアプローチが最適かはわかりません。 ユーザーはログインしておらず、カートに商品を追加していません（匿名ユーザー） ユーザーがログインし、カートに製品を追加しています。 ユーザーがログインせずにWebショップにアクセスして製品を追加するだけでなく、チェックアウトプロセスに行かない可能性が高いため、最初のケースは私を混乱させます。 ただし、ショッピングカートを作成して保存するには、このユーザーのショッピングカートを作成する必要があります。2つのオプションがあります。 ユーザーが製品を追加するときに、データベースにカートを作成し、このカートをこのユーザーに関連付けます。ログインした瞬間に、このカートをログインしているユーザーに移動します。 ユーザーがログインしてデータベースにカートを作成し、ログインしたユーザーをこのカートにユーザーと関連付けた場合、カートを作成し、製品を追加してセッションに保存します。 データベースベースのカートシステムとセッションベースの両方に肯定的側面と否定的側面があることを知っていますが、次の点を考慮するためにどちらが最善のアプローチであるかはわかりません 拡張性 柔軟性 拡張性 アプリケーションは速度に注意する必要があります この側面に関する入力を探して、パスを決定します。

16 database  session  design  web-applications 

Webアプリケーションの認証/承認について読んでいます。誰かが私の現在の知識を確認/修正できますか？ Cookie：初期のバージョンでは、一意のクライアントIDを含むテキストファイルと、クライアントについて必要なその他すべての情報（ロールなど） セッション：一意のクライアントIDのみがファイル（Cookieとも呼ばれます）で送信され、それ以外はすべてサーバーに保存されます JWT：すべてがトークンに保存されます（これは、Cookieとも呼ばれるテキストファイルに保存することもできます） フィードバックをありがとう！

12 authentication  authorization  session  cookies  jwt 

複数の開発者がこの問題の解決策を探しているのを見てきました：異なるWARからのセッション情報へのアクセス（同じEAR内であっても）-ここにいくつかのサンプルがあります：Tomcatの異なるアプリケーション間でセッション状態を共有する方法はありますか？、別のWebアプリケーションのアクセスセッション、異なるWARファイル、共有リソース、Tomcat：2つのアプリケーション間でデータを共有する方法 、TomcatでcrossContext属性は何をしますか？セッション共有を有効にしますか？等々... 私が検索したすべてから、コンテナに応じていくつかの特定の解決策がありますが、それはどういうわけか「仕様に反しています」。また、答えを見つけることができずにJava EE仕様を調べました。 一部の開発者はWebアプリケーション間のカップリングについて話しますが、私は反対する傾向があります。カップリングしない場合、同じEAR内にWARを保持する理由は何ですか？たとえば、EJBはローカルにアクセスできます（同じEAR内の別のEJB JAR内にある場合でも）。 より具体的には、私のWARの1つが認証と許可を処理し、この情報を（同じEAR内の）他のWARと共有したいと思います。以前、WARをJARとしてパッケージ化し、それらを単一のWARプロジェクト（WEB-INF / lib）に入れることで、同様の問題を回避することができました。しかし、私はこのソリューションが好きではありません（サーブレットの命名などに多大な労力が必要です）。 そして、最初の（そして最も重要な）質問に答えるソリューションはありません：なぜWARはセッション情報を共有できないのですか？

11 java  web-applications  session 

これは重複としてマークされる可能性が高いことを知っていますが、探しているものを正確に見つけることができませんでした これは一般的な問題であり、明確に定義されたベストプラクティスソリューションがあるはずです。 バックグラウンド 単一ページのSaaSアプリ、ドラッグアンドドロップがたくさんあり、ユーザーは一定期間サーバー通信がなくてもアプリを操作できます サーバーセッションは、非永続的なセッションCookieを使用して、ユーザーオブジェクトのみを保持します X時間後にサーバーでセッションが期限切れになる ログイン時にのみ読み込まれるもの 問題 ユーザーはアプリで作業し、完了してもログアウトせず、ブラウザーを開いたままにします ユーザーがX時間を超えて戻ってきた（セッションがサーバーで無効になっている） ユーザーはサーバー接続を必要とせずにアプリと対話します（ドラッグアンドドロップ、テキスト編集など） 次のサーバーとの対話時のみ（自動保存がないと仮定）、ユーザーはログインページにスローされ、一部の作業が失われます 可能な解決策 私が考えているいくつかの解決策があります。他に解決策があるかどうか、そして根本的に何か問題があるかどうかを聞きたいです。 1.ユーザーをログアウトしないでください どうやって？長いセッションを維持する、永続的なcookieを維持する、またはjavaScriptの「キープアライブ」ping 長所：ユーザーは何も心配する必要がなく、問題を修正します 短所：PCIに準拠せず、安全ではなく、開発の変更が必要です。たとえば、ユーザーのログイン時にのみセッションに読み込まれるものは、pubサブモデル（イベントの変更をリッスンする）に移動するか、キャッシュタイムアウトを持つ必要があります。 2.ローカルストレージ どうやって？ログアウトした場合、新しいローカルストレージを使用して状態を一時的に保存し、ログインページにリダイレクトし、ログイン後も保持する 長所：セッションタイムアウトの処理だけでなく、「オフライン作業」サポートのベース 短所：実装が難しく、データツリーの状態マージを行う必要がある、すべてのブラウザがサポートするわけではない 3.自動保存 モデルを変更するすべてのユーザーアクションは、すぐに（またはクライアント側のキューを介して）永続化する必要があります。たとえば、ユーザーがチェックボックスをオンにしたり、テキストフィールドを変更したり、何かをドラッグアンドドロップしたりすると、変更が永続化されます。 どうやって？MV **フレームワーク（Backbone.js / Knockout.js / Ember.js / Angular.jsなど）を使用してモデルをバインドし、変更を維持します。 長所：クリーンなソリューションのようです。ユーザーがアクティブである限りセッションはアクティブであり、永続化せずにクライアント側の作業は行われません。 短所：セッションタイムアウトが失われた後、ユーザーが最後に行ったアクション。 4.セッションの有効期限が切れた後、ユーザーをログアウトします これにはいくつかのアプローチがあります サーバーに「セッションの期限が切れています」と尋ねます。これは、サーバーへの単なる質問がセッションを延長する（タイムアウトを再開する）ため、ちょっとしたキャッチ22 /シュレディンガーの猫です。 どうやって？そのような質問をサポートするサーバーを持っているか（私は知りませんが、Javaランドから来ます）、またはセッションIDのテーブルと最終アクセス時間を手動で保持し、セッションを渡すことによってサーバーに問い合わせることができますCookieの代わりにパラメーターとしてIDを使用します。これが可能かどうかはわかりませんが、危険で、安全でなく、設計が間違っているようです。 長所：サーバーにそのようなネイティブサポートがあった場合、クリーンで正当な質問のように聞こえます（ユーザーXがまだセッションを持っているかどうかを尋ねます） 短所：サーバーがそれをサポートしていない場合（そして、サーバーやフレームワークにこの機能があるかどうかはわかりません）、回避策には潜在的に大きなセキュリティリスクがあります。 私が聞いた1つの回避策は、サーバー側での短いセッションと、最大数のpingを持つキープアライブクライアント側のpingです。 どうやって？サーバー上の短いセッション、クライアントはすべてのsessionTimeOut / 2にpingを実行し、最大再試行回数はYです。 長所：問題の修正の種類、迅速で汚い 短所：サーバーに任せるのではなく、自分でセッションの更新を処理するハックのように感じる クライアント側タイマー どうやって？クライアント側にタイマーを設定し、すべてのリクエストで再起動してサーバーのタイマーと同期させ、最大サーバーセッションタイムアウトからパディングを差し引いた値に等しくします。ユーザーがサーバーにリクエストを送信していない後、UIに「セッションは間もなくタイムアウトします。続けますか？」（あなたがオンラインバンキングに持っているように） 長所：問題を修正します …

11 web-development  session 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 PHPセッションを処理するための最良かつ最も安全な方法は何ですか。セッションを保存する最良の方法は次のとおりです。 データベース（信頼性は高いが、ボトルネックが高く、速度が遅い、データベース使用率の高いWebサイトには適さない）？ Memcache（超高速ですが、より多くのセキュリティ問題が分散し、サーバーの再起動時にデータが失われる可能性、およびキャッシュがいっぱいになるとデータが失われる可能性があります）？ ファイル（デフォルトのオプション、ファイルI / Oからの読み取りと書き込み、セキュリティの低下などから遅いと思います）。 どの方法が最適ですか？これらのアプローチのそれぞれの問題点と良い点は何ですか？

10 php  session 

私はjwt.ioと認証に比較的慣れていないため、次のようにJWT.ioを使用しています。 サーバ側 ユーザーがログインしたら、userid内部に埋め込まれたトークンを生成し、メッセージ本文でユーザーに返します クライアントサイドブラウザー/ JSトークンをlocalStorageに保存し、後続の各リクエストで、トークンをヘッダーに渡します。 Authorization: Basic someEncryptedValue 私も使用しました X-Auth-Token: someEncryptedValue これをクッキーに入れてもいいですか？ 次に、サーバー側で、トークンをシークレットに対して検証し、有効期限を確認し、トークンからIDを取得して、リクエストを処理します。 このワークフローはすべて正しいですか？

8 authentication  session  authorization  cookies 

バックグラウンド： 現在、REST APIを構築する過程で、ノードw / expressを使用しており、モバイルアプリと最終的には（最新のブラウザーベースの）Webサイトによって消費されます。 私は、ユーザーが自分のリソースを変更することのみが許可されるように、ユーザーの更新/アクション要求を承認する最良の方法を特定しようとしています。アクションは準高頻度で発生するため、懸念事項です。 注：この使用例では、エンティティーの所有権を譲渡することはできません。 可能なソリューション： 解決策：reddisなどのサーバーセッションで各ユーザーのリソースのリストを保存および維持します。 懸念事項：サーバー側セッションの永続化には、複数のサーバーに合わせて拡張する独自の複雑さのセットがあります。これもRESTに違反しています。詳細については、do-sessions-really-violate-restfulnessをご覧ください。 解決策： ユーザーの更新/アクションクエリの前に読み取りクエリを実行します。IEは私にこのユーザーのアイテムを提供し、リストにある場合は更新を続行します。 懸念事項： ユーザーがリソースに代わって操作するたびに追加の読み取りのオーバーヘッド。 解決策： ユーザーIDをdbレイヤーに渡し、それを更新条件付きの一部にします。または、ファンシーを取得したい場合は、データバックエンドに応じて、そのリソースに対してPostgresの行レベルのセキュリティなどを使用します。 懸念事項： リソースがリクエストしているユーザーのものかどうかを確認するには、リクエストのライフサイクルの少し遅いようです。エラーは、データバックエンドからずっと上にスローされる必要があります。同じように、認証とロールベースの承認はリクエストのライフサイクルの最初に行われることが多いので、少しずれているかもしれません。実装は、データバックエンドにも依存します。また、データバックエンドにビジネスロジックを示します。 解決策： クライアント側で一種のセッションに署名しました。JWTまたは暗号化/署名されたCookieを使用します。基本的に、ユーザーのリソースIDのリストを含む信頼されたセッションを維持します。 懸念事項： クライアント側セッションのサイズ。不要な場合でも、すべてのリクエストで送信されるという事実。複数のアクティブなセッション/クライアントの可能性を導入すると、メンテナンスが非常に複雑になります。リソースが別のクライアントに追加されたときに、クライアント側の状態をどのように更新しますか。 解決策： リソースがフェッチされるときに、署名された更新トークン（JWT）またはURLをリソースとともにクライアントに渡します。リソースが更新/アクションされたときに期待します。署名されたトークンには、ユーザーIDとリソースIDが含まれ、これらに対して簡単に確認できます。 懸念事項： リソースの所有権を譲渡できる場合は複雑になりますが、私の場合は問題ありません。更新前の読み取りよりも複雑になります。ちょっと変？ 最終的な考え： 私は最後の解決策に傾いていますが、それが頻繁に発生することはないので、何か不足しているのではないかと思いますか？あるいは、私が知らないデザインパターンの一部かもしれません。

8 rest  session  authorization  large-scale-project