[pmwiki-devel] Help with understanding an authentication problem

[John Rankin]

On Saturday, 23 May 2009 6:43 AM, Dominique Faure <dominique.faure at gmail.com> wrote:
>On Wed, May 20, 2009 at 22:03,  <john.rankin at affinity.co.nz> wrote:
>>> Looking at "http://www.parakoos.com/info.php", the php installation
>>> seems to be using suhosin, which provides some kind of session
>>> protection, ie. you cannot exchange session data between 2 php
>>> instances as easily as before.
>>
Gustav, could you ask the hosting service to test this by running
suhosin in simulation mode? This will log any violations detected,
but not interfere with the execution:
http://www.hardened-php.net/suhosin/configuration.html#suhosin.simulation

This will tell us whether suhosin is, in fact, the problem.
Suhosin session protection is listed as a feature here:
http://www.hardened-php.net/suhosin/a_feature_list.html
>>>
>>>> (b) suggest what might be done to fix it
>>>
>Here's how I see it (but I may be wrong): This would be a 2 scripts
>recipe, one of them making a PmWiki acting as an auth client and the
>other allowing a second PmWiki installation to respond as an auth
>server for the first client side.
>
>The client side recipe would simply define a custom auth function
>($AuthFunction), which would use curl/snoopy/... to propagate
>credentials request to the server side in a post request using a
>specific action.
>
Looking at how pmwiki's authentication works, I am wondering 
if there may be another route.

As I understand it, suhosin is detecting a problem with the
session information, so pmwiki's authentication mechanism is
being triggered, raising a prompt for a username/password.
Normally, pmwiki uses the username and password to decide
whether to let the request in. So the logic is:

- we need to authenticate this request

- ask for a username and/or password

- check for validity and return true or false

It seems to me that we ought to be able to define a custom
$AuthFunction that checks the IP address of the requestor,
rather than asking for a username and password. Then the
custom auth function can authenticate the request based on
the fact that it comes from an IP address pmwiki trusts.
It may have to grant "admin" rights, especially where the
request is retrieving multiple pmwiki pages.

To make this work, the recipe would have to tell pmwiki,
"Instead of prompting for a username and/or password,
check the IP address of the requestor."

>From the look of authuser, pmwiki treats authentication 
as a black box that returns allowed/disallowed, but I 
find the code hard to understand.

We may also have to suppress the wikipublisher code 
that passes the session information to the pdf server,
which would stop the suhosin alarm from triggering and
cause pmwiki to treat the pdf server's request like a 
new session.

Does this sound feasible?
-- 
John Rankin
Affinity Limited
T 64 4 495 3737
F 64 4 473 7991
021 RANKIN
john.rankin at affinity.co.nz
www.affinity.co.nz