[MacPerl] FYI: More on allow/deny

[Yanni <jon@aggroup.com>]

-jon

------ Forwarded Message
In revisiting the allow/deny issue with CGIs, it seems we have a bit of a
problem and it is strictly documentation-related. I've looked all over the
net for this info and only found a terse mention of how the "action"
parameter works in CGIs. See
<http://www.biap.com/datapig/mrwheat/cgi_params.html> for a description of
this paramter. For those of you with the Wiederspan/Shotton book, check
page 250.

The behavior of the "action" field was greatly enhanced after much user
prodding as part of the 1.2.3/1.2.4 update last winter. As far as I can
tell, every shred of StarNine documentation on this update to the action
parameter fell out of the distribution archive somewhere in the release
process.

So, allow/deny stuff "appears" to be broken because we didn't clearly
communicate to developers of CGIs how it's supposed to work now. Our fault.
So, here's a quick summary.

Ever since the ability was added to WebSTAR to allow CGIs, ACGIs, actions
and (soon) plug-ins to be specified as one of the special files (e.g.,
INDEX, NOACCESS, ERROR, etc.), it's been necessary to allow these same file
types to be executed independently of the allow/deny settings on the
server. This is because WebSTAR may need to run a CGI or plug-in as part of
executing the action associated with the file name in the NOACCESS or ERROR
setting. A classic example of this afflicts NetCloak users who have all
their HTML documents cloaked. If their NOACCESS file is noacess.html, for
example, NetCloak will STILL be invoked to process the no-access action for
the HTML file specified in the WebSTAR settings. This is where things run
off the rails a bit and I'll let John O'Fallon follow up on this issue and
how it affects NetCloak. In short, some CGIs ignore the action parameter
and still serve the document specified in the script_name field. Not good.

Anyway, the feature that was added to WebSTAR for CGI authors (and ACGIs,
etc.) was to use the "action" parameter sent to their app as a way to
indicate what sort of action the CGI is supposed to perform. Normally, the
action field contains the string "CGI" or "ACGI" if the CGI was invoked
directly with a URL like /yourapp.cgi or /yourapp.acgi. If, on the
otherhand, you have an action defined that specifies your CGI as the action
path (say the action is "FOO", with suffix mappings for .foobar), the
"action" parameter will contain the string "FOO".

In special cases, your CGI or plug-in may be called upon to operate on a
file (as an action) that was specified as one of WebSTAR's "special" files.
In the case of NOACCESS, your CGI would receive the string "NOACCESS" in
the action field. Your CGI is *obligated* to pay attention to this field if
you ever expect that your CGI will be used as a processor for one of the
special files. In this example, if you received "NOACCESS" in the action
parameter and chose to ignore it, you'd end up serving the file specified
in the "script_name" parameter as usual, which would be incredibly wrong
since WebSTAR just told your CGI that access had been denied to the file.
And it appears that several CGIs do in fact behave this way.

The bottom line is that CGIs which serve data through themselves in
response to URLs that invoke them as an action (or even as a normal CGI
with path args) should definitely check the contents of the "action"
parameter. If it contains "NOACCESS", you should not return the requested
document. Instead, you should emit an appropriate "refused" header and
return it to WebSTAR.

This unfortunate lapse in the documentation is not going to be easy to
correct quickly. But I encourage CGI developers to take a look at their
code and see if it's ever possible for someone to ask for a file and get it
when they shouldn't. In the meantime, we're open to suggestions about how
to disseminate this information as quickly as possible to the people that
need it...

C.

--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Chuck Shotton                               StarNine Technologies, Inc.
chuck@starnine.com                             http://www.starnine.com/
cshotton@biap.com                                  http://www.biap.com/
                      "What? Me? WebSTAR?"






------ End of Forwarded Message

Jon (no h) S. Stevens        yanni@clearink.com
ClearInk WebMagus      http://www.clearink.com/
finger pgp@sparc.clearink.com for pgp pub key
If that sentence didn't seem to make sense, that's because it didn't.