October 2000 - Zope-Dev

Re: [Zope-dev] Need help tracking down the cause of a traceback
by Dieter Maurer 04 Oct '00

04 Oct '00

Hi Skip, Skip Montanaro writes: > > I occasionally get tracebacks like > > No input for required field > .... > File /home/dolphin/skip/src/Zope/lib/python/ZPublisher/HTTPRequest.py, line 445, in processInputs > File /home/dolphin/skip/src/Zope/lib/python/ZPublisher/Converters.py, line 115, in field2required > ValueError: (see above) > > The ValueError is being raised in field2required, but I see no parameters in > the Apache log with a name of "...:required". That leads me to suspect that > somehow the RESPONSE parameter isn't getting set (it's the only > non-defaulted parameter in the suspect published methods that doesn't appear > to have its value set directly by parameters in the URL). I suspect the problem comes from a "POST" operation. You will not see POST operation parameters in the web server log files. It is highly unlikely that a missing RESPONSE causes the problem. Such an error would be handled at a different place (I think in "mapply"). At line 444 of "ZPublisher/HTTPRequest.py", you will see the following code: if flags&CONVERTED: try: item=converter(item) except: if (not item and not (flags&DEFAULT) and defaults.has_key(key)): item = defaults[key] if flags&RECORD: item=getattr(item,attr) if flags&RECORDS: item.reverse() item = item[0] item=getattr(item,attr) else: raise Add "print key; sys.stdout.flush()" before the final "raise". This will print the corresponding "key" (with is missing). To get more information: the variable "fslist" contains all parameters. It is a list of objects. Each object has a "name" attribute (which gives the form variable name or 'key'), the object either has a "file" or "value" attribute. You may look at line 370, to see how it is processed. You can test your debugging code in your test environment. Simply create a form with a "xxx:required" variable name and do not provide a value. Dieter

1 0

Re: CoreSessionTracking proposal
by gotcha＠swing.be 04 Oct '00

04 Oct '00

--- In zope(a)egroups.com, "Chris McDonough" <chrism@d...> wrote: > Without a client-checking scheme (such as encoding the IP address in the > token), a token theft attack is very easy. As voiced by others in the > thread, client-checking is not reliable, should not be a default, and maybe > shouldn't be included as an option at all. > I would like to control finely the session security mechanisms. I would like to be able to plug a client-checking (or anything else). This way, each WebApp developper can discriminate among its own constraints and risks. I want to be able to use different ways to secure the session. For example, ther would be cases where I would implement a client-checking mechanism based on both IP address and browser time-limited cookie. This would allow me to follow sessions on people refusing cookies and on people behind "IP dancing" proxies. I would loose session state for anyone both refusing browser cookie and being behind "IP dancing" proxy. This would be an acceptable compromise if I am manipulating highly private data. In other cases, I could accept lower-level security related to the less privacy. Godefroid Chapelle --------------------- BubbleNet sprl rue Victor Horta 30 1348 Louvain-la-Neuve Belgium --------------------------------------------------------------------- This mail sent through SwinG Webmail: http://mail.swing.be

1 0

ZCatalog uniqueValuesFor() cached?
by Brett Carter 04 Oct '00

04 Oct '00

How can I update the uniqueValuesFor()? Whenever I delete one of my ZCatalog-aware zclasses, they are still returned in uniqueValuesFor. What gives? is this cached or something? -Brett

2 1

Need help tracking down the cause of a traceback
by Skip Montanaro 04 Oct '00

04 Oct '00

I occasionally get tracebacks like No input for required field  mailed to me from my production web server (5-10 times per day). I have been so far unable to figure out what request is coming into Zope that is triggering it by examining the Zope and Apache server logs (I run Zope behind an Apache proxy). Every time I search the log files in the vicinity of the mail message's timestamp, I see nothing wrong. I would like to instrument the Zope code to generate a traceback that has a more useful message than "(see above)". The ValueError is being raised in field2required, but I see no parameters in the Apache log with a name of "...:required". That leads me to suspect that somehow the RESPONSE parameter isn't getting set (it's the only non-defaulted parameter in the suspect published methods that doesn't appear to have its value set directly by parameters in the URL). I am completely unfamiliar with the code involved in the above traceback, and only get such tracebacks on my production server, so I need to get it right the first time. (If I muff it, it will almost certainly not break until right after have watched it for 10 hours, then left for the day, allowing the server to choke for 12-15 hours before I come in the next day...) I'd like to enclose one of the calls in the above traceback in a try: ... except ValueError: ... statement whose except clause reraises the exception with the relevant data that will tell me just what method was invoked and what parameters, if any, it's receiving. I think the HTTPRequest class probably contains the useful bits, but I have no idea what those bits might be. (What is the saying about things that are sufficiently subtle appear to be magic to the observer?) Thanks, -- Skip Montanaro (skip(a)mojam.com) http://www.mojam.com/ http://www.musi-cal.com/

1 0

CoreSessionTracking - "Access Session Data" permission
by Dieter Maurer 03 Oct '00

03 Oct '00

Hi Chris, in an earlier message, you defended the existence of a separate permission "Access Session Data" (in the CoreSessionTracking proposal) by the following case: There may be (authenticated) users with (TTF?) scripting rights that should be prevented to screen session data (by withdrawing the "Access Session Data" permission from them). This will only be effective, when not all users automatically have the "Anonymous" role. There was a discussion about the "Anonymous" role some months ago in the list: * The (outdated) Content Manager Guide mentions that any user has the role "Anonymous". * A role "Anonymous" with the meaning "not authenticated" will make management for sites with authenticated, non-manager users more difficult, as those users should have most rights of "Anonymous". Only in exceptional cases, e.g. for session data, they will have less priviledges. If the meaning of "Anonymous" changes in this direction, then this role should be explicitely assignable to users in the "Change User" view to avoid such difficulties. I would be much in favour of a solution that does not entail new permissions. This would be possible, if session id management and access to session data would be melted together. In the current proposal, both are separate modules linked by the application: the application obtains a session id from the id manager and then accesses the session data, usually with the id, but in principle with anything it likes, e.g. a stolen session id. It seems that the new permissions should help to control such abuses. If the session id becomes an implicit (not DTML-forgable) parameter for session data access, then the session data need not to be protected by new permissions. However, I agree with you, that even making session id management implicit, will not provide strict security. Why am I against new permissions? This has partly to do with the current Zope permission management. As soon as you have more than a few products installed and created a few additional roles, permission management becomes a nightmare: it is very difficult to keep the overview with the current unstructured, non-batched permission setting view. Dieter

2 1

RE: [Zope-dev] Re: CoreSessionTracking proposal
by Toby Dickenson 03 Oct '00

03 Oct '00

Chris Wrote: > yeah, but have you ever tried to have two copies of a tree open on the > same data? That problem wouldnt arise if the page containing the tree tag used a URLDataSessionManager ;-) A different Chris Wrote: > Hmmm. Please smack me if I'm wrong, but I'm not clear on how it differs > much from not keeping session-related data in the token. I guess you could > argue that a session token that holds application data is "more random" due > to the nature of its composition, and due to that it can't be "guessed" as > easily (I doubt anyone would even try). One of the purposes of the random > element of the session token in the current implementation is to address > this "token guessing" risk. Agreed. With a large session-key the guessing game is hard. When storing session data in the URL it is theoretically impossible. Some people might find this appealing. (not me) > But all of these ponderings are kind of moot, because session > data can be > arbitrarily large (session data on the order of a megabyte > will probably not > be uncommon), so the data can't realistically be embedded in the token > anyway. Agreed, in-URL session data is not a universal solution. Im definitely only interested in implementing this as an *alternative* SessionManager, and I am aware of these limitations. > > Its also the only sensible option that lets you bookmark > your place in a > > session, and return to it much later (which interests me more). > > I don't understand what you mean... a session token that > doesn't include > application data has the same property. That's essentially > its reason for > being around at all. (If you're concerned that the session > token isn't > URL-compatible, it is... the current implementation lets the > session token > be transferred via a query string, inlined URL elements, or > as a cookie > value). Parts of the token *never* expire, so you can > happily bookmark > something with a token value embedded (or receive and > continue to resend a > persistent cookie). What about the scenario.... 1. I have a half full shopping cart (or a half opened tree tag) 2. I bookmark that half full cart. 3. I fill up the cart, but then change my mind. 4. I return to the bookmarked page - do I go to A. the half full cart from step 2, or B. the full cart from step 3? 5. I return to the bookmarked page 12 months later - do I go to C. the half full cart from step 2, or D. the full cart from step 3, or E. an empty cart, because the session cache had been purged. I guess B D and E all make sense in the context of a shopping cart (feel free to disagree; Im not too hot on shopping cart usability) I'm currently using a fremework built around in-url data to maintain the state of a sophisticated View (as in an M-V-C idiom). Options A and C are essential, since users need the ability to bookmark a view and return to it later. However most views are transient, just intermediate views on the way to the view that they want to keep. I dont have the storage on the server to indefinitely record every view that has ever been seen, however the server has no way of knowing which views have been bookmarked. The only option is to store all view state on the client, inside the bookmarked url. Being able to use a SessionManager to integrate a (rewritten) tree tag into my rich views is appealing.

2 1

'REQUEST' lost on DTML rendering
by kent＠tiamat.goathill.org 03 Oct '00

03 Oct '00

I have a Product which works fine under Zope 2.1.6 but am having trouble moving it to 2.2.1 This product creates temporary instances of objects and then uses __bobo_traverse__ to traverse class operators specified in the URL which create the objects that are rendered via DTML methods. The very first time one of these objects is called (after tehe server is started), all works fine. With all subsequest calls, the DTML methods which render the results cannot locate the REQUEST dictionary anymore. My class methods can still see the REQUEST dictionary just fine with every call, but REQUEST apparently gets lost between when the bobo_traverse returns and when the DTML renderer starts. (and yes, this all worked fine prior to 2.2x :^) I'm stumped. How could the REQUEST object get passed the first time to the DTML renderer and never thereafter? What changed thereabouts? Thanks

1 1

Zope URL
by Kenneth Latta 03 Oct '00

03 Oct '00

I do not want to connect to the Intranet using the server port (8080) in the URL to access the Zope pages . The problem you have is related to the sockets. Zope has it's port set to 8080 as a default just to make it easier to coexist with IIS. The default for the http service is port 80. If you want to use <http://smt/manage> http://smt/manage You will have to have your IIS changed to run on another port instead of the default, and then change Zope to run on port 80. But folks who don't know and just try to visit your site at <http://smt> http://smt will get the default page served by the Zope server not your IIS server. (Of course you could removed the less capable web server software...;-} ) You can not have both servers on the same port. So you probably will need to redo the install settings for both IIS and Zope. A Windows-only fix would be to change the registry setting used for the default http service to 8080. But this won't make the two services coexist on one port. Ports Port Number HTTP 80 FTP 21 GOPHER 70 SSL 443 If you want to use other port numbers, you can change them through the Registry. Start RegEdit and go to the key HKEY_LOCAL_MACHINE\System\CurrentControlSet\ control\ServiceProvider\ServiceTypes . In the W3svc subkey you'll find a hexidecimal value named TcpPort. Change this to the port number you want to use. Fo r example, if you want to use port 81, set the value to 51 (51 hex is 81 decimal). Similarly, you can set the FTP port in the MSFTPSVC subkey. Ken Latta Invictus Systems Corporation <mailto:klatta@invictus63.com> klatta(a)invictus63.com

1 0

Re: [Zope-dev] rpc-xml: Pachyderm memories needed !
by Dieter Maurer 03 Oct '00

03 Oct '00

Nigel Head writes: > .... > I'll swear that a couple of weeks back, just after I got the Flash 5 upgrade I > had this running with whatever version of Zope was extant then! Unfortunately > I've been following along with the CVS checkouts without archiving them so I > can't prove it. CVS supports checkout by date. Thus, you can recreate the former state from the CVS repository, provided you know when you got the working version. Dieter

1 0

(no subject)
by ralf.herold＠charite.de 03 Oct '00

03 Oct '00

Dear list readers, using LocalFS 0.95 war fine until trying to upgrade to Zope 2.2.2. Both freshly installed, the following snippet raises the error: "Unauthorized", "You are not authorized to access read.": <dtml-var standard_html_header> <dtml-var "frei['analog.html'].read()"> <dtml-var standard_html_footer> It is used to display site statistics contained in analog.html, which resides in a local directory referenced by LocalFS under the name "frei" (cf. LocalFS-HowTo). There is no special security setting for the read-method, as for as the security tab is concerned. Also, as a user with all possible permissions, the error still occurs. The same file can seamlessly be read in a Zope 2.2.b1 installation on the same machine, under the same user. LocalFS's author Jonothan Farr (mailto:jfarr@real.com) suggested to ask on zope-dev: Could you help, please? Thanks in advance, --- Ralf Herold, mailto:ralf.herold@charite.de

1 0