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:[email protected]>[email protected]
===(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
_______________________________________________
pmwiki-users mailing list
[email protected]
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
