Why no SSI for Showroom Customers?
Brian {Hamilton Kelly}
stu...@ecs-tech.removethis.com writes:
> Why as a Showroom and Super Showroom customer shelling out hundreds of
> pounds on a web server do I find that the Apache web server that Demon
> offers has SSI (Server Side Includes) disabled?
>
> As a standard feature for modern web servers I was amazed to find it not
> enabled.
>
> A quick call to technical support got me a confused message. One of Demons
> technical people said it was a security issue. Well that's NOT right as
> Demon.net uses the SSI function itself on its own site!
>
> http://www.demon.net/products/hosting/showroom.shtml
> for example
It's relatively simple for the webmaster of such a site to ensure that
his SSIs (and cgi-bins, etc) do not pose any security loopholes.
Besides, if there IS such a loophole, it will affect only that site
(since the host is not shared with other customers' sites).
It's a completely different barrel of fish to ensure such service
integrity with thousands of customers all having their own bits of SSI
and CGI.
So I can understand this being turned off.
Personally, I find it exceedingly primitive that the only CGI scripting
supported is Perl (and not an up-to-date version of the language either,
IIRC). Why no PHP (or, my personal favorite, Object REXX)? I can
understand that they don't permit any old executable (once again because
of the potential data integrity problems).
(Cross-posted to demon.ip.www; it's nice to see some on-topic material in
that group occasionally.)
--
Brian {Hamilton Kelly} b...@dsl.co.uk
"We have gone from a world of concentrated knowledge and wisdom to one of
distributed ignorance. And we know and understand less while being incr-
easingly capable." Prof. Peter Cochrane, formerly of BT Labs
michael lefevre
> In article <MPG.1715071ad...@158.152.254.79>
> stu...@ecs-tech.removethis.com writes:
>
>> Why as a Showroom and Super Showroom customer shelling out hundreds of
>> pounds on a web server do I find that the Apache web server that Demon
>> offers has SSI (Server Side Includes) disabled?
>>
>> As a standard feature for modern web servers I was amazed to find it not
>> enabled.
>>
>> A quick call to technical support got me a confused message. One of Demons
>> technical people said it was a security issue. Well that's NOT right as
>> Demon.net uses the SSI function itself on its own site!
>
> his SSIs (and cgi-bins, etc) do not pose any security loopholes.
> It's a completely different barrel of fish to ensure such service
> integrity with thousands of customers all having their own bits of SSI
> and CGI.
fair points, but...
> So I can understand this being turned off.
... I don't really see how this follows. are the security issues with
lots of customers with their own SSI that much different to the security
issues with lots of customers with their own Perl CGI? I know it's
possible to bring the Demon commercial web servers to a crawl with a CGI,
as that has happened on one occasion since we've had out site there. I
also know it's possible to install insecure CGIs which allow spammers to
relay through the Demon server.
> Personally, I find it exceedingly primitive that the only CGI scripting
> supported is Perl (and not an up-to-date version of the language either,
> IIRC). Why no PHP (or, my personal favorite, Object REXX)? I can
> understand that they don't permit any old executable (once again because
> of the potential data integrity problems).
Agreed. I can't see how the answer about security makes much sense.
Following from Mike Bristow's comments a short while ago in this group, I
can however see that if lots of customers moved to generating a lot of
their pages dynamically (which is more likely with PHP or SSI than with
Perl), it would greatly increase the load on the servers, and CGIs are by
no means speedy on the commercial web servers as it is. Maybe that's the
primary reason?
--
michael
Richard Clayton
<michae...@michaellefevre.com> writes
>... I don't really see how this follows. are the security issues with
>lots of customers with their own SSI that much different to the security
>issues with lots of customers with their own Perl CGI?
Yes indeed, one runs as "Apache" the other as the user. This is a matter
of considerable importance on a machine with multiple users.
I asked about this issue -- and am told that these days Apache has
features such as "Options IncludesNoExec" -- so it should be possible to
overcome the technical issues that drove the policy in the past.
One might loosely characterise the question now as one of deciding
whether the commercial need is there to do the technical development
time necessary to add the SSI feature.
--
richard writing to inform and not as company policy
"Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM
Chris Elsworth
> Personally, I find it exceedingly primitive that the only CGI scripting
> supported is Perl (and not an up-to-date version of the language either,
Perl was upgraded to 5.6.0 a while ago - 4.036 and 5.004 are still
available for those who want it.
--
Chris Elsworth . chr...@demon.net
Software & Systems Developer . . tel: 020 8371 1041
t h u s mob: 07968 324 693