Re: WebDAV problem uploading in Plone 4 with a password
dieter <[email protected]>
| Newsgroups | gmane.comp.web.zope.plone.user |
|---|---|
| Message-ID | <[email protected]> |
Andrew Daviel <[email protected]> writes: > ... WebDAV access without authentication ... > When I look on the network, I can see that when I use the script to upload > a file that does exist, $dav->put does a PUT and gets > HTTP/1.1 401 Unauthorized > It then retries with > Authorization: Basic blahblah > and succeeds. > > But if the file does not exist, it gets > 500 Internal Server Error > to the initial PUT, and gives up. > > > The idea of trying a request without credentials, and then presenting the > credentials in a subsequent attempt after a 401 response, is quite common > and is referred to in RFC2616 section 10.4.2. So I believe this is a bug > in Plone, not in HTTP::DAV You may be right -- but it would be quite difficult to fix this in Plone. The problem lies quite deep: Plone has complex logic to decide what can or cannot be added at a specific point. Part of this - but only a part - is controlled by permissions. Plone has decided to implement the complex logic by first constructing the set of addable types and then check that the type to be added is in the list rather than directly verify for the type to be added whether is can be added. With this approach, Plone cannot report something like "I cannot add this type due to missing authentication", i.e. respond with an "Unauthorized" response; it has as only information "the type is not in the list of allowed types" without knowledge why it is not there. I assume that this implementation approach was chosen because the set of addable types is needed for other purposes as well (e.g. to present a list of types that can be added in the current context). Then it seemed to be natural to check whether a given type can be added by verifying whether it is in this list. However, for your case, you need not only know whether the type can or cannot be added in the current context but also whether authentication (rather than some type of configuration) prevents the adding. This is not relevant for the typical Plone usage (where a menu (constructed from the set of addable types) controls what you can add if you are not yet authenticated and do not see there what you want to add, you likely will authenticate). With these explanations, I expect that no "Products.ATContentTypes" developper (that is where the "type in set of allowed types" check is implemented) will start working on the issue. If you want to take up, the explanation sketches the way to proceed: You must break down the complex logic about addability of a type into an algorithm that directly works on the type without first constructing the set of allowed types. It must have three outcomes "addable", "not addable due to authentication limitation", "not addable for other reasons". ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk