[pca] RFE: pca-proxy.cgi without stored credentials

[Sebastian Kayser]

* Martin Paul <martin at par.univie.ac.at> wrote:
> >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:

Yay, that was quick. :) Feedback inline.

> 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.

Sounds like a very flexible, architectural decision. Maybe with an
exclusion list for certain variables like xrefdir/patchdir? Or the other
way round, an explicit inclusion list. People might be concernced about
external requests setting xrefdir/patchdir. I know, this should be
addressed by least privileges for the pca-proxy.cgi, but it still might
be something to think about.

> 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).

This works. 40X in the long run would be nice as it looks less
error-like from a user-perspective.

$ ./pca -ad 125138
...
Looking for 125138-18 (1/1)
Trying http://pcahost/cgi-bin/pca-proxy.cgi?
Failed (Error 500: Internal Server Error)


> 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.

Mhh, seems as if the 2nd attempt is going straight to sunsolve.sun.com
in my case. Can't see any further HTTP traffic on my pca proxy host
after the 1st denied request.

Please enter Sun Online Account User: XXX
Please enter Sun Online Account Password: 

Trying https://sunsolve.sun.com/ (1/1)

> 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.

Thanks! See above.

> 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.

+1

Sebastian