[dokuwiki] Re: Suggested new config option: acceptable protocol handlers in links
- From: Sander Tekelenburg <tekelenb@xxxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Sun, 17 Jun 2007 21:34:35 +0200
At 09:39 -0700 UTC, on 2007-06-17, Walter GR wrote:
> Sander Tekelenburg wrote:
[...]
> > Agreed. I was thinking more of
> > c) user enters typo
>
> Ah, excellent point. Well, currently if a user enters a typo
> it gets linkified by DokuWiki automatically. They'd have no
> way of knowing they entered a typo unless they preview and
> click all their links.
Imagine sftp is allowed and ftp is not. What if the typo is "ftp" where
"sftp" was intended?
Maybe this is too far-fetched. It's just that, while you're discussing a
particular feature, it is relatively easy to consider all possible situations
and how to deal with them. But when you run into such a problem outside of
the context of this discussion, in daily use, it usually takes people quite a
bit more time to realise what aspect of a system a problem has to do with.
If Dokuwiki would prvide an explicit error message saying "the ftp protocol
is not allowed in this wiki", this sort of situation would be easier to
troubleshoot. But then you need to consider that most users are overloaded
with error messages already. Many are conditioned to ignore them.
> Either rendering a non-approved-
> protocol-handler-link as text or removing it completely would
> actually be _more_ of a sign that something is wrong.
True. But you still need to figure out *why* something is going wrong; how to
fix it. If a system confronts people with too many situations where this is
hard, they'll just try to avoid using that system.
> Bob McConnell wrote:
>
> > Firefox with any of the linkification plug-ins will
> > automatically convert text URIs with any of several protocol
> > types into a clickable link.
Right. You can do the same in many Mac apps.
> > I haven't looked to see if those
> > lists are adjustable, but wouldn't they over ride most of the
> > server options you are discussing?
>
> I guess that's dependent on whether the link is rendered as
> text or removed.
Or kept but not output.
> Link as text + linkification plugin would at
> least let someone see the link _in the wiki text_ and be able
> to come to some judgment about whether they should click on
> it or not. (Granted, the link destination appears in the status
> bar, but not everyone checks that before clicking.)
I think it's reasonable to say that most users are completely unaware of
protocol specifiers. If you plan to rely on users to understand URLs anyway,
you can rely on them doing that today already.
Dokuwiki not accepting certain input, or silently dropping it, or accepting
but not publicizing it would probably be required if you really want to offer
some useful level of security. Does Dokuwiki do any of that right now? If
not, implementing this would affect Dokuwiki's architecture at a much lower
level than it appears to at first sight.
Don't get me wrong, I'm not against the proposal per se. It just seems to me
there is a lot more to it than it may appear at first sight.
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
Other related posts:
