You are not logged in Log in Join
You are here: Home » Members » ivo » Ivo's patches

Log in
Name

Password

 
 

Folder icon Ivo's patches

Every now and then I run into small problems with zope. I usually try to fix these with a patch which (hopefully) will make it into a next Zope release.

webdav anonymous login fix

As someone pointed out on #zope, it is possible to view folder contents using a webdav client as an anonymous user.

I.e. download cadaver, open yourzopeserver:8080 and do ls. Then decide if you want anyone to be able to access this. Eventhough hiding this information may be security by obscurity, there are some things you just don't want everyone to see.

This allows you to see, for example, the installed products on the server. A hacker might use this knowledge to exploit some known bug in a zope product if one exists.

Most people (like me) probably think it's harmless to let old objects, documents etc linger around as you can't view them in listings through ftp or http. They don't realize webdav is running by default. Actually, it can't even be disabled! (z2.py -X -w80 won't do the trick!)

Personally I'd rather see this secured. It's not possible to disable view contents information for anonymous users in zope, as this will ruin your entire site (all anonymous access will then be disabled), so the solution would be to create a new permission for access contents through webdav.

And that's what the following (trivial) patch does.

After applying you'll get a new permission in your security tab, which is set to manager by default. To get the old behaviour back, just set the permission back to anonymous.

Apply it using patch -p1 ../webdav.patch in your SOFTWARE_HOME (i.e. the Zope-2.3.2-src dir).

Or just edit lib/python/webdav/Resource.py by hand :)

I've tested it with Zope 2.3.2, I can't guarantee it will work with other versions (use at your own risk anyway).

You can find the patch here

dtml-in improvement/fix

When using batching in dtml-in, why is previous-sequence only defined at the first iteration of the current batch? And why is next-sequence only defined at the last iteration of the current batch?

This behaviour makes it difficult to display a batch like this:

-- begin sample --
Item N
Item N+1
Item N+2

(link to previous items) (link to next items)
end sample --

Because the code would be something like:

-- begin sample --
<dtml-in something start=query_start size=3>

[do something with sequence-item]

<dtml-if sequence-end> <!-- check if last item of batch --> <dtml-if previous-sequence> (link to previous items) </dtml-if> <dtml-if next-sequence> (link to next items) </dtml-if> </dtml-if> </dtml-in> -- end sample --

However, if your batchsize is larger than 1, previous-sequence will always be untrue at the last item (when next-sequence is true).

The only solution would be implement a second dtml-in after the first one purely for displaying the previous link.

Also, dtml-in would re-execute your "expr" (which it does not very efficiently),so if you want to avoid doing the "expr" twice, you'd have to store it temporarily using dtml-let (or my dtml-set tag ;).

The end result would be:

-- start sample --

<dtml-let foo="expr"> <dtml-in foo start=start_query size=3> [do something with sequence-item] </dtml-in> <dtml-in foo start=start_query size=3> <!-- code below is safe, as the variables are only true at the resp. top and end, though the truly paranoid could check for sequence-start / -end patch #1 below would break such code! --> <dtml-if sequence-end> <dtml-if previous-sequence> (link to previous items) </dtml-if> <dtml-if next-sequence> (link to next items) </dtml-if> </dtml-if> </dtml-in> </dtml-let>

-- end sample

And at this point I really would start to implement the batching myself in python :)

Of course, basically the same applies if you want both the previous/next link at the top of the batch display.

(Imagine you want both! :)

Either I'm missing something really obvious here, or the patches below make sense. There are two versions:

- patch #1: This version fixes the issue above by enabling the values of previous/next-sequence throughout the entire batch (and other related variables as well: X-sequence, X-sequence-start-index, X-sequence-end-index, X-sequence-size) (which may break existing sites), and

- patch #2: This version introduces new variablenames, leaving the behaviour of previous/next-sequence.

A third alternative would be to only define the variables at the top and bottom of the batch.

Both versions fix (I think) a grammatical error.

It's up to the DC guys if they feel like incorporating either of these patches in a next release :)

patch #1: define variables everywhere in the batch

This patch makes sure that the following variables are available through each iteration of dtml-in, for each item.

!!!!! This patch may break alot of dtml code !!!!!!

  • next-sequence
  • next-sequence-start-index
  • next-sequence-end-index
  • next-sequence-size
  • previous-sequence
  • previous-sequence-start-index
  • previous-sequence-end-index
  • previous-sequence-size

You can find the patch here

patch #2: introduce new variables

This patch introduces the variables

  • batch-next-sequence
  • batch-next-sequence-start-index
  • batch-next-sequence-end-index
  • batch-next-sequence-size
  • batch-previous-sequence
  • batch-previous-sequence-start-index
  • batch-previous-sequence-end-index
  • batch-previous-sequence-size

Which behave exactly the same as the variables withouth batch- in front, but these are available with each iteration/item of dtml-in, not just the first/last. This patch should not break any existing dtml code.

You can find the patch here

 Title   Type   Size   Modified   Status 
 default Edit object Software Release   2001-06-27 published