Webpyでsessionを使用する
4944 ワード
sessionを使用する前にsessionとプログラミング中の実際の形態がどうなっているのかを理解するには、ここにははっきりしたページがあり、「このページを見るとオリジナルではないことがわかりますが、オリジナルの私はもう見つかりません」と直接貼っています.http://www.2cto.com/kf/201206/135471.html
上のページでは、sessionはサーバ側で生存して制御されており、クライアントではsessionの証明書を一時的に保存するしかありません.session idです.クライアントがsession idを保存する方法は、url接尾辞、Webページの非表示フィールド、cookie、その中で最もよく使われるのはクッキーであり、クライアントがクッキーを無効にした場合にのみ他の状況を考慮する.クッキー保存セッションidだけでなく、ハードディスク保存、メモリ保存の2つの形式に分けられます.ここで、ハードディスク(HDD)の保存方式は、ブラウザを閉じてから再び開くと有効になります(クッキーの有効期間によって異なります).メモリの保存方式では、ブラウザが閉じられるとsession idが失われます.メモリ方式保存セッションはブラウザによって共有メカニズムが異なり、FFはドメイン名のtabページがすべて1つのセッションidを共有しているが、ie下の同ドメインの異なるtabページはセッションidを共有していない.tabページを継承するだけで親tabページとセッションidを共有する.したがってメモリセッションでもセッションがシリアル化される場合があります.【テストの学生はもっと試してみることができて、ほほほ】
ここまでクライアントはほとんどありません.sessionに関する主な仕事はすべてサーバー側で行われます.まず、サーバーで各ユーザーの要求を検出し、ユーザーの要求に関する情報「例えば、ip、cookie」を取得し、サーバーはまず特定のsession idフィールドがあるかどうかを検査します.「もちろん、自分が前回設定したフィールドです」.このクライアントがリクエストを初めてまたは中断したことを説明していない場合、サーバは、セッションオブジェクトを新たに生成し、セッションidを生成します.今回のユーザアクセス中に、サーバは有用なユーザ情報を記録し、そのセッションidラベルの下に保存することができます.サーバ処理が終了すると応答時のヘッダにセッションidをクッキーとして設定し、次回リクエストするときにセッションidがクエリーできるようになり、このクライアントが初めてリクエストしたのではなく、サーバ側もセッションidで以前のユーザ操作で保持していたユーザ情報をクエリーできるようになります.これにより,ユーザが複数回連続してアクセスする場合の状態と情報の連続性が保障されるが,http自体は無状態であり,セッションメカニズムを用いないとこのような効果は得られない.
セッションオブジェクトの作成については、セッションid応答ヘッダの設定などが標準化されているため、webpyにもセッション機能をサポートするモジュールが用意されています.どのように使用するかは、以下を参照してください.
もう1つは、上のコードが1つのファイルにあり、sessionは現在のファイルのグローバル変数であるため、sessionは共通であることに注意してください.日常のプログラミングではすべてのコンテンツが1つのファイルに存在することは不可能であり、sessionはwebレベルのグローバル変数ではないので、複数のファイルのエンジニアリングで同じsessionを使用するには、サーバの初期化時にsessionをグローバルにアクセスできる場所に設定する必要があります.例えば、web.config、
参考資料:
http://www.2cto.com/kf/201206/135471.html
http://webpy.org/cookbook/userauthpgsql
http://webpy.org/cookbook/sessions.zh-cn
上のページでは、sessionはサーバ側で生存して制御されており、クライアントではsessionの証明書を一時的に保存するしかありません.session idです.クライアントがsession idを保存する方法は、url接尾辞、Webページの非表示フィールド、cookie、その中で最もよく使われるのはクッキーであり、クライアントがクッキーを無効にした場合にのみ他の状況を考慮する.クッキー保存セッションidだけでなく、ハードディスク保存、メモリ保存の2つの形式に分けられます.ここで、ハードディスク(HDD)の保存方式は、ブラウザを閉じてから再び開くと有効になります(クッキーの有効期間によって異なります).メモリの保存方式では、ブラウザが閉じられるとsession idが失われます.メモリ方式保存セッションはブラウザによって共有メカニズムが異なり、FFはドメイン名のtabページがすべて1つのセッションidを共有しているが、ie下の同ドメインの異なるtabページはセッションidを共有していない.tabページを継承するだけで親tabページとセッションidを共有する.したがってメモリセッションでもセッションがシリアル化される場合があります.【テストの学生はもっと試してみることができて、ほほほ】
ここまでクライアントはほとんどありません.sessionに関する主な仕事はすべてサーバー側で行われます.まず、サーバーで各ユーザーの要求を検出し、ユーザーの要求に関する情報「例えば、ip、cookie」を取得し、サーバーはまず特定のsession idフィールドがあるかどうかを検査します.「もちろん、自分が前回設定したフィールドです」.このクライアントがリクエストを初めてまたは中断したことを説明していない場合、サーバは、セッションオブジェクトを新たに生成し、セッションidを生成します.今回のユーザアクセス中に、サーバは有用なユーザ情報を記録し、そのセッションidラベルの下に保存することができます.サーバ処理が終了すると応答時のヘッダにセッションidをクッキーとして設定し、次回リクエストするときにセッションidがクエリーできるようになり、このクライアントが初めてリクエストしたのではなく、サーバ側もセッションidで以前のユーザ操作で保持していたユーザ情報をクエリーできるようになります.これにより,ユーザが複数回連続してアクセスする場合の状態と情報の連続性が保障されるが,http自体は無状態であり,セッションメカニズムを用いないとこのような効果は得られない.
セッションオブジェクトの作成については、セッションid応答ヘッダの設定などが標準化されているため、webpyにもセッション機能をサポートするモジュールが用意されています.どのように使用するかは、以下を参照してください.
import web
web.config.debug = False
urls = (
"/count", "count",
"/reset", "reset"
)
app = web.application(urls, locals())
session = web.session.Session(app, web.session.DiskStore('sessions'), initializer={'count': 0})
class count:
def GET(self):
session.count += 1
return str(session.count)
class reset:
def GET(self):
session.kill() ## session
return ""
if __name__ == "__main__":
app.run()
クライアントsession idはメモリとハードディスクに保存できますが、サーバ側sessionのメモリはメモリ、ハードディスク、さらにはデータベースに保存できます.どうせ保存できる情報のキャリアはすべてできますが、webpyではハードディスクとデータベースの2つの形式しかサポートされていません.他の形式の記憶方式を使用する必要がある場合は、Web.utilsサブクラスを自分で新しく書いて、その対応方法を実現すればいいので、上のコードのweb.session.DiskStore('sessions')
もちろんサーバ側のセッション保存も有効期間に設定できます.有効期限がなければ、どんなに大きなメモリでも、ハードディスクはいつかセッションで満たされるので、セッションを使用するときは有効期限を設定してください.サーバ側でセッションを無効にするには、有効期間の設定に加えて、クライアントの要求によってセッションをアクティブに閉じる必要があります.session.kill()
もう1つは、上のコードが1つのファイルにあり、sessionは現在のファイルのグローバル変数であるため、sessionは共通であることに注意してください.日常のプログラミングではすべてのコンテンツが1つのファイルに存在することは不可能であり、sessionはwebレベルのグローバル変数ではないので、複数のファイルのエンジニアリングで同じsessionを使用するには、サーバの初期化時にsessionをグローバルにアクセスできる場所に設定する必要があります.例えば、web.config、
web.config._session = session
このようにそのページでは、あなたがwebモジュールを参照しているだけで、web.config.を通過することができます.sessionがsessionコンテンツにアクセスしました.ただし、sessionのデフォルトはdebugモードでは使用できないため、公式の使用例ではデバッグモードがオフになります.web.debug=falseです.debugモードはreloadモジュールをreloadするため、sessionもreloadを繰り返します.実際には、デバッグモードをオフにするのを避けるには、以下のコードを使用します.if web.config.get("_session") is None:
from web import utils
store = web.session.DiskStore('sessions')
user = utils.Storage({
"id": "",
"name": "",
"email": "",
"privilege": "",
})
session = web.session.Session(app, store,
initializer={
"status": 0,
"user": user,
})
web.config._session = session
else:
session = web.config._session
では、sessionをグローバルに使用できるようにする方法もあります.メイン・プログラム・ページには、次のコードが追加されます.def session_hook():
web.ctx.session = session
app.add_processor(web.loadhook(session_hook))
他のページでセッションを呼び出します.print web.ctx.session.test
web.ctx.session.foo = 'bar'
さらにwebpyにはセッションを設定するエントリも用意されています.これらのエントリを設定することで、セッションのいくつかの属性を設定できます.たとえば、有効期間などです.web.config.session_parameters['cookie_name'] = 'webpy_session_id'
web.config.session_parameters['cookie_domain'] = None
web.config.session_parameters['timeout'] = 86400, #24 * 60 * 60, # 24 hours in seconds
web.config.session_parameters['ignore_expiry'] = True
web.config.session_parameters['ignore_change_ip'] = True
web.config.session_parameters['secret_key'] = 'fLjUfxqXtfNoIldA0A0J'
web.config.session_parameters['expired_message'] = 'Session expired'
参考資料:
http://www.2cto.com/kf/201206/135471.html
http://webpy.org/cookbook/userauthpgsql
http://webpy.org/cookbook/sessions.zh-cn