最近 Flask というWebアプリフレームワークを、いじってて気付いた事をメモとっておく。 セッション管理の仕方が、面白かったというか自分はそういう風に実装した事なかったのでへーと思った。 僕のなかでのセッションデータの管理イメージ 別にこれが普通というわけではないのだろうけど、なんとなくこういうイメージ サーバサイドでセッションデータを発行 セッションキーをCookieとかクライアントサイドに持たせる。 違うページにいったら、セッションキーを元にセッションデータを取得 この場合、クライアントサイドにもつ情報は、セッションデータに紐づくキーであって、セッションデータそのものはサーバサイドのストレージなりなんなりにもってるイメージ。 事の発端 Flaskは MicroFrameworkをうたっているフレームワークなので、フレームワークが備える機能も必要最低限になっていて、足りないところは自
app.py ���o+V � �o+V from flask import Flask, request, session, url_for, redirect, \ render_template, abort, g, flash from werkzeug.contrib.sessions import Session, SessionStore from cPickle import HIGHEST_PROTOCOL from random import random from flask import json class MemcachedSessionStore(SessionStore): def __init__(self, servers=None, key_prefix=None, default_timeout=300): SessionStore.__init__
メモ。django.contrib.sessionsのセッションキーが毎回変わる?とかそんな話が出てて、どういう動きするんだったか調べてた。 Djangoのバージョンは1.2.4。 適当に書いたview関数。 views.py from django.http import HttpResponse from random import choice def index(request): x = choice([0, 1, 2]) if x == 0: request.session['a'] = 1 elif x == 1: request.session.flush() return HttpResponse(request.session.session_key + ' ' + str(request.session.keys()) + ' ' + str(x), content_
2年前にPHPのセッション管理に使う箱選び 4で、セッションストレージとしてはMySQLのInnoDBを使用するのが良いと結論付けた。 当時は主にセッション数が増えていった場合のパフォーマンスについて調べて結論を出したものの、実際にMySQLをセッションストレージとして使用すると、さらに負荷が高くなった場合のパフォーマンスや可用性の部分にちらほら課題が見えてくる。 つまり、大規模なセッションストレージとして使うにはMySQLは高機能過ぎて重く、さらに冗長構成になっていても障害発生時の対応は手動が基本になってしまう。(自動化できないわけではないと思う) MySQL :: MySQL 5.6 リファレンスマニュアル :: 17.3.6 フェイルオーバー中にマスターを切り替える セッションデータの集中管理をやめる*1というのも手だけれど、それはそれで大変なので別のセッションストレージにする方向で
えっと何がいいたいのかというとログインセッションの持続時間は、「最後のアクセスから1時間」といった感じに設定したいじゃないですか。それがZend_Auth使って普通にやると、いくら絶え間なくアクセスしてても指定時間がくるとタイムアウトしちゃう。 「最後のアクセスから」という風にするためにこんな感じにしてみた。 アクションクラス class MemberController extends Zend_Controller_Action { public function loginAction(){ require_once 'Zend/Auth.php'; $auth = Zend_Auth::getInstance(); require_once dirname(__FILE__).'/../models/session/Exte
Firefoxには、クラッシュしても次回起動時には元のセッションを復元してくれる機能があります。 タイミングによっては完全ではないものの、こうしたリカバリ機能が備わっていることにより、助かる場面も多々ありますね。 しかし、デフォルトのセッションマネージャだけではせいぜい少し前のセッションが復元出来る程度で、ちょっと物足りないという方もいらっしゃるでしょう。 そんな方は、もっと高機能なセッション管理ができるようになるFirefoxアドオン「Session Manager」を試してみてはいかがでしょうか。 「Session Manager」は、デフォルトには無い、高度なセッション管理機能をFirefoxに与えてくれるアドオンで、セッション管理専用ツールならではの、保存、管理、復元を自在に行うことができるというアドオンです。 アドオンをインストールすると、[ツール]メニューに[セッションマネージ
ワッサーでつぶやいていて、PHPで個体識別番号をセッションIDとして使う方法を教えてもらった。http://wassr.jp/user/nihen/statuses/skctoRFZ3G 目からうろこが落ちた。 <?php session_id(get_mobile_id()); session_start(); if (!isset($_SESSION['count'])) { $_SESSION['count'] = 0; } else { $_SESSION['count']++; } echo $_SESSION['count']; ?>http://pastebin.com/m74eb934f ここで、get_mobile_id()で個体識別番号を取得するらしい。 で、それをセッションIDとして、session_idで認識させる。すると、CookieやHiddenを使えなくてもO
DjangoのSessionはCookieが使えないと使用できません。思想的にアウトですが、どーしても携帯対応でSessionが必要になりましたので、独自SessionMiddlewareを作りました。作ったといっても大したもんではありませんけど。。。 #coding: utf-8 from django.conf import settings from django.contrib.sessions.middleware import SessionMiddleware class SessionExMiddleware(SessionMiddleware): def process_request(self, request): engine = __import__(settings.SESSION_ENGINE, {}, {}, ['']) session_key = get_s
Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ
なんかスマートな方法じゃないですが、次のような感じでできます。 #!/bin/sh COOKIE_FILE=cookies.log wget --save-cookies=$COOKIE_FILE \ --keep-session-cookies \ -O /dev/null \ http://example.com/path/to/create/session wget --load-cookies=$COOKIE_FILE \ -O page.html \ https://example.com/path/to/session/required/page \rm -f $COOKIE_FILE セッションを発行するURLに対しては、 --keep-session-cookiesオプションでセッションCookieを保持することを宣言 そのCookieを--save-cookiesオプショ
coreのSession.timeoutを長めに設定していても、php.iniの設定によってはそれより早くセッションが切れてしまう。 これはphpのガベージコレクション*1が働いているのが原因。 解決するにはcore.phpに以下のように書く。 <?php Configure::write("Session.save", "cake"); Configure::write("Security.level", "medium"); // セッションは24時間でタイムアウトし、 Configure::write("Session.timeout", 24 * 60 * 60 /100); // それ以降にリクエストがある度、 ini_set("session.gc_maxlifetime", 24 * 60 * 60); // 1/100の確立でガベージコレクションを行う。 ini_set("
Webアプリケーションのログインの際によく「ログイン状態を保持する」(セッションCookieの有効期限をブラウザ終了時までではなく一定期間に指定する)という選択肢を設けることがある。Djangoの標準の認証機構ではそういったことができないなーと思っていて、でも、Pinaxにはあるだろうと考えたら、やっぱりあった。pinaxのlocal_apps/accountを使えばよさげ。以下は、pinax/local_apps/account/forms.pyからの抜粋。 class LoginForm(forms.Form): username = forms.CharField(label=_("Username"), max_length=30, widget=forms.TextInput()) password = forms.CharField(label=_("Password"), w
Zend Amf now with php session supportPHP session support is now enabled through the Zend Amf. To get started you need to update your Zend_Amf_Server class from the repository. You will also need to make sure you have Zend_Session for those of you that are using the framework on as use-at-will bases. Once you have updated your server you will need to also update your bootstrap/endpoint file to star
Zend_Session_Validator_HttpUserAgentを用いてZend_Session_Validatorを解説。Zend_Session_Validateなる存在をみなさんご存知ですか?Zend Frameworkのマニュアルには載っていないのですがZend_Session_Validateを使用する事でZend_Session::start()時にセッションデータの検証を行う事が出来るのです。Zend_Sessionのソースを覗いている時に偶然発見してしまいました。たまにはソースも覗いてみるべきですね! Zend_Session_Validatorの処理としてはZend_Session::registerValidator()で検証すべきデータをセッションに格納し、Zend_Session::start()の時にセッションデータの検証を行います。で、その検証に失敗する
セッション(session)の有効期限を設定するには ishii (2005年7月 5日 04:54) | 個別ページ | コメント(2) カテゴリ PHP タグ .htaccess, PHP セッションについて書いてみたらどうでもいいネタばかりになっちゃったけど、まあいいや。誰かのお役に立てれば。 セッションは、基本的に session.gc_maxlifetime session.gc_probability session.gc_divisor の3つをこねくりまわせば有効期限を制御することができる。この中で一番大切なのはsession.gc_maxlifetimeで、ここにセッションの有効期限を秒数で設定すればいい。 この記事を見た人は以下のエントリも見ています symfonyでカスタムバリデータを使ってフィルタを実装する PHP5.2.8 で Mojavi3 を動作させた際に出る
PHPでセッションを破棄する方法について、きちんと解説されたものが見つからなかったので書いておく。 まず、PHPでセッションを破棄する方法自体はPHPのマニュアルの載っている。↓の部分だ。 <?php // セッション変数を全て解除する $_SESSION = array(); // セッションを切断するにはセッションクッキーも削除する。 // Note: セッション情報だけでなくセッションを破壊する。 if (isset($_COOKIE[session_name()])) { setcookie(session_name(), '', time()-42000, '/'); } // 最終的に、セッションを破壊する session_destroy(); ?> 問題は、このコードについてまともな説明がされていないことだ。よくわからないままに使っている人も多いように思える。例えば「PHP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く