[Zope-dev] CoreSessionTracking onStart
Hi, I am trying to use the onStart method of a session data manager But I do not get how to give the path so that my method get called... I could not find any information of the real way to use it. Can someone help me ? Thanks -- Godefroid Chapelle BubbleNet sprl rue Victor Horta, 30 1348 Louvain-la-Neuve Belgium Tel + 32 (10) 457490 Mob + 32 (477) 363942 TVA 467 093 008 RC Niv 49849 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
dtml-let data=SESSION.getSessionData()
manage=REQUEST.get('manage_content') or
data.get('manage_content')
dtml-unless manage
dtml-call data.set('manage_content','NO')
/dtml-unless
dtml-in data.keys()
dtml-let si=sequence-item
dtml-call REQUEST.set(si, data[si])
/dtml-let
/dtml-in
/dtml-let
This will work for the manage_content, but I want to make the whole
request persistent. E.g., box states, search filters, and sequence-start
variables for batching are all made persistent ...
I'm also confused why you're using YES and NO to represent a boolean
instead of just checking that a key exists or is true.
Just consider it a bad habit ;-) -- I had some trouble working with booleans
some time ago, so I switched to this more explicit version.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
To further try to track this problem down, I've developed a burger, fries, coke application in honor of this thread. So far, I've eaten 84 burgers, 31 cokes, and 42 fries. I can't seem to break this thing, and I'm not hungry anymore. :-( I just wanted to throw this out there. I'm certain this isn't the problem because it's too simple, but just in case... How many session data managers do you (Howard, Michael, Joachim, and.. I forget who else is having problems) have? Just one, I assume. It's not possible that different DTML pages in your application call out to *different* session data managers, is it? Maybe via unanticipated acquisition? I know the answer is probably no, but I need to ask, because the symptoms are consistent with this kind of misconfiguration. Questions (assuming the previous question was a throwaway): Is there something in the standard_html_header that sets request variables out of session data? Or is this done via an access rule? Or is the session data logic just embedded within every page? Is everybody using cookies? Is everybody using the RAM-based session data container? How long is the data container timeout? Is this too many questions already? ;-) stuffed-ly y'rs, - C Chris McDonough wrote: Chris McDonough wrote: I just wrote a test case that emulates many visitors firing off sessions and making changes to shared data objects simultaneously. It even emulates aborted connections. Unfortunately, I see nothing out of the ordinary. :-( This is very frustrating. Maybe the problem folks are experiencing with CST are related to the None has no attribute 'load' bug that pops up every so often using a mounted storage (RAM-based session data containers use a mounted storage internally). If there's any chance that you can turn the STUPID_LOG_FILE on, if the problem happens while you're using the site, it would be helpful to be able to correlate (or not correlate) the problems folks are having with any messages in the error log. -C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Matt Hamilton wrote: Just to add myself to the list, I too am having problems with CoreSessionTracking :( I am trying to find a test case for the problem, but I really can't replicate it. It first I thought it was a cookie issue, but I am now noting down the session id generated and it stays the same even when my session data is lost, so I don't think it is that. what I experience: I add an item to my shopping cart system and it shows up fine, all state is maintained. If I however leave the page and not touch anything for a couple of minutes and then reload the page, the cart is now empty. I know this is not that helpful, but I'm trying to tie it down myself! Bummer. How long is the session data container timeout set for? Are you sure you're just not exceeding the timeout? One thing that I do need to check though -- I am right in assuming I can insert complex objects into the SessionData right? I have an 'Order' class that amongst other things has a dict containing instances of a 'Product' class. The Order instance is stored in the SessionData. As I said it appears to work fine and I can add and delete items from my Order fine. Just it randomly looses it now and then. Yes, any sort of object can go into session data... there are some caveats documented in the helpfile (for instance, acquisition-wrapped objects shouldn't be stored in session data), but otherwise anything's game. - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
On Fri, 25 May 2001, Chris McDonough wrote: Bummer. How long is the session data container timeout set for? Are you sure you're just not exceeding the timeout? The session timeout is 120 minutes. I am using an external SessionDataComainter stored in the normal undo-able ZODB (I'm not expecting that much traffic to it). Looking into it further I don't think it is a CST fault :) I think I have fixed the problem. It was me not setting _p_changed on an object with a dict after adding items to the dict. Hence the session wasn't being lost, just the conents of the cart itself were not very persistent :) I'll be able to confirm this later today. Yes, any sort of object can go into session data... there are some caveats documented in the helpfile (for instance, acquisition-wrapped objects shouldn't be stored in session data), but otherwise anything's game. I can't find anything about acquisition-wrapped objects in the helpfile, what is the problem with them? -Matt -- Matt Hamilton [EMAIL PROTECTED] Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Hosting | Web Design | Domain Names | Co-location | DB Integration ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Matt Hamilton wrote: Looking into it further I don't think it is a CST fault :) I think I have fixed the problem. It was me not setting _p_changed on an object with a dict after adding items to the dict. Hence the session wasn't being lost, just the conents of the cart itself were not very persistent :) Gotcha... (I can't tell you how many times I've done that ;-) Yes, any sort of object can go into session data... there are some caveats documented in the helpfile (for instance, acquisition-wrapped objects shouldn't be stored in session data), but otherwise anything's game. I can't find anything about acquisition-wrapped objects in the helpfile, what is the problem with them? Eek, you're right. This is a funny situation. I had thought I had documented this. But first I need to figure out what to document. Maybe that's why I didn't. The ZODB in general does not like to store acquisition-wrapped objects. It's usually the case in CST that you're prevented from doing this by the fact that you're generally using a mounted storage, and acqusition-wrapped objects in the context of Zope usually contain object references from the main storage (raising the InvalidObjectReference error documented in the helpfile). However, in cases like yours, where you're using a session data container that's *in* the main storage, you'll get past that hurdle (because your objects can't/don't contain references to another database). But you *should* be prevented from storing acqusition-wrapped objects in any database because it doesn't make sense to preserve an acqusition wrapper anywhere, they're completely ephemeral. But of course I just tried it, and it didn't raise any error. ;-) Hee hee. This means one of two things: 1. ZODB was fixed at some point to unwrap acquisition-wrapped objects before putting them in storage. This is likely. I dimly remember something like this happening, although I can't find it documented in any HISTORY or CHANGES files (not altogether surprising). 2. ZODB is blithely storing acquistion wrappers. If the answer is 1, everything's fine, and ignore my claim about not being able to pass acquisition-wrapped objects into session storage. Know that if you move to a mounted database in the future, and your code passes in objects pulled out of main Zope storage to session storage, that code will likely break. If the answer is 2, everything's not so fine. I'll likely need to change the CST code to unwrap acquisition-wrapped objects before storing them, just to head potential problems off at the pass. I just did a preliminary test, and it appears that it *is* storing acquisition-wrapped objects. This is bad if it's true. :-( In the meantime, to be safe, before you store an object in session storage, unwrap it by getting its aq_base, e.g.: ob = getattr(ob, 'aq_base', on) or use the utility function aq_base from Acquistion to safely do the same: from Acquisition import aq_base ob = aq_base(ob) Ah the bugs keep on piling on over here, - C -Matt -- Matt Hamilton [EMAIL PROTECTED] Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Hosting | Web Design | Domain Names | Co-location | DB Integration ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Chris McDonough wrote: If the answer is 2, everything's not so fine. I'll likely need to change the CST code to unwrap acquisition-wrapped objects before storing them, just to head potential problems off at the pass. I just did a preliminary test, and it appears that it *is* storing acquisition-wrapped objects. This is bad if it's true. :-( Note that I just changed CST to unwrap aq-wrapped objects just in case, because what little testing I've been able to do says that aquisition wrappers are being stored in ZODB. I'm sure someone's going to come along and tell me that's the dumbest thing they've ever heard, but the changes don't hurt anything if I'm wrong. The requisite changes to the SessionData class (in the SessionData.py module) are: from: def __setitem__(self, k, v): # if the key or value is a persistent instance, # set up its _p_jar immediately if hasattr(v, '_p_jar') and v._p_jar is None: v._p_jar = self._p_jar v._p_changed = 1 if hasattr(k, '_p_jar') and k._p_jar is None: k._p_jar = self._p_jar k._p_changed = 1 self._container[k] = v self._p_changed = 1 to: def __setitem__(self, k, v): # if the key or value is a persistent instance, # set up its _p_jar immediately if hasattr(v, '_p_jar') and v._p_jar is None: v._p_jar = self._p_jar v._p_changed = 1 if hasattr(k, '_p_jar') and k._p_jar is None: k._p_jar = self._p_jar k._p_changed = 1 # unwrap this thing if it's wrapped from Acquisition import aq_base k = aq_base(k) v = aq_base(v) self._container[k] = v self._p_changed = 1 weeping (although grateful for the exchange), - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Chris McDonough wrote: To further try to track this problem down, I've developed a burger, fries, coke application in honor of this thread. So far, I've eaten 84 burgers, 31 cokes, and 42 fries. I can't seem to break this thing, and I'm not hungry anymore. :-( Sorry, but I had to :-) http://www.zopezen.org/Zope/Quotes *grinz* Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Chris McDonough wrote: Note that I just changed CST to unwrap aq-wrapped objects just in case, I always wondered why Squishdot did this, now I know :-) cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Chris McDonough:
[...]
weeping (although grateful for the exchange),
I'm sorry Chris. We didn't give you a very good debugging chase. I
know how frustrating bug reports like Help! It doesn't work is, but I
guess it's very hard to troubleshoot bugs in frameworks since there's so
much customized code in there.
To be a little bit more helpful I've included two functions:
cart_add(sku, qty) (Python Script)
This function adds qty amount of a skus (integer id for product
items) to the cart
cart_display (DTML Method)
This method displayes the cart
The bug appears even when these two functions are the only functions
interacting with the session and the shopping. There are obviously some
references to code not provided in there, so don't expect them to work
just like that. If you can't see anything wrong from a simple code
inspection, I volounteer to provide the whole site for you.
It's quite refreshing to do a project for a sandwich shop, like we do
now, but I hope we can get to the bottom of these disappearing cokes. :)
Thank you for all the help. Open source sure beats the heck out of
commercial solutions when it comes to support.
Bye,
--
Bjorn Stabell [EMAIL PROTECTED]
cart_add(sku, qty)
___
session = context.session_mgr.getSessionData()
cart = session.get('shopping_cart', {})
sku = int(sku)
if not cart.has_key(sku):
cart[sku] = 0
if int(qty)0:
cart[sku] = cart[sku] + int(qty)
session.set('shopping_cart', cart)
container.cart_recalculate()
context.REQUEST.RESPONSE.redirect(context.REQUEST['HTTP_REFERER'])
cart_show()
___
dtml-call REQUEST.set('totalprice',0)
dtml-comment
Session token key, value: dtml-var session_mgr.getTokenKey(),
dtml-var session_mgr.getToken()br
/dtml-comment
dtml-let cart=session_mgr.getSessionData().get('shopping_cart', {})
dtml-if cart.keys()
dtml-in cart.keys() sort
dtml-if sequence-start
table border=0 cellspacing=0 cellpadding=0 width=100%
tr
td bgcolor=#FFDAAB
form action=cart_change method=post
table width=100% border=0 cellspacing=1 cellpadding=2
align=center
tr
td colspan=2 bgcolor=#006633 class=pagetitledtml-var
gettext('Order Bag')/td
/tr
tr
tddtml-var gettext('Category')/td
td align=right width=20%dtml-var gettext('Qty')/td
/tr
/dtml-if sequence-start
dtml-let shop_item=get_shop_item(_['sequence-item'])
tr valign=top
td bgcolor=#FF
!--dtml-var shop_item.Description()--
dtml-var shop_item.Title()
a href=cart_rm?sku=dtml-sequence-item;dtml-var
gettext('remove')/a
dtml-comment
!--dtml-var shop_item.absolute_url() html_quote--
a href=cart_rm?sku=dtml-sequence-item;remove/a
!--dtml-var shop_item.price
/dtml-comment
dtml-let qty=_.int(cart[_['sequence-item']])
dtml-call REQUEST.set('totalprice', totalprice + shop_item.price *
qty)
/td
td nowrap bgcolor=#FFinput type=hidden name=skus:list
value=dtml-sequence-item;
input type=text name=sku_dtml-sequence-item;:int
value=dtml-var cart[_['sequence-item']] size=1
/td
/dtml-let
/dtml-let
/tr
dtml-if sequence-end
tr valign=top
td colspan=2 align=right class=RMB
bgcolor=#CCdtml-var gettext('TOTAL')
dtml-var
_.int(session_mgr.getSessionData().get('shopping_cart_amount', 0))
/td
/tr
tr valign=top
td colspan=2 bgcolor=#FF
bdtml-var gettext('Bonus points')/b br
dtml-var gettext('This order is worth') dtml-var
_.int(session_mgr.getSessionData().get('shopping_cart_bonus', 0))
br
dtml-unless portal_membership.isAnonymousUser()
dtml-var gettext('Bonus points to spend')
dtml-var _.int(member.bonus_points)
/dtml-unless
/td
/tr
tr valign=top
td colspan=2 bgcolor=#FF
input type=submit name=Submit value=dtml-var
gettext('update')
a href=orderFormdtml-var gettext('Checkout')/a /td
/tr
/table
/td
/tr
/table/dtml-if sequence-end
dtml-else
Empty
/dtml-in
/form
/dtml-if
/dtml-let
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Brought to you live: The Bug (RE: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8))
By the way, Chris, you can see the bug in action at our site by going to: http://www.beijingsammies.com:7380/sammies/ The website has not been launched yet, so be careful guys. Also, don't try ordering, unless you're in Chaoyang district, Beijing, China. :) The site may be slow since it's hosted in China. Try adding some items to the shopping cart, and then clicking on the navigation menu, browsing the various brochureware pages (only cart_show is called; no modification is done). At some point, the shopping cart should suddenly disappear. If you continue browsing, it may appear again. Actually, if you add items to the shopping cart while it is disappeared/empty, they'll get accepted and you'll have two different shopping carts. Which one you see is random. The session objects are set up like this: /session_id_mgr (session id manager) /sammies/session_mgr(session data manager) There are no other session id or data managers. The session data manager is using the default internal RAM-based session data container with no onStart or onEnd methods. Here's the test run I just did: - I added a few items to the shopping cart - Then I clicked on different brochureware pages for about one hundred clicks (2 minutes? a trial in patience :) I managed to get the error: - The shopping cart became emptied - Checking the session data manager, it still showed one item/session - I added more items to the new, blank session - After about 30-40 clicks, it changed into the old session again I notice that this kind of 'change' OFTEN HAPPENS WHEN I CLICK A NEW LINK BEFORE THE OLD PAGE HAS LOADED COMPLETELY, i.e., I interrupt the page half-way. Sometimes I also think that I notice a delay in Zope (the requests seems to take one second longer) when this kind of switch happens, but that may be me imagining things. There's nothing unusual in the STUPID_LOG_FILE when the switch occurs. I can, however, see that the previous time we ran zope we had the errors I've attached below (shouldn't make any difference). Bye, -- Bjorn [...] -- 2001-05-25T07:41:03 ERROR(200) ZODB Couldn't load state for '\000\000\000\000\00 0\000)\247' Traceback (innermost last): File /zope/zope-dc-2.3.2/lib/python/ZODB/Connection.py, line 508, in setstate AttributeError: 'None' object has no attribute 'load' -- 2001-05-25T07:43:58 INFO(0) ApplicationManager Shutdown requested by jey -- 2001-05-25T07:43:58 ERROR(200) ZODB Couldn't load state for '\000\000\000\000\00 0\000)\247' Traceback (innermost last): File /zope/zope-dc-2.3.2/lib/python/ZODB/Connection.py, line 508, in setstate File /zope/zope-dc-2.3.2/lib/python/ZODB/FileStorage.py, line 595, in load (Object: /zope/site-cn:7300-sammies/var/Data.fs) File /zope/zope-dc-2.3.2/lib/python/ZODB/FileStorage.py, line 572, in _load (Object: /zope/site-cn:7300-sammies/var/Data.fs) ValueError: I/O operation on closed file -- 2001-05-25T07:43:58 PROBLEM(100) zdaemon zdaemon: Fri May 25 15:43:58 2001: The kid, 16615, died on me. -- 2001-05-25T07:47:23 INFO(0) zdaemon zdaemon: Fri May 25 15:47:23 2001: Houston, we have forked -- 2001-05-25T07:47:23 INFO(0) zdaemon zdaemon: Fri May 25 15:47:23 2001: Hi, I jus t forked off a kid: 18005 -- 2001-05-25T07:47:23 INFO(0) zdaemon zdaemon: Fri May 25 15:47:23 2001: Houston, we have forked -- 2001-05-25T07:47:27 INFO(0) ZServer HTTP server started at Fri May 25 15:47:27 2 001 Hostname: box.exoweb.net Port: 7380 -- 2001-05-25T07:47:27 INFO(0) ZServer FTP server started at Fri May 25 15:47:27 20 01 Hostname: box Port: 7321 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Nope, couldn't have been, because: I couldn't set _p_changed from Python
Script, but I changed the last line setting the shopping_cart object in
the session to:
session.set('shopping_cart', cart.copy())
This should create a fresh copy of the dict, which should be sufficent
notice for the persistence machinery (or isn't a shallow copy enough?
cart is a dict of integers). I also removed the call to
cart_recalculate, just to make sure there were no spooky thing going on
there. I'm still seeing the bug.
Just a quick question. In:
session.set('shopping_cart', cart)
is cart call-by-reference or call by value (cart is a dict). I guess it
depends if 'set' makes a copy of the dict or not before assignment?
Also, do I really have to make a copy, or is there a way from Python
Script to notify the persistence machinery about a change in a complex
object, e.g., dict?
Bye,
--
Bjorn
-Original Message-
From: Matt Hamilton [mailto:[EMAIL PROTECTED]]
Posted At: Saturday, May 26, 2001 00:37
Posted To: Zope Developer
Conversation: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Subject: RE: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
On Fri, 25 May 2001, Bjorn Stabell wrote:
session = context.session_mgr.getSessionData()
cart = session.get('shopping_cart', {})
sku = int(sku)
if not cart.has_key(sku):
cart[sku] = 0
if int(qty)0:
cart[sku] = cart[sku] + int(qty)
Could this be the same problem that I was experiencing, in that
dicts/btrees do not in themselves notify the persitence machinery that
they have changed? try adding cart._p_changed = 1 to the code after
modifying cart{}.
-Matt
--
Matt Hamilton [EMAIL PROTECTED]
uk
Netsight Internet Solutions, Ltd. Business Vision on the
Internet
http://www.netsight.co.uk +44 (0)117
9090901
Web Hosting | Web Design | Domain Names | Co-location | DB
Integration
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Hi Joachim,
I'm confused as to the utility of this bit of code.
You loop over the items in the REQUEST.form dict, putting them all into
session storage except for 'file'.
Then you loop over all the items in the session data object, putting
them into the REQUEST.other dict.
Why the first step? What if I did:
http://yoursite/amethod?bag=YESfarb=FOO
I'd have both bag and farb in my session data object? Would this be
sufficient instead:
dtml-let data=SESSION.getSessionData()
manage=REQUEST.get('manage_content') or
data.get('manage_content')
dtml-unless manage
dtml-call data.set('manage_content','NO')
/dtml-unless
dtml-in data.keys()
dtml-let si=sequence-item
dtml-call REQUEST.set(si, data[si])
/dtml-let
/dtml-in
/dtml-let
I'm also confused why you're using YES and NO to represent a boolean
instead of just checking that a key exists or is true.
Aside from that, the code looks fine to me. Your problem is consistent
with Bjorn's iasmuch as it seems that your session data object gets
cleared inappropriately... but I can't make this happen on my copy of
Zope and CST. :-( Maybe after I look at Bjorn's site, I'll have a few
more clues. Bjorn also provided some additional data that is helpful as
well. I'll try to synthesize this stuff and come up with some sort of
answer next week (I'll be away for the weekend).
- C
Joachim Werner wrote:
I know, but that's why the errors are called random: They are not easy
to
replicate ...
I understand.
I don't know if this helps a bit: It's the code used in KONTENTOR for
putting the session into the REQUEST namespace. I think it is not the most
elegant way of doing this, but it seems to work, except for the times it
doesn't ;-)
The actual problem I can trace (we don't have a shopping cart) is that the
manage_content variable falls back to NO without a reason. Please tell me
that the problem is in our code, not in the CST:
dtml-let data=SESSION.getSessionData()
dtml-unless data.has_key('manage_content')
dtml-call data.set('manage_content','NO')
/dtml-unless
dtml-in REQUEST.form.keys()
dtml-let si=sequence-item
dtml-unless si=='file'
dtml-call data.set(si, REQUEST[si])
/dtml-unless
/dtml-let
/dtml-in
dtml-in data.keys()
dtml-let si=sequence-item
dtml-call REQUEST.set(si, data[si])
/dtml-let
/dtml-in
/dtml-let
Cheers
Joachim
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
What we experience with CoreSessionTracking: We have a manage mode in the Kontentor CMS hacky thing (no, it is NOT a product yet ;-)). It works well for some time (i.e. if I click on it, the system switches to manage mode and stays in manage mode until I click again), but from time to time it is just reset (quite randomly, too) to the non-manage mode. The click just sets a session variable. Haven't got any deeper with it yet, but the session seems not to be really reliable ... Joachim ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
These it appears CST is unstable reports are helpful to an extent (from Bjorn, Joachim, and Howard), as it lets me know that something needs to be done to CST. However, a much more helpful report would be one which provides a repeatable test case which invariably reproduces the problem instead of one which states the symptoms and effects of the problem. At this point, I understand that there *is* at least one problem, and I understand what constitutes the problem(s), but I can't seem to reproduce it/them. Since I'm not able to reliably reproduce the error state, I can't find the bugs, and this means I can't fix them. It doesn't help much that I have almost no time to devote to this at the moment, either. If anyone can come up with a repeatable test case which uses CST out of the box in a fresh Zope 2.3.X install which demonstrates this failure, I would be most grateful, and it would cause the problem to be fixed much faster! Shane has come up with a way to fix the None has no attribute 'load' bug that has plagued CST since the beginning, so maybe I'll make a release next week with the fix in it to see if the problems that are being reported are related to that. I will try some more stuff in the meantime, although I'm at a loss currently as to what could be causing these symptoms. :-( - C Joachim Werner wrote: What we experience with CoreSessionTracking: We have a manage mode in the Kontentor CMS hacky thing (no, it is NOT a product yet ;-)). It works well for some time (i.e. if I click on it, the system switches to manage mode and stays in manage mode until I click again), but from time to time it is just reset (quite randomly, too) to the non-manage mode. The click just sets a session variable. Haven't got any deeper with it yet, but the session seems not to be really reliable ... Joachim ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
On Thu, 24 May 2001, Chris McDonough wrote: These it appears CST is unstable reports are helpful to an extent (from Bjorn, Joachim, and Howard), as it lets me know that something needs to be done to CST. However, a much more helpful report would be one which provides a repeatable test case which invariably reproduces the problem instead of one which states the symptoms and effects of the problem. Just to add myself to the list, I too am having problems with CoreSessionTracking :( I am trying to find a test case for the problem, but I really can't replicate it. It first I thought it was a cookie issue, but I am now noting down the session id generated and it stays the same even when my session data is lost, so I don't think it is that. what I experience: I add an item to my shopping cart system and it shows up fine, all state is maintained. If I however leave the page and not touch anything for a couple of minutes and then reload the page, the cart is now empty. I know this is not that helpful, but I'm trying to tie it down myself! One thing that I do need to check though -- I am right in assuming I can insert complex objects into the SessionData right? I have an 'Order' class that amongst other things has a dict containing instances of a 'Product' class. The Order instance is stored in the SessionData. As I said it appears to work fine and I can add and delete items from my Order fine. Just it randomly looses it now and then. -Matt -- Matt Hamilton [EMAIL PROTECTED] Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Hosting | Web Design | Domain Names | Co-location | DB Integration ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
However, a much more helpful report would be one which provides a repeatable test case which invariably reproduces the problem instead of one which states the symptoms and effects of the problem. I know, but that's why the errors are called random: They are not easy to replicate ... ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Joachim Werner wrote: However, a much more helpful report would be one which provides a repeatable test case which invariably reproduces the problem instead of one which states the symptoms and effects of the problem. I know, but that's why the errors are called random: They are not easy to replicate ... I understand. I just wrote a test case that emulates many visitors firing off sessions and making changes to shared data objects simultaneously. It even emulates aborted connections. Unfortunately, I see nothing out of the ordinary. :-( This is very frustrating. - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Chris McDonough wrote: I just wrote a test case that emulates many visitors firing off sessions and making changes to shared data objects simultaneously. It even emulates aborted connections. Unfortunately, I see nothing out of the ordinary. :-( This is very frustrating. Maybe the problem folks are experiencing with CST are related to the None has no attribute 'load' bug that pops up every so often using a mounted storage (RAM-based session data containers use a mounted storage internally). If there's any chance that you can turn the STUPID_LOG_FILE on, if the problem happens while you're using the site, it would be helpful to be able to correlate (or not correlate) the problems folks are having with any messages in the error log. -C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] CoreSessionTracking 0.8
Hi The problem about CoreSessionTracking we describe before we can repeat again now. The step is: ( 1 ) User adds Burger to shopping cart ( 2 ) User adds coke to shopping cart and click link to add coke again before request finished ( 3 ) The Burger is disappear in shopping cart and just one coke ( not two ) ( 4 ) Repeat the step 2,Burger is back Anything you could tell me would be helpful. Regards, howard ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking 0.8
I remember this problem, but I haven't been able to reproduce it. But maybe it's because I'm not understanding the steps to reproduce it. The sentence user adds coke to shopping cart and click link to add coke again before request finished is hard to understand. Can you explain? Are you using frames? Howard Zhang wrote: Hi The problem about CoreSessionTracking we describe before we can repeat again now. The step is: ( 1 ) User adds Burger to shopping cart ( 2 ) User adds coke to shopping cart and click link to add coke again before request finished ( 3 ) The Burger is disappear in shopping cart and just one coke ( not two ) ( 4 ) Repeat the step 2,Burger is back Anything you could tell me would be helpful. Regards, howard ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
Allright, let me try again. I wish I had a small piece of code to give you so you can reproduce it, but right now you'd have to get our entire CMF-based website. The bug basically manifests itself in that there are two versions of the variable we put in the session (a shopping cart dict). When I browse through the site (not even updating the shopping cart) it'll show one version for some links (1-40) before it switches to show the other, and so on. It looks like the website has two shopping carts that it switches back and forth between. You can see the shopping cart on every page in the website (it's embedded into the template). We were using frames, but I tried it several times without frames now and the bug remains. I even noticed that other variables disappeared randomly as well, e.g., USER_PREF_LANGUAGES which is set by the Localizer, resulting in a key error (I've probably seen 300 pages views, and then suddenly one going back to another page gives a key error?). I'm very curious what could possibly be causing such problems. I thought there might be something wrong in the shared memory between threads, as I can't see anything else changing but the threads (is there a way to display which thread is doing the publishing?). I've seen similar randomness displayed in other situations where I've been reloading pages that would sometimes (same interval, about every 1-40 times) show one character set, and other times another. I think nobody likes to see that kind of randomness. It gives me a very bad stomach feeling. I definately think it's something deeper than a CoreSessionTracking problem. Bye, -- Bjorn Stabell [EMAIL PROTECTED] -Original Message- From: Chris McDonough [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 23, 2001 20:34 To: Howard Zhang Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Exoweb Subject: Re: [Zope-dev] CoreSessionTracking 0.8 I remember this problem, but I haven't been able to reproduce it. But maybe it's because I'm not understanding the steps to reproduce it. The sentence user adds coke to shopping cart and click link to add coke again before request finished is hard to understand. Can you explain? Are you using frames? Howard Zhang wrote: Hi The problem about CoreSessionTracking we describe before we can repeat again now. The step is: ( 1 ) User adds Burger to shopping cart ( 2 ) User adds coke to shopping cart and click link to add coke again before request finished ( 3 ) The Burger is disappear in shopping cart and just one coke ( not two ) ( 4 ) Repeat the step 2,Burger is back Anything you could tell me would be helpful. Regards, howard ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8)
It's obvious. This is just Zope's way of telling you not live on hamburgers and coke. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bjorn Stabell Sent: Thursday, May 24, 2001 12:33 AM To: Chris McDonough; Howard Zhang Cc: [EMAIL PROTECTED] Subject: Randomness (RE: [Zope-dev] CoreSessionTracking 0.8) Allright, let me try again. I wish I had a small piece of code to give you so you can reproduce it, but right now you'd have to get our entire CMF-based website. The bug basically manifests itself in that there are two versions of the variable we put in the session (a shopping cart dict). When I browse through the site (not even updating the shopping cart) it'll show one version for some links (1-40) before it switches to show the other, and so on. It looks like the website has two shopping carts that it switches back and forth between. You can see the shopping cart on every page in the website (it's embedded into the template). We were using frames, but I tried it several times without frames now and the bug remains. I even noticed that other variables disappeared randomly as well, e.g., USER_PREF_LANGUAGES which is set by the Localizer, resulting in a key error (I've probably seen 300 pages views, and then suddenly one going back to another page gives a key error?). I'm very curious what could possibly be causing such problems. I thought there might be something wrong in the shared memory between threads, as I can't see anything else changing but the threads (is there a way to display which thread is doing the publishing?). I've seen similar randomness displayed in other situations where I've been reloading pages that would sometimes (same interval, about every 1-40 times) show one character set, and other times another. I think nobody likes to see that kind of randomness. It gives me a very bad stomach feeling. I definately think it's something deeper than a CoreSessionTracking problem. Bye, -- Bjorn Stabell [EMAIL PROTECTED] -Original Message- From: Chris McDonough [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 23, 2001 20:34 To: Howard Zhang Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Exoweb Subject: Re: [Zope-dev] CoreSessionTracking 0.8 I remember this problem, but I haven't been able to reproduce it. But maybe it's because I'm not understanding the steps to reproduce it. The sentence user adds coke to shopping cart and click link to add coke again before request finished is hard to understand. Can you explain? Are you using frames? Howard Zhang wrote: Hi The problem about CoreSessionTracking we describe before we can repeat again now. The step is: ( 1 ) User adds Burger to shopping cart ( 2 ) User adds coke to shopping cart and click link to add coke again before request finished ( 3 ) The Burger is disappear in shopping cart and just one coke ( not two ) ( 4 ) Repeat the step 2,Burger is back Anything you could tell me would be helpful. Regards, howard ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) winmail.dat
Re: [Zope-dev] CoreSessionTracking 0.8
On 23 May 2001 19:00:41 +0800, Howard Zhang wrote:
Hi
The problem about CoreSessionTracking we describe before we can
repeat again now.
The step is:
( 1 ) User adds Burger to shopping cart
( 2 ) User adds coke to shopping cart and click link to add coke
again before request finished
( 3 ) The Burger is disappear in shopping cart and just one coke
( not two )
( 4 ) Repeat the step 2,Burger is back
dtml-call putTongueInObject('cheek')
Your server is starving, let it get it's fill and feed it regularly.
Quit taking the food away from it. ;)
.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] CoreSessionTracking 0.8 strangeness
Yes, it is entirely with cookies, and we are using frames, although the there's only one sub-frame accessing the session object (that's where we show the shopping cart). -Original Message- From: Chris McDonough [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 12, 2001 23:18 To: Bjorn Stabell Cc: [EMAIL PROTECTED]; Exoweb Subject: Re: [Zope-dev] CoreSessionTracking 0.8 strangeness Bjorn, Is this entirely with cookies? Or are you using url-encoding anywhere? Does your application make use of frames or multiple windows? - C Bjorn Stabell wrote: Chris, It is definately not what you expect, although it was a good guess :) Here's an example of what happens: 1. User adds Burger to shopping cart - Shopping cart shows Burger 2. User adds Coke to shopping cart - Shopping carts shows Burger and Coke 3. User adds Fries to shopping cart - Shoppping cart is empty(!) 4. User adds Fries to shopping cart - Shopping cart only shows Fries 4. User adds Apple Pie to shopping cart - Shopping cart shows Fries and Apple Pie 5. User adds Ice Cream to shopping cart - Shopping cart shows Burger, Coke, and Ice Cream(!) ...and so on... Sometimes, clicking links that don't even touch the shopping cart will make it disappear, e.g., viewing a new product category in the catalog. It seems pretty random, and it is hard to reproduce reliably. The shopping cart is displayed on the same page as the catalog. Any ideas? PS! I have noticed that in other cases Zope is a acting a little bit random too, e.g., when it comes to which character set is used; it will not obey our commands to set it to gb2312 about 1 out of 10 times. That could be an IE bug, but I doubt it. Bye, -- Bjorn ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] CoreSessionTracking 0.8 strangeness
Chris, It is definately not what you expect, although it was a good guess :) Here's an example of what happens: 1. User adds Burger to shopping cart - Shopping cart shows Burger 2. User adds Coke to shopping cart - Shopping carts shows Burger and Coke 3. User adds Fries to shopping cart - Shoppping cart is empty(!) 4. User adds Fries to shopping cart - Shopping cart only shows Fries 4. User adds Apple Pie to shopping cart - Shopping cart shows Fries and Apple Pie 5. User adds Ice Cream to shopping cart - Shopping cart shows Burger, Coke, and Ice Cream(!) ...and so on... Sometimes, clicking links that don't even touch the shopping cart will make it disappear, e.g., viewing a new product category in the catalog. It seems pretty random, and it is hard to reproduce reliably. The shopping cart is displayed on the same page as the catalog. Any ideas? PS! I have noticed that in other cases Zope is a acting a little bit random too, e.g., when it comes to which character set is used; it will not obey our commands to set it to gb2312 about 1 out of 10 times. That could be an IE bug, but I doubt it. Bye, -- Bjorn -Original Message- From: Chris McDonough [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 20:47 To: Bjorn Stabell Cc: [EMAIL PROTECTED]; Exoweb Subject: Re: [Zope-dev] CoreSessionTracking 0.8 strangeness This is very odd, as cst depends on ZODB locking just like everything else in Zope, and uses the same transaction facilities and semantics. Now this may *be* the problem... some other folks have explained a problem where newly-created session data disappears if the long-running request that created it is aborted... this may make sense, because the request never gets the chance to finish, and the session data object never gets committed to the database because the ZODB transaction is aborted. It may be the case (especially if you're using frames or multiple windows) that simultaneous concurrent initial requests for a session data object from the same client might cause one of two newly-created data objects to be lost. But I can't imagine a case where a session data object exists for a while (a few minutes), and then a client comes in with the same sessionid, and a new session data object is created for him, not *replacing* the old one, but in addition to the old one... the only possibility for something like this that I can see is on initial request, or if a particularly long-running method creates a session data object, and a user comes in directly after it... ah, wait. I think I see how this can happen. 1. User hits /longrunningmethod. 2. /longrunningmethod creates a session data object as part of its operation. 3. /longrunning method requires 1 minute to process completely. 4. In the meantime, the user (in a separate window or frame) visits /shortrunningmethod. 5. /shortrunningmethod creates a session data object as part of its operation. 6. /shortrunningmethod completes and the session data object it created is committed to the ZODB. 7. User visits /shortrunningmethod2, which modifies the existing session data object, /shortunningmethod3, which also does this, etc. 8. In the meantime, /longrunningmethod finishes and replaces the session data object which has stuff in it from the shortrunningmethods with the one it created. I'm not completely 100% sure about this, but at least it's something to test. Could this be what's happening to you? I may have been overzealous when dealing with confict error problems here... basically, the conflict error detection stuff is disabled for session data objects, which makes this sort of thing possible and likely. Conflict error detection is the ZODB equivalent of record-locking... and when it's ignored, you can have some of the same problems that happen in a nontransactional system (like the problem I outlined above). Sigh. - C Bjorn Stabell wrote: Hi, We're developing a shopping cart using the CoreSessionTracking product v0.8, but we've run into a strange problem; once in a while getSessionData() will create a new session data object (the token value remains the same), and us that for a while. Now we'll end up having two different shopping cart objects, with getSessionData() randomly returning one of them them. We're running Zope 2.3.1. Could it be that some threads can't find the shared session data object and creates their own? The only thing changing between each HTTP request is the thread serving the request, AFAIK. Regards, -- Bjorn Stabell [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist
Re: [Zope-dev] CoreSessionTracking 0.8 strangeness
Bjorn, Is this entirely with cookies? Or are you using url-encoding anywhere? Does your application make use of frames or multiple windows? - C Bjorn Stabell wrote: Chris, It is definately not what you expect, although it was a good guess :) Here's an example of what happens: 1. User adds Burger to shopping cart - Shopping cart shows Burger 2. User adds Coke to shopping cart - Shopping carts shows Burger and Coke 3. User adds Fries to shopping cart - Shoppping cart is empty(!) 4. User adds Fries to shopping cart - Shopping cart only shows Fries 4. User adds Apple Pie to shopping cart - Shopping cart shows Fries and Apple Pie 5. User adds Ice Cream to shopping cart - Shopping cart shows Burger, Coke, and Ice Cream(!) ...and so on... Sometimes, clicking links that don't even touch the shopping cart will make it disappear, e.g., viewing a new product category in the catalog. It seems pretty random, and it is hard to reproduce reliably. The shopping cart is displayed on the same page as the catalog. Any ideas? PS! I have noticed that in other cases Zope is a acting a little bit random too, e.g., when it comes to which character set is used; it will not obey our commands to set it to gb2312 about 1 out of 10 times. That could be an IE bug, but I doubt it. Bye, -- Bjorn ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] CoreSessionTracking 0.8 strangeness
Hi, We're developing a shopping cart using the CoreSessionTracking product v0.8, but we've run into a strange problem; once in a while getSessionData() will create a new session data object (the token value remains the same), and us that for a while. Now we'll end up having two different shopping cart objects, with getSessionData() randomly returning one of them them. We're running Zope 2.3.1. Could it be that some threads can't find the shared session data object and creates their own? The only thing changing between each HTTP request is the thread serving the request, AFAIK. Regards, -- Bjorn Stabell [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking 0.8 strangeness
This is very odd, as cst depends on ZODB locking just like everything else in Zope, and uses the same transaction facilities and semantics. Now this may *be* the problem... some other folks have explained a problem where newly-created session data disappears if the long-running request that created it is aborted... this may make sense, because the request never gets the chance to finish, and the session data object never gets committed to the database because the ZODB transaction is aborted. It may be the case (especially if you're using frames or multiple windows) that simultaneous concurrent initial requests for a session data object from the same client might cause one of two newly-created data objects to be lost. But I can't imagine a case where a session data object exists for a while (a few minutes), and then a client comes in with the same sessionid, and a new session data object is created for him, not *replacing* the old one, but in addition to the old one... the only possibility for something like this that I can see is on initial request, or if a particularly long-running method creates a session data object, and a user comes in directly after it... ah, wait. I think I see how this can happen. 1. User hits /longrunningmethod. 2. /longrunningmethod creates a session data object as part of its operation. 3. /longrunning method requires 1 minute to process completely. 4. In the meantime, the user (in a separate window or frame) visits /shortrunningmethod. 5. /shortrunningmethod creates a session data object as part of its operation. 6. /shortrunningmethod completes and the session data object it created is committed to the ZODB. 7. User visits /shortrunningmethod2, which modifies the existing session data object, /shortunningmethod3, which also does this, etc. 8. In the meantime, /longrunningmethod finishes and replaces the session data object which has stuff in it from the shortrunningmethods with the one it created. I'm not completely 100% sure about this, but at least it's something to test. Could this be what's happening to you? I may have been overzealous when dealing with confict error problems here... basically, the conflict error detection stuff is disabled for session data objects, which makes this sort of thing possible and likely. Conflict error detection is the ZODB equivalent of record-locking... and when it's ignored, you can have some of the same problems that happen in a nontransactional system (like the problem I outlined above). Sigh. - C Bjorn Stabell wrote: Hi, We're developing a shopping cart using the CoreSessionTracking product v0.8, but we've run into a strange problem; once in a while getSessionData() will create a new session data object (the token value remains the same), and us that for a while. Now we'll end up having two different shopping cart objects, with getSessionData() randomly returning one of them them. We're running Zope 2.3.1. Could it be that some threads can't find the shared session data object and creates their own? The only thing changing between each HTTP request is the thread serving the request, AFAIK. Regards, -- Bjorn Stabell [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] CoreSessionTracking
Is onStart and onEnd broken in the CoreSessionTracking (0.8) product? (Or am
I broken? :-))
I have a folder /Radio
Within that folder I have a Session ID Manager and a Session Data
Manager named Session.
Session onStart method path of the Session ID Manager is set to
/Radio/onStart
I have an external method /Radio/onStart that does work if called
standalone,
from zLOG import LOG, WARNING
def onStart(sdo):
LOG('session started', WARNING, 'session started')
but it never gets called when I call my index_html;
dtml-var standard_html_header
dtml-var Session.getToken()
dtml-if Session.isTokenNew()
Token is new.
dtml-else
Token is not new.
/dtml-if
dtml-var standard_html_footer
Ths index_html method does return 'Token is new', but no onStart method is
being called.
What am I missing??? I have read the helpfile over and over again, but it
still doesn't work.
?
/Magnus
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking
Is onStart and onEnd broken in the CoreSessionTracking (0.8) product? (Or
am
I broken? :-))
I hope neither ;-)
I have a folder /Radio
Within that folder I have a Session ID Manager and a Session Data
Manager named Session.
Session onStart method path of the Session ID Manager is set to
/Radio/onStart
I have an external method /Radio/onStart that does work if called
standalone,
from zLOG import LOG, WARNING
def onStart(sdo):
LOG('session started', WARNING, 'session started')
but it never gets called when I call my index_html;
dtml-var standard_html_header
dtml-var Session.getToken()
dtml-if Session.isTokenNew()
Token is new.
dtml-else
Token is not new.
/dtml-if
dtml-var standard_html_footer
The onStart method will be called when a session data object is created.
Neither of the calls you show here create a session data object. Something
like Session.getSessionData() would, however.
Ths index_html method does return 'Token is new', but no onStart method is
being called.
What am I missing??? I have read the helpfile over and over again, but it
still doesn't work.
?
/Magnus
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
SV: [Zope-dev] CoreSessionTracking
The onStart method will be called when a session data object is created. Neither of the calls you show here create a session data object. Something like Session.getSessionData() would, however. Ah. I read when a session starts, you may call an external method or PythonScrip and thought that the session started when I received a new token... Thanks! /Magnus ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
SV: [Zope-dev] CoreSessionTracking
This onStart method...
sdo['date'] = context.ZopeTime()
...gives this error:
--
2001-04-23T14:36:32 PROBLEM(100) Session Tracking session event failed
The call to function onStart failed. Traceback:
Traceback (innermost last):
File
/usr/home/magnus/www/Zope-2.3.1-src/lib/python/Products/CoreSessionTracking/
SessionDataManager.py, line 451, in __call__
(Object: )
File
/usr/home/magnus/www/Zope-2.3.1-src/lib/python/Shared/DC/Scripts/Bindings.py
, line 324, in __call__
(Object: onStart)
File
/usr/home/magnus/www/Zope-2.3.1-src/lib/python/Shared/DC/Scripts/Bindings.py
, line 354, in _bindAndExec
(Object: onStart)
File
/usr/home/magnus/www/Zope-2.3.1-src/lib/python/Products/PythonScripts/Python
Script.py, line 336, in
_exec
(Object: onStart)
(Info: ({'script': PythonScript instance at 87d1b10, 'context':
Folder instance at 8847358, 'container': Folder instance at 8847358,
'traverse_subpath': []}, ({},), {}, None))
File Script (Python), line 2, in onStart
File
/usr/home/magnus/www/Zope-2.3.1-src/lib/python/Products/PythonScripts/zbytec
odehacks/VSExec.py, line 430, in __setitem__
TypeError: object does not support item assignment
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking
Darn. Security nails us once again. :-(
I'll need to figure out how to allow __setitem__ to be called on session
data objects from within a Python Script.
In the meantime, use the .set method of the session data object, e.g. in the
onStart function:
sdo.set('Username', 'Foobar')
.. or use an external method.
- Original Message -
From: Magnus Heino (Rivermen) [EMAIL PROTECTED]
To: 'Chris McDonough' [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, April 23, 2001 10:37 AM
Subject: SV: [Zope-dev] CoreSessionTracking
This onStart method...
sdo['date'] = context.ZopeTime()
...gives this error:
--
2001-04-23T14:36:32 PROBLEM(100) Session Tracking session event failed
The call to function onStart failed. Traceback:
Traceback (innermost last):
File
/usr/home/magnus/www/Zope-2.3.1-src/lib/python/Products/CoreSessionTracking/
SessionDataManager.py, line 451, in __call__
(Object: )
File
/usr/home/magnus/www/Zope-2.3.1-src/lib/python/Shared/DC/Scripts/Bindings.py
, line 324, in __call__
(Object: onStart)
File
/usr/home/magnus/www/Zope-2.3.1-src/lib/python/Shared/DC/Scripts/Bindings.py
, line 354, in _bindAndExec
(Object: onStart)
File
/usr/home/magnus/www/Zope-2.3.1-src/lib/python/Products/PythonScripts/Python
Script.py, line 336, in
_exec
(Object: onStart)
(Info: ({'script': PythonScript instance at 87d1b10, 'context':
Folder instance at 8847358, 'container': Folder instance at 8847358,
'traverse_subpath': []}, ({},), {}, None))
File Script (Python), line 2, in onStart
File
/usr/home/magnus/www/Zope-2.3.1-src/lib/python/Products/PythonScripts/zbytec
odehacks/VSExec.py, line 430, in __setitem__
TypeError: object does not support item assignment
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
SV: [Zope-dev] CoreSessionTracking
In the meantime, use the .set method of the session data
object, e.g. in the
onStart function:
sdo.set('Username', 'Foobar')
.. or use an external method.
Ok, works now. Thanks.
How to I access things like the DTML AUTHENTICATED_USER.getUserName() from a
python script?
/Magnus
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking
Alternately (and this will be in the next CST release), add this to the
session data object class (SessionData.SessionData):
__guarded_setitem__ = __setitem__
As far as finding the currently logged in user's name, try this:
context.REQUEST['AUTHENTICATED_USER'].getUserName()
This is a deprecated API, however. The new one I can't find at the moment,
though. ;-)
- Original Message -
From: Magnus Heino (Rivermen) [EMAIL PROTECTED]
To: 'Chris McDonough' [EMAIL PROTECTED]; Magnus Heino (Rivermen)
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, April 23, 2001 10:48 AM
Subject: SV: [Zope-dev] CoreSessionTracking
In the meantime, use the .set method of the session data
object, e.g. in the
onStart function:
sdo.set('Username', 'Foobar')
.. or use an external method.
Ok, works now. Thanks.
How to I access things like the DTML AUTHENTICATED_USER.getUserName() from
a
python script?
/Magnus
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking
Chris McDonough wrote: Darn. Security nails us once again. :-( I'll need to figure out how to allow __setitem__ to be called on session data objects from within a Python Script. Add a line below your definition of __setitem__ that reads: __guarded_setitem__ = __setitem__ cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] CoreSessionTracking
Title: RE: [Zope-dev] CoreSessionTracking Do you mean: from AccessControl import getSecurityManager security = getSecurityManager() user = security.getUser() userName = user.getUserName() ??? Adrian... -Original Message- From: Chris Withers [mailto:[EMAIL PROTECTED]] Sent: Monday, 23 April 2001 16:57 To: Chris McDonough Cc: Magnus Heino (Rivermen); [EMAIL PROTECTED] Subject: Re: [Zope-dev] CoreSessionTracking Chris McDonough wrote: Alternately (and this will be in the next CST release), add this to the session data object class (SessionData.SessionData): __guarded_setitem__ = __setitem__ OK, that'll teach me to read the whole thread before I post :-) As far as finding the currently logged in user's name, try this: context.REQUEST['AUTHENTICATED_USER'].getUserName() This is a deprecated API, however. The new one I can't find at the moment, though. ;-) When you find out, can you let us know :-S Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking
RE: [Zope-dev] CoreSessionTrackingThat's it! Except from DTML. ;-) - Original Message - From: Adrian Hungate To: 'Chris Withers' ; Chris McDonough Cc: Magnus Heino (Rivermen) ; [EMAIL PROTECTED] Sent: Monday, April 23, 2001 12:00 PM Subject: RE: [Zope-dev] CoreSessionTracking Do you mean: from AccessControl import getSecurityManager security = getSecurityManager() user = security.getUser() userName = user.getUserName() ??? Adrian... -Original Message- From: Chris Withers [mailto:[EMAIL PROTECTED]] Sent: Monday, 23 April 2001 16:57 To: Chris McDonough Cc: Magnus Heino (Rivermen); [EMAIL PROTECTED] Subject: Re: [Zope-dev] CoreSessionTracking Chris McDonough wrote: Alternately (and this will be in the next CST release), add this to the session data object class (SessionData.SessionData): __guarded_setitem__ = __setitem__ OK, that'll teach me to read the whole thread before I post :-) As far as finding the currently logged in user's name, try this: context.REQUEST['AUTHENTICATED_USER'].getUserName() This is a deprecated API, however. The new one I can't find at the moment, though. ;-) When you find out, can you let us know :-S Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] CoreSessionTracking
_.SecurityGetUser() -Randy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking
Nothing like good documentation ;-) Where can I find otu about that? http://www.zope.org/Members/michel/Projects/Interfaces/DTMLSecurityAPI Is there an equivalent of: dtml-var _.SecurityGetUser().getUserName() This works. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] CoreSessionTracking
The documentation is in lib/python/AccessControl/DTML.py :) From: Chris Withers [mailto:[EMAIL PROTECTED]] dtml-var _.SecurityGetUser().getUserName() as for simplifying _.SecurityGetUser().getUserName(), BasicUser defines __str__ to return getUserName(), so dtml-var SecurityGetUser should result in the same output as dtml-var expr=_.SecurityGetUser().getUserName() -Randy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking
Chris McDonough wrote: Nothing like good documentation ;-) Where can I find otu about that? http://www.zope.org/Members/michel/Projects/Interfaces/DTMLSecurityAPI It's also in the security chapter of the Zope Book *embarrassed grinz* Randall F. Kern wrote: as for simplifying _.SecurityGetUser().getUserName(), BasicUser defines __str__ to return getUserName(), so dtml-var SecurityGetUser should result in the same output as dtml-var expr=_.SecurityGetUser().getUserName() And in PS, I guess x + `_.SecurityGetUser()` + y would work when x and y are strings? Cool :-) cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] CoreSessionTracking stuff
More questions on CoreSessionTracking. On on site I wish to persist the information on a session indefinitely so a user can reconnect with those previous session settings. I looked at "External Session Data Container" (ESDC) and had some questions here I go: -Why does an ESDC have a session timeout in 20 minutes, yet the cookie lifespan can be 30 days. Surely there will be no way to tie a cookie back up to a session since the ESDC will be have had that person nuked, I was sort of hoping I coudl persist the data in the ESDC for a long time to provide storage (I could always set the minutes to 9 or something silly). I guess if I really want data to be persisted for ever some sort of Membership product will be needed... -Mounting a non-undoable db into Zope is not trivial unless there is something Im missing. There's a non-undoable system every Zope installation has called the file system, why dont we use that? I was thinking we could modifiy LocalFS to provide that sort of functionality would be much easier... Cheers. -- Andy McKay. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking stuff
Hi Andy, -Why does an ESDC have a session timeout in 20 minutes, yet the cookie lifespan can be 30 days. Surely there will be no way to tie a cookie back up to a session since the ESDC will be have had that person nuked, I was sort of hoping I coudl persist the data in the ESDC for a long time to provide storage (I could always set the minutes to 9 or something silly). I guess if I really want data to be persisted for ever some sort of Membership product will be needed... A session data object timeout of "0" as set in the session data container means "give me completely persistent session data objects, do not expire them". Set it to this, and set a high cookie timeout. But yes, a better way to do something like this is to use sessioning in combination with a membership product. -Mounting a non-undoable db into Zope is not trivial unless there is something Im missing. There's a non-undoable system every Zope installation has called the file system, why dont we use that? I was thinking we could modifiy LocalFS to provide that sort of functionality would be much easier... Local filesystem access won't work across ZEO clients. The primary purpose of an external data container is to provide access to a shared namespace between ZEO clients. This doesn't mean someone couldn't write an alternate data container implementation that uses the filesystem, however. As far as the difficulty of mounting goes, when I can find some time, I want to write a mounting howto. HTH, - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking stuff
A session data object timeout of "0" as set in the session data container means "give me completely persistent session data objects, do not expire them". Set it to this, and set a high cookie timeout. But yes, a better way to do something like this is to use sessioning in combination with a membership product. Ah ok, yes the more I thought about it, the more I thought a Membership system is the way to go. Local filesystem access won't work across ZEO clients. The primary purpose of an external data container is to provide access to a shared namespace between ZEO clients. This doesn't mean someone couldn't write an alternate data container implementation that uses the filesystem, however. True. But its another option that is quick and easy for many people. I'll put it on my interesting things to do on a rainy day list somewhere As far as the difficulty of mounting goes, when I can find some time, I want to write a mounting howto. Thats always welcome. Thanks. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] CoreSessionTracking Release 0.2
I had some reports yesterday of the Core Session Tracking development code not working against recent Zope 2.2 releases, so I removed dependencies in the code on the Interface module which were causing the incompatibilities. CoreSessionTracking 0.1 will work against Zope 2.3a1, but not against Zope 2.2.3, 2.2.4, etc. A new release of the code which has these dependencies removed, 0.2, is available from http://www.zope.org/Members/mcdonc/Products/CoreSessionTracking . This release works against all Zope 2.2.X based systems, AFAIK. Thanks! - Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] CoreSessionTracking - Access Session Data permission
Hi Chris, in an earlier message, you defended the existence of a separate permission "Access Session Data" (in the CoreSessionTracking proposal) by the following case: There may be (authenticated) users with (TTF?) scripting rights that should be prevented to screen session data (by withdrawing the "Access Session Data" permission from them). This will only be effective, when not all users automatically have the "Anonymous" role. There was a discussion about the "Anonymous" role some months ago in the list: * The (outdated) Content Manager Guide mentions that any user has the role "Anonymous". * A role "Anonymous" with the meaning "not authenticated" will make management for sites with authenticated, non-manager users more difficult, as those users should have most rights of "Anonymous". Only in exceptional cases, e.g. for session data, they will have less priviledges. If the meaning of "Anonymous" changes in this direction, then this role should be explicitely assignable to users in the "Change User" view to avoid such difficulties. I would be much in favour of a solution that does not entail new permissions. This would be possible, if session id management and access to session data would be melted together. In the current proposal, both are separate modules linked by the application: the application obtains a session id from the id manager and then accesses the session data, usually with the id, but in principle with anything it likes, e.g. a stolen session id. It seems that the new permissions should help to control such abuses. If the session id becomes an implicit (not DTML-forgable) parameter for session data access, then the session data need not to be protected by new permissions. However, I agree with you, that even making session id management implicit, will not provide strict security. Why am I against new permissions? This has partly to do with the current Zope permission management. As soon as you have more than a few products installed and created a few additional roles, permission management becomes a nightmare: it is very difficult to keep the overview with the current unstructured, non-batched permission setting view. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking proposal
At 10:44 PM 9/30/00 -0400, Chris McDonough wrote: However, as prompted by a Digital Creations "jam session", there are going to be changes to the use cases which actually make the "Browser Id Manager" into a "Session Id Manager" which will generate a "session token" that will carry both a "browser id" (meant to semipermanent) *and* a "session key" (meant to exist for the duration of a "session" as bounded by a "global" timeout period). This is purely an implementation Huh? I don't get it. It's still just an opaque key from the POV of the session data managers, right? It doesn't matter how you assign the key, just as long as it's unique. The concept of a "browser id" was purely a *metaphor* on my part to show why you only needed one key, whose lifetime only needed to be as long as the longest session handled by the session data managers. That's also why in the docs I wrote up on the Wiki, I called the ID handler a "session ID manager", not a browser ID manager. As far as I can see, there isn't any need for a *real* browser ID, it was just a metaphor. detail, driven by the somewhat specious requirement that we allow people to associate a "session" bounded by one session data manager with a "session" bounded by another in the same system. (The implementation is also driven by my reluctance to store session key state related to a browserid inside Zope itself... it could be handled internally, but I've decided to put the "session" state on the client instead, it's easier). I'm still lost. Reluctance to store what state? Why do you need to store anything? Keep in mind that a session data manager just throws away its record for a given ID when it wants to expire it. If the user "comes back" and still has a session cookie, that particular session data manager will just start a new session with the old key. No harm, no foul. If a specialized session data manager wants to keep permanent records of expired sessions, it can simply move the record somewhere else and/or give it a permanent key when it expires. Or it can give every session a permanent ID, but simply look up active sessions using the session cookie. I assume from the use cases, however, that a permanent record of an expired session is a rarity, not the rule. So it seems wrong to me to add complications just to handle that case. As for associating sessions between two session data managers, why can't the simple session cookie concept handle that? It's only one ID, and so is shared, right? I'm not quite clear on what the requirement is here. This will be an opt-in feature for session data manager implementations, Now I'm really lost. What does the feature have to do with the session data managers at all? token. However, it also means that session tokens (which replace browser ids as a identification value) will be prone to change much more frequently, as a new session token will be constructed every time the "global" session timeout expires, and it will contain both the "browser key" (potentially recycled out of a received token) and a new "session key". This sounds to me again like the "browser id" concept is being taken too literally. I assumed that the global "session ID" would expire and be reset just as described above. It sounds to me like you're "changing" to what I thought we agreed on in the first place. :) This may actually be beneficial (in some twisted, baroque way :-), because it means that people will be less tempted to set the cookie expiry time far into the future, as the cookie will be reset more often. I think you're actually making things more complex than they need to be. It sounds like the misunderstanding probably stems from the part of the SessionIDManager Wiki page that reads: "Session ID's provided by a Session ID Manager never expire. The cookie may expire, or data associated with the session may expire, but the session ID never does. It can be thought of as being like a "browser serial number" that sometimes changes (when a cookie expires, or user reloads a non-session URL in URL mode)." What this means is that there is never any reason to issue a new global session identifier value when one already exists. However, if the cookie which *carries* that global session identifier expires, then one may consider that global session identifier to have expired. What I was trying to emphasize is that *you don't need to know when the 'global' session has expired*. Only session data managers need to know something has expired, and they do it by timeout on their local session data objects, and they don't need any info from the SessionIDManager in order to do that. That's why I described it as the session ID never expiring. The SessionIDManager just issues ID's. It doesn't have to remember them, expire them, or anything else. It *just* gets the current ID or issues a new one if it doesn't exist. That's all. The properties on the SessionIDManager control the cookie expiration, which thus
Re: [Zope-dev] CoreSessionTracking proposal
Chris McDonough writes: The random element of the token is currently five characters. I may need to "up" this. The secure cookie requirement is already reflected in the use cases and in the current implementation. Anybody have any other bright ideas about how to make session tokens harder to guess? Hash them as GUF does. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking proposal
Dieter Maurer wrote: Phillip J. Eby writes: The actual lifetime of a browser ID will be controllable by the Zope site manager. I agree with you, however, in that the default lifetime should be reasonable. Indeed, I would suggest that the default simply be to use cookies with no expiration date, and which therefore only live so long as the user's browser is open, be it minutes or days. I would be very happy with this. Good, that's what it is now. :-) As I understand it, the "Access Session Data" permission gives you the right to call a method that returns you the session data for the current request, but does not give you the right to access arbitrary session data. Thus, one only has permission to see one's own session data. Do we need a special permission for this? All users will have it (when sessions are used at all). Thus, why clutter the (already cluttered) security management screen with an additional permission. It is advantageous to prevent certain users from accessing session data (such as nonanonymous, non-management users with TTW scripting capabilites) so they cannot arbitrarily examine session data values. -- Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] CoreSessionTracking proposal
I just read the CoreSessionTracking proposal. I am very concerned about the "long living browser id". * Why should a browser id live longer than the session data maintained for the browser? This means, if the session lifetime is in the order of an hour, the cookie need not live longer than, say, a day. * I am *VERY* suspicious whenever I get a cookie with an expiration date more than a few days in the future. I do not see any reason why a site should be able to track my activity over a longer period of time -- at least no without my explicit consent. I tend to refuse long living cookies and as sites continue to send cookies on any request, I disable cookies all together. If this means, a site can not be visited, I stop visiting the site. If Zope tries to implement long living browser ids, I fear, Zope sites will have a high chance, I will no longer visit them. Security: * I do not think "Annonymous" should have the permission "Add Session Data Objects". Session handling should be transparent, including allocation of a session data object. * I do not think "Annonymous" should have "Access Session Data" permission with the exception to its own session data. Sessions may contain confident information that must not be revealed to other users. Again, session handling should be transparent, implemented by a mechanism that implements its own special purpose access policy (access to session data only by the session owner). Consistency: * sometimes "__zsession__" and sometime "_ZopeId" seems to be used to refer to an identifier used for session tracking * how is it possible to have nested "Session ID Managers" (necessary for delegation) with "getZopeSessionID" a singleton? As I understand it, the "singleton" property prevents any child to reimplement the method. I must be wrong with this assumption. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking proposal
DISCLAIMER: everything I'm about to say is my understanding based on my discussions with Chris about how to do session management, and does not necessarily reflect the current state of the session management code that he is developing, or what will end up in the Zope core. :) At 09:27 PM 9/30/00 +0200, Dieter Maurer wrote: I am very concerned about the "long living browser id". * Why should a browser id live longer than the session data maintained for the browser? It doesn't need to, necessarily. However, since the session data is decoupled from ID management, the browser ID needs to live at least as long as the longest type of session handled by the site. This means, if the session lifetime is in the order of an hour, the cookie need not live longer than, say, a day. Correct. Of course, if the site *also* contains session objects that have a life on the order of a day, then at least one cookie set by the site must have that longer lifetime. Thus, by setting the browser ID lifetime to at least as long as the longest session, one avoids having multiple cookies, one per session manager. * I am *VERY* suspicious whenever I get a cookie with an expiration date more than a few days in the future. If Zope tries to implement long living browser ids, I fear, Zope sites will have a high chance, I will no longer visit them. The actual lifetime of a browser ID will be controllable by the Zope site manager. I agree with you, however, in that the default lifetime should be reasonable. Indeed, I would suggest that the default simply be to use cookies with no expiration date, and which therefore only live so long as the user's browser is open, be it minutes or days. * I do not think "Annonymous" should have "Access Session Data" permission with the exception to its own session data. As I understand it, the "Access Session Data" permission gives you the right to call a method that returns you the session data for the current request, but does not give you the right to access arbitrary session data. Thus, one only has permission to see one's own session data. Again, session handling should be transparent, implemented by a mechanism that implements its own special purpose access policy (access to session data only by the session owner). No such policy is necessary, since access to the session data objects themselves is gated. You can't get to the session object unless you have management rights on the session data manager itself, or if the session data object is for "your" session -- the session for the current REQUEST. Once you have retrieved that session data object, what you can do with it is entirely dependent on what the object is. For example, a shopping cart object might grant Anonymous users access to place or remove items in it. Other types of session data objects might grant permissions to record click-tracking data, but not to view it. Nonetheless, most of these permissions issues are moot under normal circumstances, unless you are granting anonymous users the ability to create DTML or other executable methods in your site. Session data objects are not directly accessible through the web under normal circumstances without management access to the session data manager object. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking proposal
"Phillip J. Eby" wrote: Thus, by setting the browser ID lifetime to at least as long as the longest session, one avoids having multiple cookies, one per session manager. This is a good point and one that I probably didn't make clear in the use cases.. it's entirely possible to have a site with hundreds of session data managers. Each session data manager may implement its own policy as regards session data object expiry the type of session data object(s) it returns, as well as the storage of these session data objects. The point of the "browser id manager" is to handle the requirement to identify visitors between requests on behalf of all the session data managers in the system, as opposed to requiring each data manager to handle this identification. Thus, only one identifer need be used for all the session data managers in a system. However, as prompted by a Digital Creations "jam session", there are going to be changes to the use cases which actually make the "Browser Id Manager" into a "Session Id Manager" which will generate a "session token" that will carry both a "browser id" (meant to semipermanent) *and* a "session key" (meant to exist for the duration of a "session" as bounded by a "global" timeout period). This is purely an implementation detail, driven by the somewhat specious requirement that we allow people to associate a "session" bounded by one session data manager with a "session" bounded by another in the same system. (The implementation is also driven by my reluctance to store session key state related to a browserid inside Zope itself... it could be handled internally, but I've decided to put the "session" state on the client instead, it's easier). This will be an opt-in feature for session data manager implementations, and does not change much of the underlying principle of having a potentially "semipermanent" browser id. Contributed session data managers will be free to ignore the (oft-changing) session key component of the session token, and will be free to implement their own session expiry policies related only to the browser id component of the session token. However, it also means that session tokens (which replace browser ids as a identification value) will be prone to change much more frequently, as a new session token will be constructed every time the "global" session timeout expires, and it will contain both the "browser key" (potentially recycled out of a received token) and a new "session key". This may actually be beneficial (in some twisted, baroque way :-), because it means that people will be less tempted to set the cookie expiry time far into the future, as the cookie will be reset more often. * I am *VERY* suspicious whenever I get a cookie with an expiration date more than a few days in the future. If Zope tries to implement long living browser ids, I fear, Zope sites will have a high chance, I will no longer visit them. The actual lifetime of a browser ID will be controllable by the Zope site manager. I agree with you, however, in that the default lifetime should be reasonable. Indeed, I would suggest that the default simply be to use cookies with no expiration date, and which therefore only live so long as the user's browser is open, be it minutes or days. This sounds like a reasonable default. * I do not think "Annonymous" should have "Access Session Data" permission with the exception to its own session data. As I understand it, the "Access Session Data" permission gives you the right to call a method that returns you the session data for the current request, but does not give you the right to access arbitrary session data. Thus, one only has permission to see one's own session data. This is true. If you can guess (or steal) someone else's session token, however, you will be able to access the site "as that user", though you still will not be able to arbitrarily view session data object contents, only what is shown by the application code. I think Dieter's comments point out that the overarching requirement that sessioning be useful in the context of anonymity is at odds with the desire to lock down access to the data referenced by a session identifier. I will need to spell out very clearly in the user docs that session data not be used to store intensely sensitive information. -- Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
