You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Jason Vas Dias <ja...@gmail.com> on 2011/04/06 16:52:38 UTC
[users@httpd] Re: denying access to SSI fragments
I don't understand why this question got no responses .
Surely it is not an unreasonable request to ask the server to support
SSI requests like :
\<\!\-\-\#include virtual\=\"include/head.html\"\-\-\>
without also exporting "include/*" to be available to HTTP/S requests ?
Of what meaning to users could a "head.html" or "footer.html" fragment be expected to be ?
I think httpd's SSI implementation is somewhat broken in that it appears impossible to include a fragment
without exposing the fragment to valid HTTP/S requests .
This is the main reason I use HTML::Mason's '$m->comp(...)" instead of SSI includes, which, IMHO,
SHOULD be a useful httpd feature, but ISN'T , for the above reason.
What I've ended up having to do to allow non-Mason html pages to include fragments with SSI without exposing the
fragments to users is to write a "handler" in "C" for all "include/*" content that parses internal Apache data structures
to see if the request orginated with an "SSI" , and only if it did, returns the content .
If anyone else would find such a handler module useful, I'll post it here - otherwise can anyone explain how else to set
up apache to allow SSI requests but NOT allow HTTP/S requests for a fragment ?
Thanks in advance for any responses (which I really do not expect to receive after all this time on this issue ! )
and thanks for giving the world its best HTTP/S server
Regards, Jason
On Monday 13 September 2010 16:05:48 Jason Vas Dias wrote:
> Sorry if this question has been answered somewhere else before,
> but searches of your site and google yielded nothing relevant.
>
> How can I deny access to fragments that are included with
> server-side-includes (SSI) , ie. I want to be able to include
> a fragment:
> '<!--#include virtual="/include/a_fragment"-->
> in an html page, but I don't want users to be able to request
> '/include/a_fragment' .
> on its own ?
>
> All my attempts to do this by specifying access control on my
> '/include/' directory fail, because the SSI #include request is itself denied,
> even though the request is coming internally from the server,
> not from not an external user .
>
> I've tried specifying the include directory as :
> '<Directory /include/>
> ...
> Deny from all;
> '</Directory>'
> and
> '<Directory /include/>
> ...
> Order Deny, Allow;
> Deny from all;
> Allow from 127.0.0.0/8;
> '</Directory>'
> but both deny the SSI include requests as well as the external requests.
>
> Why must SSI include requests use the same originating IP details as the request
> for the whole page, since they are internal "request"s originating in the server ?
>
> Can anyone suggest a way of denying access to '/include/*' from external users,
> while allowing '/include/*' to be targets of SSI #include requests ?
>
> Thanks in advance for any responses,
>
> Regards,
> Jason Vas Dias <ja...@gmail.com>
>
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: denying access to SSI fragments
Posted by Eric Covener <co...@gmail.com>.
> I still don't see how else to overcome this problem with apache's SSI.
I think in general it is not perceived as a problem that fragments of
pages are directly accessible.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: denying access to SSI fragments
Posted by Eric Covener <co...@gmail.com>.
> AddHandler ssi-fragment ".inc" ".ssi"
Another back might be to use mod_rewrite and ensure your fragments are
only accessible via subrequests.
--
Eric Covener
covener@gmail.com
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: denying access to SSI fragments
Posted by Eric Covener <co...@gmail.com>.
On Wed, Apr 6, 2011 at 12:05 PM, Jason Vas Dias
<ja...@gmail.com> wrote:
> On Wednesday 06 April 2011 16:22:46 Eric Covener wrote:
>> > Yes, but even with "file" the server will still "serve" those files and they must still be "accessable"
>> > to HTTP/S requests -
>>
>> It will serve them (outside of SSI) if you configure it to, but I
>> don't see it as a requirement as it is with virtual.
>>
>
> Yes, but if my $some_dir is outside of any <Directory ...> I can't include it - the url gets prefixed with whatever <Directory > the document the user originally requested was in,
> because EVERY page on my site uses relative URLs to access site pages - it so simplifies re-basing - and if it's inside a <Directory ...> ,
Sorry, assumed #include file= wasn't relative-only.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: denying access to SSI fragments
Posted by Jason Vas Dias <ja...@gmail.com>.
On Wednesday 06 April 2011 16:22:46 Eric Covener wrote:
> > Yes, but even with "file" the server will still "serve" those files and they must still be "accessable"
> > to HTTP/S requests -
>
> It will serve them (outside of SSI) if you configure it to, but I
> don't see it as a requirement as it is with virtual.
>
Yes, but if my $some_dir is outside of any <Directory ...> I can't include it - the url gets prefixed with whatever <Directory > the document the user originally requested was in,
because EVERY page on my site uses relative URLs to access site pages - it so simplifies re-basing - and if it's inside a <Directory ...> , users can request it, and you cannot create
another Sub <Directory > for it and then say 'deny from all' for that sub-directory because then SSI includes are denied .
So I create a handler :
AddHandler ssi-fragment ".inc" ".ssi"
and
<Directory "/var/www/my_site" ...> ...
</Directory>
Alias "include/" "/var/www/include/"
<Directory "/var/www/include" ...>
SetHandler ssi-fragment
allow from all
</Directory>
and my fragments are all named ".inc" , and ALL files under /var/www/include have the ".inc" extension ,
and "ssi-fragment" is a c shared-library module that determines if the request came from SSI or not;
if it did, it completes the request, and if it did not, aborts the request with 403 (forbidden).
I still don't see how else to overcome this problem with apache's SSI.
All the best,
Jason
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: denying access to SSI fragments
Posted by Eric Covener <co...@gmail.com>.
> Yes, but even with "file" the server will still "serve" those files and they must still be "accessable"
> to HTTP/S requests -
It will serve them (outside of SSI) if you configure it to, but I
don't see it as a requirement as it is with virtual.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: denying access to SSI fragments
Posted by Jason Vas Dias <ja...@gmail.com>.
On Wednesday 06 April 2011 15:58:29 you wrote:
> On Wed, Apr 6, 2011 at 10:52 AM, Jason Vas Dias
> <ja...@gmail.com> wrote:
> > I don't understand why this question got no responses .
> >
> > Surely it is not an unreasonable request to ask the server to support
> > SSI requests like :
> > \<\!\-\-\#include virtual\=\"include/head.html\"\-\-\>
> > without also exporting "include/*" to be available to HTTP/S requests ?
> >
> > Of what meaning to users could a "head.html" or "footer.html" fragment be expected to be ?
>
> Virtual treats it like a normal request for that URL, so I would
> expect it to be an otherwise valid URL for a client. "file" is an
> alternative.
>
Thanks for your response Eric !
Yes, but even with "file" the server will still "serve" those files and they must still be "accessable"
to HTTP/S requests - I remember testing this a long time ago I was still able to send an HTTP
request for files included with "file" - the difference being that I lose the potential for file to be
a cgi script and to get access to special SSI variables ? Or am I missing something ?
ie a DocumentRoot /www/ file contains:
<!--#include (virtual or file)="some_dir/a_fragment"-->
The user must be "granted" read access to "some_dir" and to "some_dir/a_fragment" - I don't
see how to overcome this except by a custom handler for "some_dir/" - or am I just a stupid
apache novice ?
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: denying access to SSI fragments
Posted by Eric Covener <co...@gmail.com>.
On Wed, Apr 6, 2011 at 10:52 AM, Jason Vas Dias
<ja...@gmail.com> wrote:
> I don't understand why this question got no responses .
>
> Surely it is not an unreasonable request to ask the server to support
> SSI requests like :
> \<\!\-\-\#include virtual\=\"include/head.html\"\-\-\>
> without also exporting "include/*" to be available to HTTP/S requests ?
>
> Of what meaning to users could a "head.html" or "footer.html" fragment be expected to be ?
Virtual treats it like a normal request for that URL, so I would
expect it to be an otherwise valid URL for a client. "file" is an
alternative.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org