Re: [Hypercontent-users] download zip facility
Brought to you by:
alexvigdor
From: tom t. <j_l...@ya...> - 2007-09-04 01:11:39
|
Hi Alex, I removed the workflow-date directory and redeployed the app, then everything started working, This includes your patch as well, Now the publishers can download, but I am not going to give the read permissions to config,dtd directories, because the intention is publishers should be able to take the backup of the entire content excluding configuration data, taking the backup of the entire site including the configuration data is Admis task, Let me now if there is a issue with this. Thanks, --- tom tom <j_l...@ya...> wrote: > Hi Alex, > > I updated my file and deployed again, still it is > not > working, it got rid of the error message, but it > just > shows the please-wait file, now even for admin it > doenst work, when I click more details it shows the > following. > > History > 9/4/07 9:46:24 AM > Download Zip > by you > Current Queues > /workflow-data/queues/zip/zipping > /workflow-data/queues/principal/spAdmin > Attributes > href = > http://localhost/hypercontent/screens/please-wait.html > zipper = Admin > > > > The strange thing is I did revert it back to the > original and tried as Admin, now that also not > working, > It shows the same above page, It looks to be it get > cashed somewhere else. I removed everything and > redeployed but result is the same. I can't figure it > out what is going on, shall I remove workflow-data > and > try? > > > > --- Alex Vigdor <al...@bi...> wrote: > > > You can get it using CVS with anonymous access, or > > from the CVS web > > browser at > > > > > http://hypercontent.cvs.sourceforge.net/hypercontent/hypercontent2/ > > > > > source/org/hypercontent/workflow/exec/impl/ZippingExecutable.java > > > > Alex > > > > On Aug 30, 2007, at 11:08 PM, tom tom wrote: > > > > > Hi, > > > > > > Can you let me know the location to download > with > > > username and password. > > > > > > Thanks > > > > > > --- Alex Vigdor <al...@bi...> wrote: > > > > > >> Hi, > > >> OK, you found a real bug there! I checked in > > the > > >> fix to > > >> > > >> > > > > > > org.hypercontent.workflow.exec.impl.ZippingExecutable > > >> > > >> The bug would have kept anyone who is not an > > admin > > >> from downloading a > > >> zip. > > >> > > >> However, users will still only be able to zip > > files > > >> and directories > > >> for which they have read permission. And to be > > >> clear, this permission: > > >> > > >> <permission principal="group:publishers" > > >> target="/**/" activity="read"/> > > >> > > >> does NOT override > > >> > > >> <permission principal="group:anybody" > > >> target="/config/**/" activity="read" > > >> denied="true"/> > > >> > > >> See my explanation again of precedence in > > >> permissions: more specific > > >> targets are given higher weight than more > > specific > > >> groups. So this > > >> permission: > > >> > > >> <permission principal="group:publishers" > > >> target="/config/**/" activity="read"/> > > >> > > >> DOES override > > >> > > >> <permission principal="group:anybody" > > >> target="/config/**/" activity="read" > > >> denied="true"/> > > >> > > >> > > >> Cheers, > > >> Alex > > >> > > >> > > >> > > >> On Aug 29, 2007, at 11:41 PM, tom tom wrote: > > >> > > >>> Hi Alex, > > >>> > > >>> I tried many possibilities but failed. see my > > >>> observations below, > > >>> > > >>> I dont want everybody to see the configuration > > >>> directories, that is why I am having those > > >> denied=true > > >>> for those targets, but the thing which I can't > > >>> understand is as we have the following > shouldnt > > >> this > > >>> overide the top level permissions. > > >>> > > >>> <permission principal="group:publishers" > > >>> target="/**/" activity="read"/> > > >>> > > >>> <permission principal="group:publishers" > > >>> target="/**/*.*" activity="read"/> > > >>> > > >>> > > >>> As the above failed I did overide all the > > >> denied=true > > >>> entries in the publisher group to have the > read > > >>> rights, > > >>> but that also failed. This is what you > > >> recommended. > > >>> > > >>> In the end I removed all the top denied=true > > >> entries, > > >>> e.g > > >>> <permission principal="group:anybody" > > >>> target="/config/**/" activity="read" > > >> denied="true"/> > > >>> > > >>> but still it fails. > > >>> > > >>> If I go to a specific directory and try to zip > > >> which > > >>> has not been restricted, still it shows the > same > > >>> problem. > > >>> > > >>> Can you try this in your environment.? I have > a > > >>> feeling something wrong some where, let me > know > > if > > >> you > > >>> want to see my zip.xml > > >>> > > >>> Thanks, > > >>> > > >>> > > >>> > > >>> > > >>> > > >>>> It could have something to do with your > > >> permissions > > >>>> setup. HC has > > >>>> to resolve conflicting permissions in two > ways: > > >>>> those which have a > > >>>> more specific target, and those which have a > > more > > >>>> specific group. It > > >>>> evaluates them in that order, so that a more > > >>>> specific target is > > >>>> honored over a more specific group. In your > > >> case, > > >>>> that means > > >>>> publishers are inheriting "denied" read > > >> permissions > > >>>> for design, xsl, > > >>>> config and dtd from group:anybody; however if > > you > > >>>> assign > > >>>> group:publishers read for any of those > targets, > > >> the > > >>>> more specific > > >>>> group of publishers will take precedence. > > >>>> > > >>>> Alex > === message truncated === ____________________________________________________________________________________ Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. http://autos.yahoo.com/carfinder/ |