Re: [cowiki-dev] Extension to coWiki text formatting

PAUL HANCHETT wrote:

> Archie Campbell wrote:
>
>>
>> I really don't know about the extent to which 'availability of 
>> [sophisticated formatting] will be controlled by the site 
>> administrator', but I would like to comment briefly on the proposed 
>> markup, mostly the stuff that is already familiar.
>
> This is a security feature that we'd need to add on the administration 
> pages.  Basically the ability to turn the processing that enables 
> these features on and off.

Why don't we need this already?

>> Does coWiki attempt to save & redisplay? Certainly stuff that can't 
>> be processed is often displayed in full, a sort of 'default to 
>> verbatim'. If we can define parser-success, then we can 
>> fail-to-verbatim. What if closing all tags was all we had to put 
>> faith in?
>
> Presently coWiki will save text that it does not recognize as valid.  
> dtg must have included a mechanism to make this happen because I see 
> it.  What I'm proposing is to make the parser robust enough to detect 
> when text is poorly formatted.  Since the text that the user submitted 
> will still be available, it can be returned to the user for 
> correction, along with hints about where the problem is.

Like any parser, coWiki will be able to guess, often poorly, what the 
user is getting at. The desired intelligence behind the parser's 
comments won't be cheap to provide. I can only think of holding 
unrecognised tags up for examination, and pinpointing problems with the 
emphatic markup (single asterisks occurring). However, if desired, the 
parser's witty comments will be as much a problem as bona fide misparsing.

>> LPIs...
>>
>> May be found at newline, also must be first element (provided by 
>> initial parse if not submitted).
>
> LPI's can occur anywhere.  This is necessary so that elements from one 
> language can be included in another.  For example, to include a coWiki 
> constant into an HTML page.  It has the same purpose as scripting in 
> HTML and JSP.

So LPIs won't be an attempt to provide html-embedded foreach and other 
control loop behaviour. That's too difficult to imagine and needed a 
virtual machine. More like, LPIs provide access (secured) to variables 
at point. That way we won't need to parse to an in-core parsed 
representation, and can go straight to pretty xml.

>> Only cowiki and html (pasted verbatim) a present. Awaiting security. 
>> How do we secure raw php? Or is what is wanted more a syntax 
>> highlighter like GeSHi?
>
> ACK.  I don't see PHP or any other language as crucial at the moment.  
> I more wanted to demonstrate how they fit into the whole picture, to 
> understand that language selection operates at a higher level than the 
> current language selection.  (I think that's the key to making it 
> simple to implement.)

I'm imagining that still means GeSHi is more likely than rules for 
securing inline php.

> ---
>
> On the issue of language security-- There are natural and self 
> consistent extensions following these rules:
>
>     * The ability to save pages with a language feature represented
>       either by a group or can be assigned to groups by the site
>       administrator.  (Only one of these is required, and representing
>       a feature by a single group is probably both easier to implement
>       and faster to execute.)
>
Feature by single group has my vote.

>     * A user is given the ability to save pages which invoke a certain
>       language feature by adding that langugage group to their group list.
>
Ditto.

>     * A user will not be allowed to save a page that invokes a
>       language feature they are not entitled to use.
>
The entire textarea is returned to them, with another box showing 
line-before, line & line-after the forbidden area, or something?

>     * To prevent a "got-you" syndrome, a user should be prohibited or
>       at least warned when they attempt to edit a page that uses a
>       feature they are not entitled to.  (Maybe just warned because
>       they may be removing the feature...)
>
I'm still thinking this is better limited to plugins. Maybe they can 
edit (for interest's sake), but the xml is plugged with a dummy-tag for 
the forbidden feature.

>     * Individual language features can be turned on and off by the
>       site administrator.  If a feature is turned off, it cannot be
>       parsed on a page when it is saved. 
>
> All of this security intentionally pertains to pages when they are 
> /saved/.  This lets previously saved pages, which invoke now disabled 
> features, to continue to work without error.

No reason why it couldn't appertain to previous pages now in xml format.

You know, I'd feel a deal better if the markup was available to all, but 
some of those kinky, specialised plugins were locked-down and reserved 
for special occasions. Otherwise, I'm not sure that page-saving is the 
right time for security. It may even be healthy to provide a dummy tag 
for markup-that-is-forbidden, allowing differential viewing to win out, 
where frustrated editing is more like a teething error.

coWiki is, of course, the security-conscious wiki, but Paul has really 
surprised me with his totalitarian vision! While it will be far simpler 
to cut things out of a fully-working parser, I support discussion to 
improve our understandings of each others' conceptualisations.

Isn't it only foolproof security when the plugin or markup is refused 
during rendering? Isn't there the possibility of man in the middle until 
that point?

Regards,

Archie