On Saturday, 23 May 2009 6:43 AM, Dominique Faure <dominique.fa...@gmail.com> wrote: >On Wed, May 20, 2009 at 22:03, <john.ran...@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.ran...@affinity.co.nz www.affinity.co.nz _______________________________________________ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
