cgi-session-user Mailing List for CGI-Session (Page 14)
Brought to you by:
sherzodr
Menu
▾
▴
cgi-session-user — CGI::Session users mailing list
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
(13) |
Apr
(6) |
May
(2) |
Jun
(3) |
Jul
(2) |
Aug
(10) |
Sep
(9) |
Oct
(15) |
Nov
(1) |
Dec
(4) |
| 2004 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2005 |
Jan
(1) |
Feb
(8) |
Mar
(1) |
Apr
(1) |
May
(9) |
Jun
|
Jul
(14) |
Aug
(32) |
Sep
(34) |
Oct
(16) |
Nov
(6) |
Dec
(15) |
| 2006 |
Jan
(5) |
Feb
(27) |
Mar
(60) |
Apr
(12) |
May
(17) |
Jun
(24) |
Jul
(27) |
Aug
(16) |
Sep
(13) |
Oct
(19) |
Nov
(22) |
Dec
(29) |
| 2007 |
Jan
(23) |
Feb
(33) |
Mar
(42) |
Apr
(30) |
May
(14) |
Jun
(5) |
Jul
(12) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
(6) |
Feb
(9) |
Mar
(48) |
Apr
(20) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(9) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(11) |
Oct
(2) |
Nov
|
Dec
|
| 2010 |
Jan
(9) |
Feb
(28) |
Mar
|
Apr
(12) |
May
(13) |
Jun
|
Jul
(3) |
Aug
|
Sep
(1) |
Oct
(3) |
Nov
|
Dec
(9) |
| 2011 |
Jan
|
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(8) |
| 2015 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ju...@jh...> - 2006-08-23 23:08:26
|
Ron Savage wrote: > Couldn't you find this on CPAN? > > http://search.cpan.org/~rsavage/CGI-Session-ExpireSessions-1.08/ Uh, ehm, no. I must confess, I didn't search for it since I didn't reckon with a third party solution for this. Also since I didn't know that it exists, I'd soon given up searching. CPAN search doesn't find your module when searching for "Expire Sessions" or "CGI Session Expire" in All, only in Modules. Maybe I've to learn how to use CPAN search. But anyways, your module looks good. Thanks you for writing it and for the pointer. Bye, Jürgen |
|
From: Ron S. <ro...@sa...> - 2006-08-23 21:17:05
|
On Wed, 23 Aug 2006 14:33:50 +0200, J=FCrgen Herz wrote: Jurgen Couldn't you find this on CPAN? http://search.cpan.org/~rsavage/CGI-Session-ExpireSessions-1.08/ -- Cheers Ron Savage, ro...@sa... on 24/08/2006 http://savage.net.au/index.html Let the record show: Microsoft is not an Australian company |
|
From: <ju...@jh...> - 2006-08-23 12:34:01
|
Hi! Often sessions expire without their owner try to use them afterwards, so they stay in file/db. I could write a cleanup query for my SQL-db which I'd have to call in intervalls. But maybe there's already some code to achieve that in CGI::Session. So, what to do? Regards, Jürgen |
|
From: Sherzod R. <she...@ha...> - 2006-08-23 10:57:58
|
-----Original Message-----
From: Sven Neuhaus [mailto:sv...@sv...]=20
Sent: Wednesday, August 23, 2006 3:44 AM
To: Sherzod Ruzmetov
Subject: Taint problem with CGI::Session
Hello Sherzod,
I found a problem with Taint mode, DBI connections with the TaintIn-flag =
set
and CGI::Session. In your module, in _init_new_session(), the functions
sticks $ENV{REMOTE_ADDR} into the database without untainting it first.
Could you change the module so it untaints this value? I guess you need =
a
regex that covers both IPv4 and IPv6 to be on the safe side.
If you need assistance, please let me know.
Thanks,
-Sven Neuhaus
|
|
From: <de...@ki...> - 2006-08-20 02:35:59
|
四位名师向您揭示中国行业先锋企业的领先之道，协助企业实现精细化管理，开辟无人竞争
的全新市场，打造拥有军队般凝聚力的高效企业
※※※ 取名师所长 助企业创新 ※※※
时间：9月16日 向解放军学习――最有效率组织管理之道
9月17日 蓝海战略――用蓝海思维达至创新超越
9月23日 领先之道――透析中国行业先锋企业的商业精髓
9月24日 精细化管理
==============================================================================
联 系 电 话 :( 0 7 5 5 ) 8 3 1 6 6 8 4 6 ,, 8 3 1 6 6 8 4 7
报 名 传 真 :( 0 7 5 5 ) 8 3 1 6 6 8 4 7
地 点：中国.深圳
费 用：4800元/人（团体报名可享优惠）
对 象：企业总裁、副总裁、总经理、副总经理；市场、销售、人力资源等部门中高层管理团队
===============================================================================
§ 讲 师 介 绍 §
主讲嘉宾：张建华
著名组织建设与 组织行为管理专家
主讲嘉宾：余世维
中国管理教育第一人
主讲嘉宾：陈春花
《北大商业评论》 副主编，教授、博导
主讲嘉宾：汪中求
细节管理第一人
===============================================================================
§ 课 程 特 点§
四位名师向您揭示中国行业先锋企业的领先之道，协助企业实现精细化管理，开辟无人竞争
的全新市场，打造拥有军队般凝聚力的高效企业。
===============================================================================
§ 课 程 大 纲 §
★向解放军学习――最有效率组织管理之道
*张*建*华*
北京大学、清华大学等大学的客座教授；历任著名跨国公司COSCO企业宣传高级主管，R&D市场
信息研究部总经理、教授。
课程介绍：
解放军是中国最有效率的组织，张建华先生15岁加入中国人民解放军，从基层作战连队普通一兵，
到进入解放军的高级统帅机关，亲身体验了中国最有效率组织的管理之道。具备了军队和企业双
重管理经验的张建华，将军队的管理思想融入企业管理之中，提出“向解放军学管理”的口号，
《向解放军学习―最有效率组织的管理之道》与您一起学习中国最有效率组织的管理之道。
★蓝海战略――用蓝海思维达至创新超越
*余*世*维*
华人最权威、最资深的实战型培训专家，诺瓦大学公共决策博士，哈佛大学企管博士后，牛津大
学国际经济博士后，被称为“中国管理教育第一人”。
课程介绍：
“蓝海战略”是近年来风靡全球的管理思想，其核心思想是指导企业避开竞争，开创非竞争性的
全新市场。余世维博士的《蓝海战略》课程不仅仅是对《蓝海战略》的讲授与解读，更是余世维
管理创新思想与蓝海战略的完美结合，一次培训，两种收获。
★领先之道：透析中国行业先锋企业的商业精髓
*陈*春*花*
集博导、总裁、教授和咨询顾问于一身的传奇女性；《北大商业评论》副主编，华南理工大学教
授，广州市政府决策咨询专家， 2002年应邀担任山东六和集团的总裁，两年中，她将山东六和
的营业额从28亿带至2004年的75亿。
课程介绍：
商业思想改变商业世界，跨国公司在华二十年――惠普，上海大众，诺基亚，摩托罗拉，宝洁，
雀巢，IBM……不仅改变了中国的经济格局，同时为了适应中国环境，自身也做出了改变。在改
变与被改变的过程中，多少中国企业“失城割地”；多少民族品牌――浪奇、美加净、熊猫……
史诗般悲壮的倒下或者是彻底消失；同样也锻造了更多更响亮的新生一代的品牌企业：海尔、
TCL、联想、华为等，那么，到底是什么力量实现了这些新生一代企业的飞速成长并一直保持着
行业先锋的竞争力？究竟是什么力量让这些企业在成长中得以领先？
★精细化管理
*汪*中*求*
清华大学EMBA，汪中求细节管理网董事长、北京博士德公司特聘细节管理顾问、培训师，著有企
业管理著作《细节决定成败》和营销专著《营销人的自我营销》，引发了社会上有关“细节管理
的热潮”
课程介绍：
精细化管理时代－细节决定成败，汪中求提出的精细化管理口号，被誉为“扎在当今社会浮躁穴
位上的一根针”，在全国范围内掀起了”细节管理“研究实践的热潮，他也因此被誉为“中国企
业界细节管理第一人”。
《精细化管理》是汪中求细节管理思想的精华所在，与您一起开创企业的精细化管理时代。汪中求
提示企业乃至社会各界：精细化管理时代已经到来，一定要注重细节，把小事做细。
===============================================================================
---TO---cgi-session-user
-请-来-电-索-取-报-名-回-执-表-及-上-课-有-关-事-项-
===============================================================================
10:32:13
|
|
From: root <ro...@s1...> - 2006-08-16 22:42:39
|
On Tue, Aug 15, 2006 at 09:33:54AM -0400, Mark Stosberg wrote: > I usually store the name/pass in a "users" table, and check them at > login time, at which point "is_logged_in" gets added to the session. > > After that I simply check "is_logged_in". > I used the same method as Mark does, in addition I set the value of "is_logged_in" to the PRIMARY KEY collumn of the user. This helps me not just ensure the user is authenticated, but also the ID of the user, which can be used to load his details, if need be (to greet him, may be, but read on) Although I like keeping sessions open for longer time, to ensure the privacy of the users I set an expiration to the 'is_logged_in' session parameter, from 5 to 30 minutes (depending on the sensitivity of the profile data). This allows me to still be able to greet the users with their first name even after weeks (by storing the user's name in the session object), or display their recently viewed pages, or keep their shopping cart data, but force them to re-identify themselves when it comes to accessing their sensitive profile information. Good luck. Sherzod Ruzmetov |
|
From: Mark S. <ma...@su...> - 2006-08-15 13:35:17
|
Justin Simoni wrote: > Thought this may have been asked before, but the archives say > nothing :) Anyways, in the CGI::Session::Tutorial it states: > > # First rule of thumb, do not store users' passwords or other > sensitive data in the session, please. > If you have to, use one-way encryption, such as md5, or SHA-1-1. For > my own experience I can assure > you that in properly implemented session-powered Web applications > there is never a need for it. > > Source: http://search.cpan.org/~markstos/CGI-Session-4.14/lib/CGI/ > Session/Tutorial.pm#STORAGE > > I am in total agreement with this statement, but! how do you check > the credentials of the user, if there isn't some sort of credentials > in the session file? I thought this would be one the most Frequently > Asked Question. > > My guess is, that before you issue a session, you first check the > credentials of the person and if they check out, you issue the > session, with the correct bits in there to allow the individual to > use your webapp. Since you've checked the credentials once, checking > a saved username/password pair again and again from the same session > information is redundant and a security risk, since some sort of > credentials, however encrypted are in the session itself. > > Is this the basic jist of the situation, or is there more? That's basically it. I usually store the name/pass in a "users" table, and check them at login time, at which point "is_logged_in" gets added to the session. After that I simply check "is_logged_in". Mark |
|
From: Justin S. <ju...@sk...> - 2006-08-15 05:52:11
|
Thought this may have been asked before, but the archives say nothing :) Anyways, in the CGI::Session::Tutorial it states: # First rule of thumb, do not store users' passwords or other sensitive data in the session, please. If you have to, use one-way encryption, such as md5, or SHA-1-1. For my own experience I can assure you that in properly implemented session-powered Web applications there is never a need for it. Source: http://search.cpan.org/~markstos/CGI-Session-4.14/lib/CGI/ Session/Tutorial.pm#STORAGE I am in total agreement with this statement, but! how do you check the credentials of the user, if there isn't some sort of credentials in the session file? I thought this would be one the most Frequently Asked Question. My guess is, that before you issue a session, you first check the credentials of the person and if they check out, you issue the session, with the correct bits in there to allow the individual to use your webapp. Since you've checked the credentials once, checking a saved username/password pair again and again from the same session information is redundant and a security risk, since some sort of credentials, however encrypted are in the session itself. Is this the basic jist of the situation, or is there more? Currently, my webapp *does* store an encrypted password, but the password can be decrypted using a shared key - so if you have access to the session file, you'll also most likely have access to this shared key (which is located in a different physical place - NOT in the session file, but still easy enough to find, if you look hard enough). This scenario is like it is, because the actual password is stored in an encrypted form via crypt(). Safe to say, I'd like to close up this little (big) security hole in my webapp, but I don't want to open another hole somewhere else. Thanks for all guidance, you've all been a great help to me, Justin Simoni -- :: is an eccentric artist, living and working in Denver, Colorado :: URL: http://justinsimoni.com :: Mailing List - http://justinsimoni.com/mailing_list.html |
|
From: - 2006-08-12 13:31:36
|
=?GB2312?B?ILeoIMLJIM7zIMf4Kw==?= <gy...@li...>
Subject: =?GB2312?B?LTnUwjGjrTLJz7qjLTnUwjI5o60zMMnu29ot?=
To: cgi...@li...
Content-Type: text/plain;
charset="gb2312"
Content-Transfer-Encoding: 8bit
Reply-To: gy...@li...
Date: Mon, 14 Aug 2006 11:36:10 +0800
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
¡ù¡ù¡ù н ³ê ¸£ Àû ÖÆ ¶È Éè ¼Æ Óë ʵ Ê© ÖÐ µÄ ³£ ¼û ·¨ ÂÉ Îó Çø ¡ù¡ù¡ù
cgi-session-userÄúºÃ~
===============================================================================
Ö÷ °ì »ú ¹¹£ºÀÍ ¶¯ ±£ ÕÏ ÑÐ ¾¿ »á
Áª ϵ µç »°£º0 7 5 5£8 3 1 6 6 7 0 0 8 3 1 6 6 7 0 1 ÍõС½ã
±¨ Ãû ´« Õ棺0 7 5 5£8 3 1 6 6 7 0 1
ʱ ¼ä µØ µã£º2 0 0 6 Äê 9 Ô 1£2 ÉÏ º£
2 0 0 6 Äê 9 ÔÂ 29 £30 Éî ÛÚ
·Ñ¡¡¡¡Óãº2000Ôª/ÈË(º¬½²Òå¡¢Îç²Í¡¢²èµã¡¢ºÏÓ°¡¢Í¨Ñ¶Â¼)
ÊÚ ¿Î ¶Ô Ï󣺹«Ë¾¸ß²ã¹ÜÀíÕß¡¢ÐÐÕþÈËÊ¡¢²ÆÎñ²¿¡¢ÈËÁ¦×ÊÔ´²¿¾Àí¡¢Ö÷¹Ü¼°¸÷Ö°Äܲ¿ÃÅÖ÷¹ÜµÈ
===============================================================================
¡ì¿Î--³Ì--±³--¾°¡ì
¼¨Ð§µÄÌáÉý£¬Ð½³ê³É±¾µÄ¿Ø¹Ü£¬ÊÇ21ÊÀ¼ÍÆóÒµÃæÁÙµÄ×î´óÌôÕ½¡£ÈçºÎÀûÓÃÓÐÏÞµÄн×ÊÔ¤
Ë㣬ѰÇóÆóÒµ¾Óª³É±¾¡¢¾ÓªÐ§ÒæÖ®¼äµÄ×î¼Ñƽºâµã£¬´ïµ½Áô²Å¡¢Çó²ÅµÄ¡°Ë«Ó®¡±£¿ÈçºÎʹ¼¨
Ч¡¢Ð½³êÕ½ÂÔÓëÆóÒµµÄ¾ÓªÕ½ÂÔÏàÁªÏµ²¢Ö§³ÅÆóÒµµÄ¾ÓªÕ½ÂÔ£¿¼¨Ð§¿¼ºËÓëн³ê¸£Àû¹ÜÀíÊÇHR
²¿ÃŵĻù´¡¹¤×÷£¬¶øÓɼ¨Ð§¿¼ºË¡¢Ð½×ÊÒýÆðµÄ·¨ÂÉÕùÒéÈ´Ò»ÔÙ³ÉΪÀͶ¯ÕùÒéÖÐ×îÆÕ±éµÄÎÊÌâ¡£²»
¹ÜÊǽ¨Öþ¹¤µØµÄÃñ¹¤£¬»¹ÊÇÄêнÊý°ÙÍòµÄ¸ß¹Ü£¬¶¼Ò»ÔÙµÄΪн×Ê×ßÉϹ«Ìá£È«Çò»¯µÄн×ÊÌåϵ¾¿
¾¹ÈçºÎÊÊÓ¦±¾ÍÁ¸´Ôӵķ¨ÂÉ»·¾³£¬¿çµØÇø·¢Õ¹µÄÆóÒµµ¥Î»Ó¦µ±ÈçºÎÊÊÓ¦²»Í¬µØÇøµÄÌØÊâÒªÇó£¿Èç
ºÎºÏ·¨ÔËÓÃн×ʵĸܸË×÷ÓôٽøÈËʹÜÀí¡¢ÌáÉýÔ±¹¤Äܼ¨£¿
===============================================================================
¡ì¿Î--³Ì--ÌØ--É«¡ì
¿Î³Ì¸ù¾ÝÊ×ϯ¹ËÎÊκºÆÕ÷ÏÈÉúΪ½ü°Ù¼ÒÖªÃûÆóÒµÌṩÀͶ¯ÈËʹÜÀí¹ËÎÊ¡¢×ÉѯºÍÕùÒé´¦
·þÎñµÄ¶àÄêʵ¼ù¾ÑéÓëÑо¿³É¹û£¬´ÓÆóÒµ¹ÜÀíËùÃæÁÙµÄʵ¼ÊÎÊÌâ³ö·¢£¬½áºÏ×îз¨Âɹ涨£¬Í¨
¹ý´óÁ¿¾µä°¸ÀýµÄ·ÖÎöºÍ½²½â¡¢ÏÖ³¡´ðÒÉ¡¢¾Ñé½»Á÷Ó뻥¶¯ÑÐÌֵȷ½Ê½£¬Õë¶Ô¼¨Ð§¡¢Ð½³ê¸£Àû
¹ÜÀí¾«ÐÄÉè¼ÆʵÎñѵÁ·£¬ÓбȽϡ¢ÓзÖÎö¡¢ÓÐѵÁ·£¬ÈÃÄúÔÚ¾ßÌåµÄ°¸ÀýʵÎñ²Ù×÷ÖÐÖØÐÂÉóÊÓÀÍ
·¨ÂɹØÓÚ¿¼ºËÓëн×ʵľßÌå¹æ¶¨¼°µ÷ÕûÊֶΣ¬È«ÃæÌáÉýÆóÒµ¹ÜÀíÕßÓÐЧԤ·ÀÓëÓ¦¶ÔÈËÁ¦×ÊÔ´¹Ü
Àí·çÏÕµÄÄÜÁ¦£¡
===============================================================================
¡ì ½²--ʦ--¼ò--½é¡ì
κºÆÕ÷£¬·¨Ñ§Ë¶Ê¿£¬ÀͶ¯·¨ÊÀ½çÊ×ϯ¹ËÎÊ£¬¡¶Ô±¹¤¹Øϵ¡·Ö÷±à£¬ÖйúÈËÁ¦×ÊÔ´¿ª·¢Ñо¿»á
ÌØÔ¼½²Ê¦£¬²¢¼æÈζà¼Ò×Éѯ»ú¹¹ÌØÔ¼ÅàѵʦºÍ×Éѯ¹ËÎÊ¡£Ö÷³Ö¡¶¶þÊ®Ö÷Òª³ÇÊÐÀͶ¯·¨¹æÕþ²ßʵÎñ
±È½ÏÓëÓ¦Óá·,¡¶ÖйúÀͶ¯·¨¹æ¡¢Éç»á±£ÕÏÓëÔ±¹¤ ¹Øϵ¹ÜÀíÖ¸ÄÏ¡·¡¢¡¶ÆóÒµ²Ã¼õÔ±¹¤ÊµÎñ²Ù×÷ÊÖ
²á¡·µÈÊéµÄ±àд¹¤×÷³¤ÆÚ´ÓÊÂÀͶ¯·¨ÓëÔ±¹¤¹Øϵ¹ÜÀí×ÉѯÓëÅàѵ¹¤×÷£¬ÔÚÉϺ£¡¢±±¾©¡¢ÉîÛÚ¡¢¹ã
ÖÝ¡¢ËÕÖÝ¡¢ÄϾ©¡¢º¼ÖÝ¡¢ÏÃÃÅ¡¢¸£ÖÝ¡¢³É¶¼µÈµØ³É¹¦Ö÷½²°ÙÓೡÀͶ¯·¨ÓëÔ±¹¤¹Øϵ¹ÜÀí¹«¿ª¿Î¼°
ÆóÒµÄÚѵ¿Î³Ì£¬ÊÜѵѧԱÊýǧÈË¡£µ£ÈÎÊýÊ®¼ÒÖªÃûÆóÒµµÄÀͶ¯·¨¹ËÎÊ¡¢ÈËÁ¦×ÊÔ´¹ÜÀí¹ËÎÊ£¬ÔÚÆó
Òµ¹æÕÂÖƶȹÜÀí¡¢ÀͶ¯ºÏͬ¹ÜÀí¡¢Ô±¹¤Ìø²Û·À·¶¹ÜÀí¡¢ÉÌÒµÃØÃܱ£»¤¡¢Ô±¹¤Î¥¼Í´¦Àí¡¢²ÃÔ±¹ÜÀí¡¢
Óù¤³É±¾¿ØÖÆ¡¢¸ÄÖÆÖØ×é¡¢ÀͶ¯ÕùÒéÔ¤·À¼°Ó¦¶ÔµÈ·½Ãæ¾ßÓжÀÌصIJÅÄܺͷḻµÄ¾Ñé¡£
ÔøΪͨÓõçÆø¡¢ÃÀ¹úÇ¿Éú¡¢IBM¡¢¿ÂÄῨÃÀÄÜ´ï¡¢Èü¿ÆʯÓÍ¡¢°¢¶û˹ͨ¡¢±´¶û°¢¶û¿¨ÌØ¡¢¶Å
°î¡¢·ÉÀûÆÖµç×Ó¡¢ÁªÏë¡¢±¦¸Ö¡¢°¢µÏ´ï˹¡¢ÖйúÒøÁª¡¢Ó¢·ÉÁè¡¢ÂíÊ¿»ù¡¢Ê©Ä͵µçÆø¡¢¼ªÁС¢Á¢
°îÍ¿ÁÏ¡¢¸ðÀ¼ËØÊ·¿Ë¡¢Ã·ÌØÀÕ£ÍÐÀû¶à¡¢Ç÷ÊƿƼ¼¡¢°£ÉÕÜ×Éѯ¡¢°ÄÃÀÖÆÒ©¡¢¸»Ê¿Ê©ÀÖ¡¢±´Ëþ˹
Âü¡¢Ì«Æ½Ñó°²Ì©¡¢ÓÈÄáÉ¡¢¶«·½º½¿Õ¡¢Î¢´´Èí¼þ¡¢ÖÇÁªÕÐƸ¡¢ÖйúÈËÁ¦×ÊÔ´¿ª·¢Íø¡¢±±´ó¾ÀíÈË¡¢
»¨Íõ¡¢Ë¿±¦¡¢¾ùÑþ¡¢Íâ¸ßÇÅÔì´¬³§¡¢´ïÄÜ¡¢Ó¢Òµ´ï¡¢°×è¡¢Öõع㳡¡¢ÓÈÄݼѡ¢ÒÁÊ¿Âü¡¢°²ÉÃÀ¡¢
¼×¹ÇÎÄÈí¼þ¡¢½õÌì³ÇÂÉʦÊÂÎñËù¡¢´÷µÂÁºÐС¢¸´ÐǼ¯ÍÅ¡¢»ªÁ¢¼¯ÍÅ¡¢ÆæÈðÆû³µ¡¢ÃÀÊ©Íþ¶û¡¢µÏ±ÈÌØ¡¢
ÉϺ£»ÆÒ³¡¢±ÈÀûʱ¸»Í¨ÒøÐС¢ÎÞÎýÉеÂÌ«ÑôÄÜ¡¢½ÁåÆû³µ¡¢ÉϺ£Í⽨¡¢ÓÀÀּҵ硢¹úÃÀµçÆ÷¡¢Ì«Æ½
Ñó½¨É輯ÍÅ¡¢Ïð¹û¹ú¼Ê¡¢µÂ°î֤ȯ¡¢Ò׳õÁ«»¨¡¢ÓÑ°î±£ÏÕ¡¢ÖÐÍâÔ˶غÀµÈÊý°Ù¼Ò´óÐÍÆóÒµÌṩÀͶ¯
·¨ÓëÔ±¹¤¹Øϵ¹ÜÀí×Éѯ¡¢Åàѵ¡¢¹ËÎʵȷþÎñ¡£
Éó¤ºËÐĿγ̰üÀ¨¡¶ÈËÁ¦×ÊÔ´¹ÜÀíÖеķçÏÕ¿ØÖÆ¡·¡¢¡¶Ìø²ÛÔ±¹¤Óë´ÇÍËÔ±¹¤¹ÜÀí¼¼Çɼ°µäÐÍ°¸Àý
½âÎö¡·¡¢¡¶Ô±¹¤Êֲᡢ¹æÕÂÖƶÈÖƶ©ÓëÀͶ¯ÕùÒé·çÏÕ·À·¶¡·¡¢¡¶ÀͶ¯ºÏͬ¹ÜÀíʵս¾«Òª¡·¡¢¡¶¼Ó°à
·Ñ¼°Óù¤³É±¾¿ØÖƼ¼ÇÉ¡·¡¢¡¶ÆóÒµÉÌÒµÃØÃܱ£»¤·¨ÂÉʵÎñ²Ù×÷¡·¡¢¡¶¹¤ÉË·çÏÕ¿ØÖÆÓëת¼Þ·¨ÂÉʵÎñ¡·¡¢
¡¶¼¨Ð§¿¼ºËÓëн³êÉè¼ÆÖеķ¨ÂÉÎóÇø¼°Ó¦¶Ô¼¼ÇÉ¡·¡¢¡¶ÈçºÎÓÐЧӦ¶ÔÀͶ¯ÕùÒé¡·¡¢¡¶ÀÍÎñÅÉDzÓëÓÃ
¹¤·çÏÕ¿ØÖÆʵÎñ²Ù×÷¼¼ÇÉ¡·¡¢¡¶²¿ÃžÀíµÄÔ±¹¤¹Øϵ¹ÜÀí¡·¡¢¡¶ÒìµØÔ±¹¤¹Øϵ¹ÜÀí¼¼Çɼ°·¨ÂÉÄѵã
½âÎö¡·µÈ¡£
===============================================================================
¡ì¿Î--³Ì--´ó--¸Ù¡ì
Ò»¡¢¼¨Ð§¿¼ºË¡¢Ð½³ê¸£ÀûÓëÀͶ¯ÕùÒé
¼¨Ð§¿¼ºËÓëн³ê¸£ÀûµÄÕ½ÂÔ¶¨Î»
¼¨Ð§¿¼ºË¡¢Ð½³ê¸£ÀûµÄÀͶ¯ÕùÒé°¸Àý·ÖÎö
¶þ¡¢ÆóÒµ¼¨Ð§¿¼ºËÖжÔÀͶ¯·¨Âɵļ¼ÊõÐÔ´¦ÀíºÍÔËÓÃ
Òµ¼¨ÈÎÎñÖƶ¨Öеij£¼û·¨ÂÉÎóÇø
ÊÔÓÃÆÚÒµ¼¨ÈÎÎñÖƶ©ÓëÒµ¼¨¿¼ºË
¶Ô²»ÄÜʤÈι¤×÷Ô±¹¤µÄÈ϶¨Óë¹ÜÀí
¶ÔÔ±¹¤Ê§Ö°ÐÐΪµÄÈ϶¨Óë¹ÜÀí
ĩλÌÔÌÖƶȵÄÕýȷʹÓÃ
ÈçºÎ¸ù¾Ý¼¨Ð§¿¼ºË½á¹û¶ÔÔ±¹¤½øÐе÷¸Úµ÷н
ÈçºÎ¶ÔÔ±¹¤½øÐм¨Ð§¸Ä½øÅàѵ
¶Ô¼¨Ð§¿¼ºË²»ºÏ¸ñÔ±¹¤¡¢Ê§Ö°Ô±¹¤µÄ´ÇÍ˼¼ÇÉ
Èý¡¢Æóҵн³êÉè¼ÆÓëʵʩÖжÔÀͶ¯·¨Âɵļ¼ÊõÐÔ´¦ÀíºÍÀûÓÃ
¹¤×ʵĺÒåÓë±ê×¼
ÀͶ¯·¨ÂɶԹ¤×ÊÖ§¸¶µÄÌØÊâÒªÇóºÍÆóÒµ¹¤×ÊÖ§¸¶ÖƶÈÉè¼Æ
¹¤×Ê¿Û³ý¼¼ÇÉÓëÆóÒµÀͶ¯¼ÍÂÉÅäÌ×Éè¼Æ
ÊÔÓÃÆÚн³êÖ§¸¶³£¼ûÎóÇø
¼Ó°à¼Óµãн³êÖ§¸¶³£¼ûÎóÇø
²»Í¬µØÇø¶Ô¼Ó°à¡¢Ðݼٹ¤×ʼÆËãºÍÖ§¸¶µÄÌØÊâ¹æ¶¨
ÀëÖ°²¹³¥½ð¡¢Åâ³¥½ð¡¢Î¥Ô¼½ðÖ§¸¶³£¼ûÎóÇø
ÌØÊ⹤ʱϹ¤×ÊÖ§¸¶µÄ³£¼ûÎóÇø
Ò½ÁÆÆÚ¡¢²¡¼Ù¡¢¹¤ÉË¡¢Í£¹¤¡¢Ðݼٵȸ÷ÖÖÇéÐÎÏµĹ¤×ÊÖ§¸¶
ÏúÊÛÈËÔ±¹¤×Ê¡¢»õ¿î¹ÜÀíÖеij£¼ûÎóÇø
Ůְ¹¤ÈýÆÚÇéÐÎϵÄн×ʱ£»¤
ÄêÖÕ½±¡¢¼¾¶È½±¿¼ºËÓë·¢·Å³£¼ûÎóÇø
ËÄ¡¢ÆóÒµ¸£ÀûÖƶÈÖжÔÀͶ¯·¨Âɵļ¼ÊõÐÔ´¦ÀíºÍÀûÓÃ
ÌØÊ⸣Àû´ýÓöÉè¼Æ³£¼ûÎóÇø
Åàѵ·ÑµÄ¿ØÖƺͱ£»¤
ÅàѵÐÒéµÄÖÆ×÷
¼ÙÆÚ¸£Àû´ýÓöµÄ¿ØÖÆ
ס·¿¡¢Æû³µµÈÌØÊ⸣Àû´ýÓöµÄ¿ØÖƺͱ£»¤
Î塢н³êÕùÒéµÄ´¦Àí¼¼ÇÉ
н³êÕùÒé¹ÜϽȨѡÔñÓë´¦Àí
ÀͶ¯ÕùÒéÖÐÌØÓеÄн³êÖ¤¾ÝÖƶÈ
н³êÕùÒéʱЧÈ϶¨Óë´¦Àí¼¼ÇÉ
Áù¡¢ÒÉÄѽâ´ðÓ뾫²Ê»¥¶¯
11:36:08
===============================================================================
¡ö ¡ö ¡ö ±¨ Ãû »Ø Ö´ ¡ö ¡ö ¡ö
ÌîдÍê±ÏºóÇë´«Õæµ½£º0 7 5 5£8 3 1 6 6 7 0 1ÆäÓàµÄÊÂÇéÈ«²¿¾Í½»¸øÎÒÃÇÀ´×ö£¬Ð»Ð»£¡
²Î »á µ¥ λ Ãû ³Æ£º________________________________ ²Î »á ÈË Êý:_________ÈË
²Î ¼Ó ¿Î ³Ì £º¡¶ н ³ê ¸£ Àû ÖÆ ¶È Éè ¼Æ Óë ʵ Ê© ÖÐ µÄ ³£ ¼û ·¨ ÂÉ Îó Çø ¡·
Áª ϵ ÈË£º_____________µç »°:______________´« Õæ:______________ÓÊ ¼þ£º____________
²Î »á ·Ñ Óà £¤£º______________Ôª
²Î »á ÈË£º__________Ëù ÈÎ Ö° Îñ£º__________ÒÆ ¶¯ µç »°£º___________ÓÊ ¼þ£º__________
²Î »á ÈË£º__________Ëù ÈÎ Ö° Îñ£º__________ÒÆ ¶¯ µç »°£º___________ÓÊ ¼þ£º__________
²Î »á ÈË£º__________Ëù ÈÎ Ö° Îñ£º__________ÒÆ ¶¯ µç »°£º___________ÓÊ ¼þ£º__________
²Î »á ÈË£º__________Ëù ÈÎ Ö° Îñ£º__________ÒÆ ¶¯ µç »°£º___________ÓÊ ¼þ£º__________
²Î »á ÈË£º__________Ëù ÈÎ Ö° Îñ£º__________ÒÆ ¶¯ µç »°£º___________ÓÊ ¼þ£º__________
ÇëÄúÑ¡Ôñ²Î»áµØµã£º£¨ÇëÑ¡Ôñ´ò¡°¡Ì¡±£© ¡õ1¡¢ ÉÏ º£¡¡¡õ2¡¢ Éî ÛÚ
Ô¤¶©·þÎñÏîÄ¿£ºÊÇ·ñסËÞ£¨ÇëÑ¡Ôñ´ò¡°¡Ì¡±£©£º ¿ÚÊÇ ¿Ú·ñ
¸¶¿î·½Ê½£¨²»½ÓÊÜ֧Ʊ£©£º£¨ÇëÑ¡Ôñ´ò¡°¡Ì¡±£© ¡õ1¡¢ÏÖ ½ð ¡õ2¡¢×ª ÕÊ ¡õ3¡¢µç »ã
====================================
|
|
From: Mudiwa S. <nik...@li...> - 2006-08-06 18:39:53
|
Hi, =20 VzlAGRA from 3, 35 $ CzlALIS from 3, 75 $ VALzlUM from 1, 25 $ AMBzlEN =20 http://www.vukeradesacune.com =20 , , , , , other two guards necks. Squeezed as they turned their spears towards Floyd! I gasped out, putting all my energy into my throttle grips so these jokers would pass out before they harpooned me. The others! |
|
From: Mohd Y. S. <uno...@ya...> - 2006-08-03 13:57:19
|
Hi,
I try CGI::Session and i come up with the following test code. but why the session file is not deleted after it expires? E.g. I press submit, and wait. But the session file still there, and $session->is_expired never come true. Why? I run the Apache web server on Windows XP. Thanks in advance.
---------------------
#!c:/Perl/bin/perl -T
##
## Demo page for user login. If user login already expires, login again
##
use strict;
use CGI::Carp 'fatalsToBrowser'; # uncomment for debug!
use CGI ":std -tabindex";
use CGI::Cookie;
use CGI::Session;
use constant SESSION_DRIVER => "driver:file;serializer:storable";
use constant SESSION_LOCATION => "../tmp/session";
my %user = ( userid=>'' );
my $page = new CGI();
## Try to get the previous status (session)
##
my $session = CGI::Session->load(SESSION_DRIVER, $page, { Directory=>SESSION_LOCATION });
## If it's a submission...
##
if ($page->param() and $page->param('login')) {
## Create new status (session)
##
$session = new CGI::Session(SESSION_DRIVER, undef, { Directory=>SESSION_LOCATION });
$session->expire('+10s');
## save new session
##
$session->save_param($page, ['userid']);
$user{'userid'} = $page->param('userid');
print $session->header();
showInfo("'". $user{userid}. "' is just logged in " . $session->id());
## if session already expired...
} elsif ($session->is_expired()) {
printForm("<h1>Please re-login</h1>");
}elsif (!$session->is_empty()) {
## show who is staying...
##
$session->load_param($page, ['userid']);
$user{userid} = $page->param('userid');
print $session->header();
showInfo("Welcome again ". $user{userid}. "!");
} else {
## first timer...
##
printForm("<h1>Login Page</h1>");
}
###------------------
###------------------
sub showInfo
{
my $msg = shift;
print $page->start_html(),
$msg,
$page->end_html();
}
sub printForm
{
my $msg = shift;
print $page->header(),
$page->start_html(),
$msg,
$page->p,
$page->start_multipart_form(),
"User id : ",
$page->textfield(-name=>'userid',
-value=> '',
-size=>10,
-maxlength=>10),
$page->p,
$page->submit( -name=>'login',
-value=>'Login'),
$page->end_form();
$page->end_html();
}
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. |
|
From: Mark S. <ma...@su...> - 2006-08-01 01:27:06
|
dazjorz wrote:
> It probably requires the programmer to give a CGI::Session object as an
> argument, but I don't think it will tie the object itself.
That's OK with me. I'm CC'ing the users list so other users or
maintainers an provide opinions.
Mark
--
http://mark.stosberg.com/
|
|
From: Mark S. <ma...@su...> - 2006-08-01 01:12:28
|
dazjorz wrote: > Hello, > > I would like to make a Tie.pm <http://Tie.pm> in your CGI::Session > namespace. Is this okay? Does it involve tying a CGI::Session object? If so, it seems like reasonable name. Mark -- http://mark.stosberg.com/ |
|
From: Mark S. <ma...@su...> - 2006-07-31 03:44:52
|
Justin Simoni wrote: > Final followup, > > Dropping the session table and creating this one: > > CREATE TABLE sessions ( > id CHAR(32) NOT NULL PRIMARY KEY, > a_session TEXT NOT NULL > ); > > And running the Test::More test Mark made me create has it pass in every > case I noted, with or without either of those two lines commented - > looks like we're in good shape! Great, I patched the docs and committed that change to SVN. You got credit for your help bring it to our attention. Thanks! Mark |
|
From: Justin S. <ju...@sk...> - 2006-07-31 03:26:59
|
Final followup,
Dropping the session table and creating this one:
CREATE TABLE sessions (
id CHAR(32) NOT NULL PRIMARY KEY,
a_session TEXT NOT NULL
);
And running the Test::More test Mark made me create has it pass in
every case I noted, with or without either of those two lines
commented - looks like we're in good shape!
Testing the web app itself, I'm seeing similar positive results -
multiple copies of the session information are not being created -
one session entry per session - perfect.
Thanks for all the help, would never have figured that out :)
(Justin realizes the power of the Test::More test script, will file
in back of mind for later use...)
Justin Simoni
--
:: is an eccentric artist, living and working in Denver, Colorado
:: URL: http://justinsimoni.com
:: Mailing List - http://justinsimoni.com/mailing_list.html
On Jul 30, 2006, at 9:48 PM, Mark Stosberg wrote:
> Justin Simoni wrote:
>>> There's probably a bug here. Could you boil this down to a
>>> Test::More
>>> style test case? It looks like you are nearly there.
>> Done! Be gentle - this is my first real Test::More test - I know
>> these are supposed to be pretty simple, but setting up all the DBI
>> parameters seems a bit verbose, but I've attached it to this
>> message, as well as attempted to place it inline (notes to follow
>> code):
>
> Thanks Justin.
>
> I adapted this test for the SQLite driver... and it passed when it
> fails for MySQL. So that points to something MySQL-specific.
> Looking at the code for the MySQL driver, it does do something a
> little different. It use the non-standard "REPLACE INTO" function.
> It's documented here:
>
> http://sunsite.mff.cuni.cz/MIRRORS/ftp.mysql.com/doc/en/REPLACE.html
>
> Your test excluded creating the session table itself. Notice in the
> docs for REPLACE INTO where it says that if there is no UNIQUE or
> PRIMARY KEY constraint, then it will always INSERT, never update.
>
> That sounds a lot like your case. If that's the issue. we should
> add a big note to the MySQL driver about that.
>
> Mark
>
> --
> http://mark.stosberg.com/
>
>
|
|
From: Justin S. <ju...@sk...> - 2006-07-31 03:17:38
|
> Your test excluded creating the session table itself. Notice in the > docs for REPLACE INTO where it says that if there is no UNIQUE or > PRIMARY KEY constraint, then it will always INSERT, never update. Ah ha. Indeed, here is the table I've been using: CREATE TABLE sessions ( id CHAR(32) NOT NULL, a_session TEXT NOT NULL ); The docs do sort of complicate matters, as it's stated what the minimum table is for "most" SQL backends are here: http://search.cpan.org/~markstos/CGI-Session-4.14/lib/CGI/Session/ Driver/DBI.pm#STORAGE But, the docs specifically for MySQL: http://search.cpan.org/~markstos/CGI-Session-4.14/lib/CGI/Session/ Driver/mysql.pm Don't have any mention of how to create the table (so I have to guess?), but there are docs from the 3.x series: http://search.cpan.org/~sherzodr/CGI-Session-3.95/Session/MySQL.pm (which I found just searching on CPAN for, easy to forget to look at the version numbers) That do have directions for MySQL. Going through all that, I'm assuming the MySQL can use the generic table stated in the DBI.pm docs, and Postgres uses what is listed here: http://search.cpan.org/~markstos/CGI-Session-4.14/lib/CGI/Session/ Driver/postgresql.pm OK, I can apply that change to my docs as well :) Thanks for helping out with this; Justin Simoni -- :: is an eccentric artist, living and working in Denver, Colorado :: URL: http://justinsimoni.com :: PHO: 720.436.7701 :: Mailing List - http://justinsimoni.com/mailing_list.html On Jul 30, 2006, at 9:48 PM, Mark Stosberg wrote: > Justin Simoni wrote: >>> There's probably a bug here. Could you boil this down to a >>> Test::More >>> style test case? It looks like you are nearly there. >> Done! Be gentle - this is my first real Test::More test - I know >> these are supposed to be pretty simple, but setting up all the DBI >> parameters seems a bit verbose, but I've attached it to this >> message, as well as attempted to place it inline (notes to follow >> code): > > Thanks Justin. > > I adapted this test for the SQLite driver... and it passed when it > fails for MySQL. So that points to something MySQL-specific. > Looking at the code for the MySQL driver, it does do something a > little different. It use the non-standard "REPLACE INTO" function. > It's documented here: > > http://sunsite.mff.cuni.cz/MIRRORS/ftp.mysql.com/doc/en/REPLACE.html > > Your test excluded creating the session table itself. Notice in the > docs for REPLACE INTO where it says that if there is no UNIQUE or > PRIMARY KEY constraint, then it will always INSERT, never update. > > That sounds a lot like your case. If that's the issue. we should > add a big note to the MySQL driver about that. > > Mark > > -- > http://mark.stosberg.com/ > > |
|
From: Mark S. <ma...@su...> - 2006-07-31 02:52:20
|
Justin Simoni wrote: >> There's probably a bug here. Could you boil this down to a Test::More >> style test case? It looks like you are nearly there. > > Done! Be gentle - this is my first real Test::More test - I know these > are supposed to be pretty simple, but setting up all the DBI parameters > seems a bit verbose, but I've attached it to this message, as well as > attempted to place it inline (notes to follow code): Thanks Justin. I adapted this test for the SQLite driver... and it passed when it fails for MySQL. So that points to something MySQL-specific. Looking at the code for the MySQL driver, it does do something a little different. It use the non-standard "REPLACE INTO" function. It's documented here: http://sunsite.mff.cuni.cz/MIRRORS/ftp.mysql.com/doc/en/REPLACE.html Your test excluded creating the session table itself. Notice in the docs for REPLACE INTO where it says that if there is no UNIQUE or PRIMARY KEY constraint, then it will always INSERT, never update. That sounds a lot like your case. If that's the issue. we should add a big note to the MySQL driver about that. Mark -- http://mark.stosberg.com/ |
|
From: Justin S. <ju...@sk...> - 2006-07-30 23:41:49
|
> There's probably a bug here. Could you boil this down to a Test::More
> style test case? It looks like you are nearly there.
Done! Be gentle - this is my first real Test::More test - I know
these are supposed to be pretty simple, but setting up all the DBI
parameters seems a bit verbose, but I've attached it to this message,
as well as attempted to place it inline (notes to follow code):
[snip]
#!/usr/bin/perl
use Test::More tests => 4;
use CGI::Session;
use DBI;
# SQL Paramaters - obviously, these will be different from you...
my %sql_params = (
database => 'database',
dbserver => 'localhost', # may just be, "localhost"
port => '3306', # mysql: 3306, Postgres: 5432
dbtype => 'mysql', # 'mysql' for 'MySQL', 'Pg' for
'PostgreSQL'
user => 'user',
pass => 'pass',
session_table => 'sessions',
);
# Let's get a db handle...
my $dbh = connectdb(
$sql_params{dbtype},
$sql_params{database},
$sql_params{dbserver},
$sql_params{3306},
$sql_params{user},
$sql_params{pass},
);
# Some CGI::Session params...
my $dsn = 'driver:mysql';
my $dsn_args = {
Handle => $dbh,
TableName => $sql_params{session_table},
};
# Let's start with a clean slate...
$dbh->do("DELETE FROM " . $sql_params{session_table});
# Build us a session object...
my $session = new CGI::Session($dsn, undef, $dsn_args);
$session->param('foo', 'bar');
$session->expire('+1d');
$session->flush();
# Check the integrity of our saved information....
ok($session->param('foo') eq 'bar', "Correct information has been
saved in the session...");
# Save this for later, so we can recall the info...
my $session_id = $session->id;
# Hey, let's see how many rows we have...
my $sth = $dbh->prepare("SELECT COUNT(*) FROM " . $sql_params
{session_table} );
$sth->execute();
# (Hopefully) we only have one session...
ok($sth->fetchrow_array() == 1, "Only one copy of the session file...");
# In the app itself, the Session is checked upon a refresh to a new
screen...
# So let's get rid of what we have, and do it again...
undef $session;
undef $dbh; # just being thorough.
# Our new DB handle...
# There's no persistance in the CGI app...
my $dbh2 = connectdb(
$sql_params{dbtype},
$sql_params{database},
$sql_params{dbserver},
$sql_params{3306},
$sql_params{user},
$sql_params{pass},
);
# And again..
my $dsn2_args = {
Handle => $dbh2,
TableName => $sql_params{session_table},
};
# New Session! Should call up the same information...
my $session2 = CGI::Session->load($dsn, $session_id, $dsn2_args);
# Check the integrity of our saved information....
ok($session2->param('foo') eq 'bar', "Information is retrieved from
past session alright...");
# NOTE: UNCOMMENTING EITHER OF THESE TWO LINES WILL CAUSE THE NEXT
TEST TO FAIL
# $session2->flush;
# undef $session2;
# ???
# How many do we have?!
my $sth2 = $dbh2->prepare("SELECT COUNT(*) FROM " . $sql_params
{session_table} );
$sth2->execute();
# One? Two?
ok($sth2->fetchrow_array() == 1, "Still only one copy of the
session...");
# This is to double check out handy work:
#
print "\n\nLet's see what's in the table:\n" . '-' x 72 . "\n";
my $sth3 = $dbh2->prepare("SELECT * FROM " . $sql_params
{session_table} );
$sth3->execute();
$sth3->dump_results(2048);
[/snip]
NOTES:
I tried to emulate how things are running in the (I admit, complex)
web app - does a good job.
In the web app, upon login, a session is created, and set in a cookie.
The person will receive the cookie and the page will refresh to the
administration side of things
- that's why there's the creation of a new session (and db handle, etc).
Plop in your own DB credentials, obviously.
All the above tests (4) PASS - until you uncomment one of the two lines:
Either:
# $session2->flush;
or:
# undef $session2;
For whatever reason, this will write a second, similar session into
the table, with the same session id and same parameters saved. And
that's leading to some problems. I've only tested this on a server
running mysql, but it doesn't (without testing) seem to be a problem
with Postgres which is a little mysterious. Here's the output if you
uncomment one of the above lines:
me@there [~/where/we/are]# perl dup_sess.pl
1..4
ok 1 - Correct information has been saved in the session...
ok 2 - Only one copy of the session file...
ok 3 - Information is retrieved from past session alright...
not ok 4 - Still only one copy of the session...
# Failed test (dup_sess.pl at line 123)
Let's see what's in the table:
------------------------------------------------------------------------
'c211b11dc99e01c9f5685fd39391d6eb', '$D = {'_SESSION_ETIME' =>
86400,'_SESSION_ID' =>
'c211b11dc99e01c9f5685fd39391d6eb','_SESSION_ATIME' =>
1154302807,'foo' => 'bar','_SESSION_REMOTE_ADDR' =>
'','_SESSION_CTIME' => 1154302807};;$D'
'c211b11dc99e01c9f5685fd39391d6eb', '$D = {'_SESSION_ID' =>
'c211b11dc99e01c9f5685fd39391d6eb','_SESSION_ETIME' =>
86400,'_SESSION_ATIME' => 1154302807,'foo' =>
'bar','_SESSION_EXPIRE_LIST' => {},'_SESSION_REMOTE_ADDR' =>
'','_SESSION_CTIME' => 1154302807};;$D'
2 rows
# Looks like you failed 1 test of 4.
me@there [~/where/we/are]#
Thanks Mark for showing me how to whip up Test's :)
Justin Simoni
--
:: is an eccentric artist, living and working in Denver, Colorado
:: URL: http://justinsimoni.com
:: PHO: 720.436.7701
:: Mailing List - http://justinsimoni.com/mailing_list.html
|
|
From: Justin S. <ju...@sk...> - 2006-07-30 22:32:54
|
> There's probably a bug here. Could you boil this down to a Test::More
> style test case
See what I can do ;)
A good exercise anyways, since sometimes doing just that makes you
realize some other complication in the code.
Justin
On Jul 29, 2006, at 9:29 PM, Mark Stosberg wrote:
>>
>> I could probably also use load? which wouldn't create a new
>> session, and
>> then just try use the, is_empty() method.
>>
>> I'm still having trouble with accessing a session already created,
>> something simple as:
>>
>> require CGI::Session;
>> CGI::Session->name($LOGIN_COOKIE_NAME);
>> $session = CGI::Session->load($self->{dsn}, $q,
>> $self->{dsn_args});
>
>
> There's probably a bug here. Could you boil this down to a Test::More
> style test case? It looks like you are nearly there.
>
> Looking at the docs for load(), it says:
>
> Constructor. Usage is identical to new(), so is the return
> value. Major
> difference is, new() can create new session if it detects
> expired and
> non-existing sessions, but load() does not.
>
> load() is useful to detect expired or non-existing sessions without
> forcing the
> library to create new sessions.
>
> This contains an apparent contradiction, because it says the return
> value is the same as new(), but new() returns newly created sessions.
> That conflicts with the next paragraph that says it doesn't create
> a new
> session.
>
> Looking at the code, load() /does/ have the ability to return new,
> empty
> sessions, which seems wrong. Do others agree? "new()" is already
> magical that way. It doesn't seem that we need "load" to mean
> "load_or_new" as well.
>
>> Will not just read the already created session, it'll create a new
>> session, with the exact same session id and exact same information
>> inside the a_session column.
>
> You mean, it's cloning the session of loading it, resulting in
> duplicate
> entries in the database? That seems weird.
>
> Mark
>
> ----------------------------------------------------------------------
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys -- and earn
> cash
> http://www.techsay.com/default.php?
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>
|
|
From: Sherzod R. <she...@ha...> - 2006-07-30 03:39:39
|
Mark,
Right before I was coding load() I had a need for such functionality,
although no matter how hard I try to remember, I can't recall what =
exactly
created that need. But since then I wrote lots of code, and not even =
once
remember having to use load(). So, I'm not exactly sure what the purpose =
of
load() is, except adding to the complexity of the already complex code.
Usually in an application there really is no need for checking for the
existence of the actual session. It's too low level to be even concerned
about. Application should create a session at request, and check for
existence of certain session parameters. At least that's how I do it =
these
days.
Notifying the users about their expired sessions is also something not =
quite
necessary. Displaying the login screen conveys the same message, and =
also,
provides with an option to re-create a new login session, which in turn
saves bandwidth, and at least couple lines of code, if not more.
Sherzod
> -----Original Message-----
> From: cgi...@li...=20
> [mailto:cgi...@li...] On=20
> Behalf Of Mark Stosberg
> Sent: Saturday, July 29, 2006 11:30 PM
> To: Justin Simoni
> Cc: List - CGI-Session
> Subject: Re: [Cgi-session-user] how load works (was: MySQL=20
> backend - multiple copies of session id's stored?)
>=20
>=20
> >
> > I could probably also use load? which wouldn't create a=20
> new session, and
> > then just try use the, is_empty() method.
> >
> > I'm still having trouble with accessing a session already created,
> > something simple as:
> >
> > require CGI::Session;
> > CGI::Session->name($LOGIN_COOKIE_NAME);
> > $session =3D CGI::Session->load($self->{dsn}, $q,
> > $self->{dsn_args});
>=20
>=20
> There's probably a bug here. Could you boil this down to a Test::More
> style test case? It looks like you are nearly there.
>=20
> Looking at the docs for load(), it says:
>=20
> Constructor. Usage is identical to new(), so is the return=20
> value. Major
> difference is, new() can create new session if it detects=20
> expired and
> non-existing sessions, but load() does not.
>=20
> load() is useful to detect expired or non-existing=20
> sessions without=20
> forcing the
> library to create new sessions.
>=20
> This contains an apparent contradiction, because it says the return
> value is the same as new(), but new() returns newly created sessions.
> That conflicts with the next paragraph that says it doesn't=20
> create a new
> session.
>=20
> Looking at the code, load() /does/ have the ability to return=20
> new, empty
> sessions, which seems wrong. Do others agree? "new()" is already
> magical that way. It doesn't seem that we need "load" to mean
> "load_or_new" as well.
>=20
> > Will not just read the already created session, it'll create a new
> > session, with the exact same session id and exact same information
> > inside the a_session column.
>=20
> You mean, it's cloning the session of loading it, resulting=20
> in duplicate
> entries in the database? That seems weird.
>=20
> Mark
>=20
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the=20
> chance to share your
> opinions on IT & business topics through brief surveys -- and=20
> earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge
&CID=3DDEVDEV
_______________________________________________
Cgi-session-user mailing list
Cgi...@li...
https://lists.sourceforge.net/lists/listinfo/cgi-session-user
|
|
From: Mark S. <ma...@su...> - 2006-07-30 02:33:17
|
>
> I could probably also use load? which wouldn't create a new session, and
> then just try use the, is_empty() method.
>
> I'm still having trouble with accessing a session already created,
> something simple as:
>
> require CGI::Session;
> CGI::Session->name($LOGIN_COOKIE_NAME);
> $session = CGI::Session->load($self->{dsn}, $q,
> $self->{dsn_args});
There's probably a bug here. Could you boil this down to a Test::More
style test case? It looks like you are nearly there.
Looking at the docs for load(), it says:
Constructor. Usage is identical to new(), so is the return value. Major
difference is, new() can create new session if it detects expired and
non-existing sessions, but load() does not.
load() is useful to detect expired or non-existing sessions without
forcing the
library to create new sessions.
This contains an apparent contradiction, because it says the return
value is the same as new(), but new() returns newly created sessions.
That conflicts with the next paragraph that says it doesn't create a new
session.
Looking at the code, load() /does/ have the ability to return new, empty
sessions, which seems wrong. Do others agree? "new()" is already
magical that way. It doesn't seem that we need "load" to mean
"load_or_new" as well.
> Will not just read the already created session, it'll create a new
> session, with the exact same session id and exact same information
> inside the a_session column.
You mean, it's cloning the session of loading it, resulting in duplicate
entries in the database? That seems weird.
Mark
|
|
From: Justin S. <ju...@sk...> - 2006-07-29 23:54:04
|
Here's an update:
There's been a few problems in my code - the first was with login of
my webapp - before login would even take place, the app makes sure
you're not logged in, with a different set of credentials (basically,
if you're logged in as one user, it won't let you log in as a
different user, until you log out)
The way it did this was to look at the saved session information and
make sure everything matches - fine and dandy, but if there is no
saved session information, CGI::Session will make it. Many ways to
fix this, I just see if the person logged in, isn't logged in as a
different user, that current session is deleted.
I could probably also use load? which wouldn't create a new session,
and then just try use the, is_empty() method.
I'm still having trouble with accessing a session already created,
something simple as:
require CGI::Session;
CGI::Session->name($LOGIN_COOKIE_NAME);
$session = CGI::Session->load($self->{dsn}, $q, $self->
{dsn_args});
Will not just read the already created session, it'll create a new
session, with the exact same session id and exact same information
inside the a_session column.
This snippet of code happens every time the session information is
checked - basically everytime you bring a new screen up in the webapp
and that's one way of how the session tables starts to get a little
full (not THOUSANDS as my bug poster put it, but still)
Any reason for this to happen?
Justin
On Jul 29, 2006, at 8:08 AM, Mark Stosberg wrote:
> Justin Simoni wrote:
>> Hey everyone,
>> before I delve any further into a problem I'm having,
>> Is it normal for the MySQL backend to store multiple copies of
>> the session in a MySQL backend?
>
> No. But read the source of the MySQL driver module to confirm for
> yourself. It's rather simple.
>
>> I've had some bug reports:
>> http://sourceforge.net/tracker/index.php?
>> func=detail&aid=1525557&group_id=13002&atid=113002
>
> The bug report clarifies something. It's not /duplicate/ sessions
> are being saved, but rather, lots of new, different sessions. That
> sounds like it might be an application error. Review the calls to
> CGI::Session->new(). Add debugging statements near there and try
> again.
> That should clarify who is at fault.
>
> Remember that's fine for the same session to be used before and
> after someone logs in. The difference might be the presence of
> "logged_in => 1" in the session.
>
> (And random suggestion: The YAML serializer creates output that is
> a lot nicer to look it for debugging than the default one. )
>
>> Given the advice of the docs and this list, every change done to
>> the sessions - adding/editing/removing is followed by a ->flush
>> method call. I'm willing to make a test up that I'll try running,
>> but first wanted to see if this is behavior is actually wrong.
>
> I think flush() just means "synchronize memory with disk". So this
> design is OK. In theory, doing it once at the end of the request
> cycle would be sufficient, or just before you need to run a DB
> query that depends on the flushed state()
>
>> My program is of course, pretty meaty,
>
> I like to think of it a "pretty tofuey" or just "high in protein".
>
> Mark
>
> --
> http://mark.stosberg.com/
>
>
|
|
From: Mark S. <ma...@su...> - 2006-07-29 13:12:03
|
Justin Simoni wrote: > Hey everyone, > > before I delve any further into a problem I'm having, > > Is it normal for the MySQL backend to store multiple copies of the > session in a MySQL backend? No. But read the source of the MySQL driver module to confirm for yourself. It's rather simple. > I've had some bug reports: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1525557&group_id=13002&atid=113002 The bug report clarifies something. It's not /duplicate/ sessions are being saved, but rather, lots of new, different sessions. That sounds like it might be an application error. Review the calls to CGI::Session->new(). Add debugging statements near there and try again. That should clarify who is at fault. Remember that's fine for the same session to be used before and after someone logs in. The difference might be the presence of "logged_in => 1" in the session. (And random suggestion: The YAML serializer creates output that is a lot nicer to look it for debugging than the default one. ) > Given the advice of the docs and this list, every change done to the > sessions - adding/editing/removing is followed by a ->flush method > call. I'm willing to make a test up that I'll try running, but first > wanted to see if this is behavior is actually wrong. I think flush() just means "synchronize memory with disk". So this design is OK. In theory, doing it once at the end of the request cycle would be sufficient, or just before you need to run a DB query that depends on the flushed state() > My program is of course, pretty meaty, I like to think of it a "pretty tofuey" or just "high in protein". Mark -- http://mark.stosberg.com/ |
|
From: Justin S. <ju...@sk...> - 2006-07-28 22:41:44
|
Hey everyone, before I delve any further into a problem I'm having, Is it normal for the MySQL backend to store multiple copies of the session in a MySQL backend? The other backends I've tried - file, Db, Postgres, don't seem to have this behavior - I'm guessing this is because, the file backend has the name of the session_id as its filename, so any multiples get re-written - same goes for the Berkeley DB backend - keys (I think) in a tied hash have to be unique, or you'll overwrite your information already saved. No clue on Postgres ;) I've had some bug reports: http://sourceforge.net/tracker/index.php? func=detail&aid=1525557&group_id=13002&atid=113002 that, for some reason, the more sessions that are saved, the more multiples of the next session created are made, perhaps in an almost Fibonacci growth :) It gets to the point that many thousands of entries are made for the same session, slowing things right down. Before I blame CGI::Session, I was wondering if any specific behavior of my program may be at fault to create such a scenario. Given the advice of the docs and this list, every change done to the sessions - adding/editing/removing is followed by a ->flush method call. I'm willing to make a test up that I'll try running, but first wanted to see if this is behavior is actually wrong. My program is of course, pretty meaty, so making a simplified version of what's going on, may be a little bit of a chore (that I am willing to do). Justin Simoni -- :: is an eccentric artist, living and working in Denver, Colorado :: URL: http://justinsimoni.com :: Mailing List - http://justinsimoni.com/mailing_list.html ps: Sherzod - moved to the CGI::Session::ExpireSessions for my other problem - thanks! |
|
From: Mark S. <ma...@su...> - 2006-07-23 13:39:28
|
Sergey Brutsky wrote:
> Hi, Mark.
> I've run your tests.
> The results is
> ok 1 - session starts out undef
> ok 2 - session is true after getInstance
> not ok 3 - multiple call to getInstance return the same session ID 1..3
Thanks running the test. What CGI::Session version are you using? I used
4.13. Please upgrade to the latest version if you are using an older
version.
> My SessionSingleton always returns session object with status 1, it
> never reaches status 2.
> To use CGI::Application::Plugin::Session I have to create separate
> package, but I wouldn't like it.
> I just want to use SessionSingleton in simple script (not in package).
Using a simple script with a custom singleton has taken days to debug.
CGI::Application and CGI::Application::Plugin::Session can be used in a
script, it just not recommended.
You can declare the package at the top of the script:
package My::CGIApp::Subclass;
use base 'CGI::Application';
use CGI::Application::Plugin::Session;
and at the bottom:
My::CGIApp::Subclass->new->run();
#####
However, considering our different test results, but the problem now
doesn't appear to be with the code, but something in the environment,
like your CGI::Session version.
Mark
|
142 messages has been excluded from this view by a project administrator.
