[pmwiki-users] session problems

[Petko Yotov]

I have tested your site with Firefox and Chromium (a derivative of Chrome  
with tracking removed) and both browsers correctly post the "authpw" value.

>From your description it is clear that your particular browser doesn't  
"post" the authpw value. (The $_REQUEST array is populated from $_POST and  
$_GET, and sometimes $_COOKIE, by PHP.)

What you describe may sometimes happen if any of the forms in the page is  
missing a closing </form> tag, or if the two forms are overlapping in some  
way. But I looked at the HTML source and didn't find such problem.

Disable all JavaScripts in the page (Google Analytics or other) and try  
again. It is unlikely, although possible, for a JavaScript program to  
manipulate the DOM tree of the page and to (re)move the input authpw element  
from the submitted form. (And while you're at it, clear the browser cache,  
and disable any installed browser extensions/modules.)

Other than that I don't know. :-)

Petko


Peter Bowers writes:
>
> So I looked at the value of $_REQUEST and $_POST at the *very top* of  
> pmwiki.php.  In firefox (working) I see this:
>
>
> ===(snip)===aREQUEST=
> Array
> (
>     [n] => Test2.Fey
>     [authpw] => Secret
>     [userlang] => 
>     [__utma] => 40668285.348328946.1397164534.1398017197.1398019354.5
>     [__utmz] => 40668285.1397164534.1.1.utmcsr=(direct)|utmccn=(direct)| 
> utmcmd=(none)
>     [PHPSESSID] => cd53316c99d3690c99942e7f0850b408
> )
>
> aPOST=
> Array
> (
>     [authpw] => Secret
>
> )
> ===(snip)===
>
>
>
> And in Chrome I see this:
>
>
> ===(snip)===aREQUEST=
>
>
> Array
> (
>     [n] => Test2.Fey
>     [userlang] => en
>     [__utma] => 40668285.38466667.1397209880.1398017149.1398190718.4
>     [__utmc] => 40668285
>     [__utmz] => 40668285.1397209880.1.1.utmcsr=(direct)|utmccn=(direct)| 
> utmcmd=(none)
>     [PHPSESSID] => 08228d5e9d3a3393f5352487c73f314f
> )
>
> aPOST=
>
>
> Array
> ( 
>
> )
> ===(snip)===
>
>
>
> In both cases this is after having done ?action=logout and then immediately  
> entering the password and pressing submit - I'm giving you the tracing from  
> the page-load immediately upon submitting with the password.  No config.php  
> or farmconfig.php is active (still renamed to config.php.bak and  
> farmconfig.php.bak) and, even if they were active they couldn't affect the  
> value of $_REQUEST or $_POST in pmwiki.php well above where they are  
> included.
>
>
> To be clear, this is what my pmwiki.php looks like starting at the very top:
>
>
> ===(snip)===
>
> <?php
> echo "aREQUEST=<pre>".print_r($_REQUEST,true)."</pre><br />\n";
>
> echo "aPOST=<pre>".print_r($_POST,true)."</pre><br />\n";
> /*
>
>     PmWiki
>     Copyright 2001-2014 Patrick R. Michaud
>     <URL:mailto:pmichaud at pobox.com>pmichaud at pobox.com
> ===(snip)===
>
>
> Obviously in both firefox and chrome I'm getting the error about the headers  
> already being sent (due to my tracing), but I don't think that's an issue at  
> all - the issue is that $_REQUEST doesn't hold the password expected!  I have  
> confirmed that on my machine IE works and on another machine both chrome and  
> firefox worked, but on a 3rd machine (remote - I wasn't able to get a clear  
> answer as to which browser they were using) they were unable to log in.
>
>
> Any ideas?
>
>
> -Peter