<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Patrick,<br>
<br>
Thanks for pointing me to the specific module responsible for the
security, Patrick, and for the reality check.<br>
<br>
I am continuing to investigate alternate webserver hosts.
canadianwebhosting.com looks promising. They use <a
href="http://helpdesk.canadianwebhosting.com/support-center/index.php?x=&mod_id=2&root=19&id=210">an
suPHP</a> scheme which looks tight but workable, with "Your scripts and
directories can have a maximum of 755 permissions" (all files have the
same owner with rwx). I presume that would be workable? Would I have to
reconfigure the umask(002); statement in pmwiki.php for this?<br>
<br>
Hope you're well. I just (finally) upgraded one of my sites
(<a class="moz-txt-link-abbreviated" href="http://www.dufferinpark.c">www.dufferinpark.c</a>) to 2.2, soon will do the others (the rest are all
part of one farm). Then I'm *really* looking forward to playing with
all the cool new features!<br>
<br>
Best,<br>
<br>
- Henrik<br>
<br>
Patrick R. Michaud wrote:
<blockquote cite="mid:20080326190257.GN23964@host.pmichaud.com"
type="cite">
<pre wrap="">On Sun, Mar 23, 2008 at 10:11:49AM -0400, Henrik wrote:
</pre>
<blockquote type="cite">
<pre wrap="">This security change by my webhost is confirmed. In response to my query
they sent me the following response.
=============================
The web server security is setup such that it will automatically block system related words while posting data from php based applications, as this may lead to web server exploit. We request you to stop using system related words in your applications.
=============================
So suddenly none of my websites can post external links (with the string
<a class="moz-txt-link-rfc2396E" href="http://">"http://"</a> anywhere in the page), and hundreds if not thousands of pages
that have this protocol embedded are suddenly uneditable.
Truly horrible. A complete nightmare!
But nothing to do with PmWiki.
</pre>
</blockquote>
<pre wrap=""><!---->
Just to follow up on this -- this particular issue is described
at <a class="moz-txt-link-freetext" href="http://www.pmwiki.org/wiki/PmWiki/Troubleshooting#mod_security">http://www.pmwiki.org/wiki/PmWiki/Troubleshooting#mod_security</a> .
There is no PmWiki-based workaround to it, as the problem is well
outside of PmWiki (as you've recognized).
I've never heard of someone using mod_security to block <a class="moz-txt-link-rfc2396E" href="http://">"http://"</a>
before, though, so that's new (and an additional reason to doubt
the sanity of the webhosting provider). Note that this security
measure affects not only PmWiki, but also any application that
tries to use an input form where someone might want to provide
an <a class="moz-txt-link-freetext" href="http://">http://</a> link (e.g., comments to blog postings, shopping carts,
etc.).
Pm
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Henrik Bechmann
<a class="moz-txt-link-abbreviated" href="http://www.bechmann.ca">www.bechmann.ca</a>
Webmaster, <a class="moz-txt-link-abbreviated" href="http://www.dufferinpark.ca">www.dufferinpark.ca</a></pre>
</body>
</html>