Hi Sebastian,
Couldn't you just use a "custom" authentication scheme to handle auth
between pca-proxy.cgi and pca?
You pointed me at HTTP custom headers, which are made available to the
CGI script by Apache via environment variables - that's a promising way
to get data from the client to the proxy in a simple way. As for the
other direction, standard HTTP response should suffice.
I've made the following changes to the development version of pca:
When running as proxy, it reads options from HTTP_PCA_X_<option>, just
like regular pca already does with the PCA_<option> environment
variables. Like that, one could theoretically forward any option to the
proxy with custom HTTP headers, set by wget's "--header" option.
When pca-proxy.cgi tries to download a file from SunSolve and doesn't
have SOA data, it replies "500 SOA missing" to the client and quits (I
might change that to a 4xx code later, but the 500 is hardcoded right now).
When the client receives "500 SOA missing" from the proxy, and "askauth"
is set (on the client) it asks for SOA data and retries the request,
sending X_PCA_USER and X_PCA_PASSWD by HTTP headers. It's not necessary
to set "askauth" in pca-proxy.conf.
If user/passwd are set on the client (via command line or config file),
it will always be pushed to the proxy, overriding any possible SOA data
in pca-proxy.conf. I'm not sure yet whether this is the way to go, so it
might change.
I did some testing, and it seems to behave fine. If you can, please try
it as well. You need version 20091117-01 both on the client and the
proxy from http://www.par.univie.ac.at/solaris/pca/installation.html -
let me know how it works out for you.
BTW, I'm thinking about deprecating the "askauth" option completely.
Especially for new users it makes more sense to have a default of asking
for SOA data when contacting SunSolve instead of failing with an error.
I can't think of a real-world scenario where explicitely *not* setting
"askauth" (without setting user/passwd as well) makes sense.
Martin.
