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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.