[tahoe-lafs-trac-stream] [tahoe-lafs] #1425: blacklist support

[tahoe-lafs]

#1425: blacklist support
-----------------------------------+-------------------------------------
     Reporter:  warner             |      Owner:  warner
         Type:  enhancement        |     Status:  new
     Priority:  major              |  Milestone:  1.9.0
    Component:  code-frontend-web  |    Version:  1.8.2
   Resolution:                     |   Keywords:  blacklist review-needed
Launchpad Bug:                     |
-----------------------------------+-------------------------------------

Comment (by davidsarah):

 Replying to [comment:19 warner]:
 > hrm, one wrinkle that's somehow bypassing tests meant to catch it: if
 you blacklist a file, access it (and get the error), then unblacklist it,
 the next access still throws an error. An obvious downside of
 monkeypatching to replace {{{Node.read}}} is that the Node might stick
 around: in this case in the nodemaker's cache (although that's a
 {{{WeakValueDictionary}}} so there must be something else holding on to
 it).
 >
 > The safest approach (at least one that would let you unblacklist things
 quickly) would be to do the blacklist check on each call to read(), rather
 than replacing read() with a function that always throws an exception.

 [attachment:blacklist4.darcs.patch] solves this problem because the
 nodemaker will cache the original node object, not the !ProhibitedNode
 wrapper. A node will get wrapped with !ProhibitedNode on each request
 depending on whether or not it is blacklisted at that request.

 A slightly odd side-effect of this patch is that prohibited directories
 will be treated a little more like files. This is actually quite useful
 because it prevents recursive operations from trying to traverse them.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1425#comment:21>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage