phpwiki-talk

[Phpwiki-talk] Some thoughts about phpwiki

[Mikhail V. <vla...@ma...>]

Hello, people.

I have installed phpwiki-1.3.10 on my site, and I want to tell you,
what I think about it.

I have tried to make Russian locale for it, to make my own theme, to
add some new special sequences (link --- for mdash, -- for ndash, (C)
for copyright sign e.t.c.).

I found the following difficulties:

1. [:alpha:], [:alnum:] and other character classes works well on my
PHP installation, while phpwiki still tries to use it's buggy
work-around for them.  I want to be able to switch off that
work-around.

2. 'strict' authorization scheme is broken (it tries next
authentication method if previous method says, that user exists, but
password is wrong).  I have fixed this bug by deleting several lines
in WikiUserNew.php (first 'if' statement in function _tryNextPass of
class PassUser)

3. WIKI_NAME_REGEXP is used for both automatic link creation and for
checks for valid user names.  I prefer to apply to user names weaker
conditions, then to automatic links.  I want to be able to specify two
different regular expressions for this two cases.

I am an expierenced PHP programmer and I think, I can help with
development of phpwiki.  At least I can submit Russian locale for it.
My user name at sourceforge is mvladimirov.

--
Best regards
Mikhail Vladimirov <vla...@ma...>

Re: [Phpwiki-talk] Some thoughts about phpwiki

[Reini U. <ru...@x-...>]

Mikhail Vladimirov schrieb:
> I have installed phpwiki-1.3.10 on my site, and I want to tell you,
> what I think about it.
> 
> I have tried to make Russian locale for it, to make my own theme, to
> add some new special sequences (link --- for mdash, -- for ndash, (C)
> for copyright sign e.t.c.).
> 
> I found the following difficulties:
> 1. [:alpha:], [:alnum:] and other character classes works well on my
> PHP installation, while phpwiki still tries to use it's buggy
> work-around for them.  I want to be able to switch off that
> work-around.

We currently check in pcre_fix_posix_classes() for broken [:upper:] and 
use workarounds for [:alnum:], [:alpha:], [:upper:] and [:lower:] if the 
utf8 or Ä check fails.
You say that your [:upper:] check fails, but [:alpha:], [:alnum:] do 
work ok? I cannot believe this.
Maybe you can find out why your utf8 or Ä check fails.
   preg_match('/[[:upper:]]/', 'Ä')) => true
   preg_match('/[[:upper:]]/', '\xc4\x80') => true

> 2. 'strict' authorization scheme is broken (it tries next
> authentication method if previous method says, that user exists, but
> password is wrong).  I have fixed this bug by deleting several lines
> in WikiUserNew.php (first 'if' statement in function _tryNextPass of
> class PassUser)

Thanks!

> 3. WIKI_NAME_REGEXP is used for both automatic link creation and for
> checks for valid user names.  I prefer to apply to user names weaker
> conditions, then to automatic links.  I want to be able to specify two
> different regular expressions for this two cases.

Sure. Username checks must be class methods, because the strictness is 
backend specific. auth, pref and db backend specific.
bogousers are WIKI_NAME_REGEXP specific.
pageprefs users must use pagename validity checks, based on the db 
backend. (valid filenames) We shoudl work around this filename 
limitation by using urlencode in the file backend storage mechanism. But 
not for 1.3.11 yet.
SQL pref and auth users must use SQL-specific validity checks.
LDAP auth usernames are even stricter, because it easier to fool ldap 
than properly quoted sql.

> I am an expierenced PHP programmer and I think, I can help with
> development of phpwiki.  At least I can submit Russian locale for it.
> My user name at sourceforge is mvladimirov.

Great! I always loved to work with russian programmers back in old 
Autolisp days.

What is quite difficult and for which I have no time yet, is adding 
support for Markup_isonumchars in lib/InlineParser.php
TODO: "..." => "…"  browser specific display (not cached?)
TODO: "--" => "&emdash;" browser specific display (not cached?)

You want this, I believe. Currently any & is converted to & so we 
should escape it somehow (functional style) or use an OO approach as in 
HTML::Raw.
-- 
Reini Urban
http://phpwiki.org/

Re: [Phpwiki-talk] Some thoughts about phpwiki

[Reini U. <ru...@x-...>]

Âëàäèìèðîâ Ìèõàèë Àëåêñååâè÷ schrieb:
>>>1. [:alpha:], [:alnum:] and other character classes works well on my
>>>PHP installation, while phpwiki still tries to use it's buggy
>>>work-around for them.  I want to be able to switch off that
>>>work-around.
> 
> RU> We currently check in pcre_fix_posix_classes() for broken [:upper:] and
> RU> use workarounds for [:alnum:], [:alpha:], [:upper:] and [:lower:] if the
> RU> utf8 or Ä check fails.
> RU> You say that your [:upper:] check fails, but [:alpha:], [:alnum:] do
> RU> work ok? I cannot believe this.
> No, I say, that [:alpha:], [:alnum:] and other character classes works
> well, including [:upper:].  So I want to be able to disable work-around.

But the live-check must work.
utf8:
   preg_match('/[[:upper:]]/', '\xc4\x80') => true
else
   preg_match('/[[:upper:]]/', 'Ä')) => true

If this fails then something else is wrong.
If this is true, no workarounds are used.

> I remember another problem.  Plugin UserPreferences does not encrypt
> passwords, even if ENCRYPTED_PASSWD is true.  I have fixed it in the
> following way:
> 
> if (empty($rp['passwd'])) unset($rp['passwd']);
> else $rp['passwd'] = $this->_encryptPassword ($rp['passwd']);
> 
> where _encryptPassword () encrypts password if ENCRYPTED_PASSWD is
> true (I used code from script passencrypt.php to implement it).

Oops. Thanks.

> RU> What is quite difficult and for which I have no time yet, is adding
> RU> support for Markup_isonumchars in lib/InlineParser.php
> TODO: "..." =>> "…"  browser specific display (not cached?)
> TODO: "--" =>> "&emdash;" browser specific display (not cached?)
> 
> Maybe I misunderstand phpwiki architecture, but I have easily
> implemented features like this in InlineParser.php in the following
> way:
> 
> class Markup_copy extends SimpleMarkup
> {
>     var $_match_regexp = '\(C\)';
> 
>     function markup ($match) {
>         return HTML::raw ('©');
>     }
> }
> 
> RU> You want this, I believe. Currently any & is converted to & so we
> RU> should escape it somehow (functional style) or use an OO approach as in
> RU> HTML::Raw.
> I prefer something like HTML::Entity ('copy').  I hope it will be easy
> to implement.

Great. That looks fine. Though only isonumchars works so far.

class Markup_html_entities  extends SimpleMarkup {
     var $_match_regexp = '(: \.\.\.|\-\-|\-\-\-|\(C\) )';

     function markup ($match) {
         static $entities = array('...'  => '…',
                                  '--'   => '–',
                                  '---'  => '—',
                                  '(C)'  => '©',
                                  );
         return HTML::Raw($entities[$match]);
     }
}
class Markup_isonumchars  extends SimpleMarkup {
     var $_match_regexp = '\&\#\d{2,5};';

     function markup ($match) {
         return HTML::Raw($match);
     }
}
class Markup_isohexchars extends SimpleMarkup {
     // hexnums, like &#x00A4; <=> &curren;
     var $_match_regexp = '\&\#x[0-9a-fA-F]{2,4};';

     function markup ($match) {
         return HTML::Raw($match);
     }
}

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Some thoughts about phpwiki

[Reini U. <ru...@x-...>]

Âëàäèìèðîâ Ìèõàèë Àëåêñååâè÷ schrieb:
>>>2. 'strict' authorization scheme is broken (it tries next
>>>authentication method if previous method says, that user exists, but
>>>password is wrong).  I have fixed this bug by deleting several lines
>>>in WikiUserNew.php (first 'if' statement in function _tryNextPass of
>>>class PassUser)

It's not that simple but I found a good fix.

> RU> Thanks!
> I remember another problem.  Plugin UserPreferences does not encrypt
> passwords, even if ENCRYPTED_PASSWD is true.  I have fixed it in the
> following way:
> 
> if (empty($rp['passwd'])) unset($rp['passwd']);
> else $rp['passwd'] = $this->_encryptPassword ($rp['passwd']);
> 
> where _encryptPassword () encrypts password if ENCRYPTED_PASSWD is
> true (I used code from script passencrypt.php to implement it).

That's unfortunately wrong, because the user class stores and changes 
the passwords. You cannot do that in the plugin.

But I detected the real problem for PersonalPage users
in WikiUserNew only.
This _PassUser::changePass method forgot to crypt and more things.
(not foolproof yet)

     function changePass($submitted_password) {
         $stored_password = $this->_prefs->get('passwd');
         // check if authenticated
         if (!$this->isAuthenticated()) return false;
         if (ENCRYPTED_PASSWD) {
             $submitted_password = crypt($submitted_password);
         }
         // check other restrictions, with side-effects only.
         $result = $this->_checkPass($submitted_password, $stored_password);
         if ($stored_password != $submitted_password) {
             $this->_prefs->set('passwd', $submitted_password);
             //update the storage (session, homepage, ...)
             $this->SetPreferences($this->_prefs);
             return true;
         }
         //Todo: return an error msg to the caller what failed?
         // same password or no privilege
         return ENCRYPTED_PASSWD ? true : false;
     }


-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/