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])
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
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
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
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
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
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 :-)
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]
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
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
,
--
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
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 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
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
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
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 ...
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
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
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
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
: 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
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
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
-
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
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.
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
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
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
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
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,
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
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
_.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
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
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
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
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
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
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
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
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
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
"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
43 matches
Mail list logo
