[pmwiki-devel] Help with understanding an authentication problem

[Dominique Faure]

On Wed, May 20, 2009 at 22:03,  <john.rankin at affinity.co.nz> wrote:
>> Hi,
>>
>> On Wed, May 20, 2009 at 06:03, John Rankin <john.rankin at affinity.co.nz>
>> wrote:
>>> (a) explain what might be going on to cause the problem
>>
>> 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.
>
> That is definitely a problem for Wikipublisher.
>
> Is it something the hosting service can configure, so for this
> set of sites it doesn't use suhosin? Or is it a server-wide
> setting?

I dont know. I fear the hosting service won't allow you to alter the
configuration of this security enhancement tool.

>>
>>> (b) suggest what might be done to fix it
>>
>> Perhaps, by providing your own way to propagade unserialized auth info
>> from one instance to another.
>>
>> ITOH, why not writing a new PmWiki delegated auth scheme recipe, made
>> of two scripts:
>>
>> * A delegated auth function responsive to forward auth request from a
>> slave Pmwiki to a master one.
>>
>> * The latter would host a set of handler functions able to answer to
>> slave requests as if they were locally made.
>>
>> This would imply some network tools such as curl, or Snoopy
>> (http://sourceforge.net/projects/snoopy/).
>>
> I do not even understand where to begin. Since they also run php
> in safe mode, this sets other restrictions on what is allowed.
> This problem is way beyond my limited skill level. If I understand
> correctly, a recipe could use snoopy to trap the authentication
> request and simulate a form response? So this could be done as
> a pmwiki plug-in on the affected sites?

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.

The server side recipe would implements the related action handler
which would get simply fetch respond with the auth datas, as if the
authentication occured on the server.

Anyway, the data exchange between both side should be encrypted (using
a shared password), and the ip addresses controlled.

An alternative architecture would be to have all PmWiki instances
relying on a common tier auth server such as OpenId.

> Thank you for the help.

You're welcome.

-- 
Dominique

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en début de message est-il si effroyable?