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 )
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 )
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 )
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 )
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 )
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 )
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 )
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 )
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 )