The formupload/ service expects a username and pasword to be
sent in the form of form variables. However, the password is
completely ignored and instead the service will use the
Authorization header username and password (in the variables
r_user and r_pw) to do CMS authentication.

This raises two issues:

- Why send the password at all and risk exposing it if it is
then ignored.

- Plone generally uses cookie-based authentication, so
clients don't have a HTTP Auth header ready, nor will a
typical Plone user know what to do with the auth box here.

I propose two solutions:

1. Stop requiring the upload form to send the user's
password along. Instead, add a Plone formupload service that
does authentication based on the same cookie the
cookiecrumbler expects for Zope authentications; it contains
the same information anyway.

2. Start using the username and password in the form to
authenticate against the CMS.

Solution 1. has as a disadvantage that it complicates setups
with the railroad repository on a seperate server; cookies
and especially authentication headers don't travel well
across URLs. The advantage is that you can get rid of the
insecure use off passwords embedded in forms.

Solution 2. is what you probably intended in the first place
:) You could optionally fall back to basic-auth headers if
the password was not included in the form data. This way you
offer implementors an option on how secure they want to be.