Re: [PHP] Is header() malfunction due to PHP5.3.3 - 5.4.11 transition?
On Sat, Feb 9, 2013 at 8:00 PM, Jonathan Eagle jeo...@attglobal.net wrote:
I'm having a problem with a very straightforward routine; one that works
in one PHP installation but not on the other. The only difference that I
can see between the working version and the non-working version is that
the one that doesn't work is running on the later version of PHP. The
following basic log-in routine works fine on my personal development
server, running PHP 5.3.3, but doesn't work on the production server,
hosted by 11.com that is running PHP 5.4.11.
?php
require_once('../includes/initialize.php'); //== $session object
init'd and set to false
if(!$session-is_logged_in())
{
header(Location: login.php);
exit;
}
?
login.php is in the same directory as the file that has this code at the
very top of the file.
Everything works as expected right up to the 'exit;' line.
* $session-is_logged_in() is false
* when tested immediately after the 'header(Loc...)' statement,
'headers_sent()' reports true.
* no error messages result (like: 'header already sent', etc.)
Instead of the program flow moving to 'login.php', the URL indicates
that the destination is the original file, except that the file is empty
- zero bytes. I've tried accessing the routine via three different
computers, all running different MS operating systems from XP to Win7
and they all behave identically. The behavior is also consistent
between browsers (i.e., FireFox, Chrome, and Windows Explorer).
It seems like the header is not actually send, maybe because the headers
are already sent.
You can check what your server returned with the Developer tools in Chrome,
or Firebug in Firefox. It should have that header in its return, but I
doubt it's there.
I also did a $_SERVER variable dump immediately before and after the
'header(...' line, expecting to see a difference in at least one of the
'REDIRECT_*' elements, but both outputs where identical with the
exception that the $_SERVER ouput after the header statement was
executed was missing the following line:
$_SERVER refers to headers that were send from client to server, the
redirect header you set is with the headers sent from server to client.
I would try a file like this first:
?php
header(Location: login.php);
?
and see if that works. Then you can investigate further.
- Matijn
Re: [PHP] Is header() malfunction due to PHP5.3.3 - 5.4.11 transition?
On 9 Feb 2013, at 19:00, Jonathan Eagle jeo...@attglobal.net wrote:
I'm having a problem with a very straightforward routine; one that works
in one PHP installation but not on the other. The only difference that I
can see between the working version and the non-working version is that
the one that doesn't work is running on the later version of PHP. The
following basic log-in routine works fine on my personal development
server, running PHP 5.3.3, but doesn't work on the production server,
hosted by 11.com that is running PHP 5.4.11.
?php
require_once('../includes/initialize.php'); //== $session object
init'd and set to false
if(!$session-is_logged_in())
{
header(Location: login.php);
exit;
}
?
login.php is in the same directory as the file that has this code at the
very top of the file.
Everything works as expected right up to the 'exit;' line.
* $session-is_logged_in() is false
* when tested immediately after the 'header(Loc...)' statement,
'headers_sent()' reports true.
* no error messages result (like: 'header already sent', etc.)
Instead of the program flow moving to 'login.php', the URL indicates
that the destination is the original file, except that the file is empty
- zero bytes. I've tried accessing the routine via three different
computers, all running different MS operating systems from XP to Win7
and they all behave identically. The behavior is also consistent
between browsers (i.e., FireFox, Chrome, and Windows Explorer).
I also did a $_SERVER variable dump immediately before and after the
'header(...' line, expecting to see a difference in at least one of the
'REDIRECT_*' elements, but both outputs where identical with the
exception that the $_SERVER ouput after the header statement was
executed was missing the following line:
[HTTP_CACHE_CONTROL]= max-age=0
It doesn't look relevant to me, but I include it to be thorough.
I looked through the PHP changelog pages, but I don't see mention of the
problem (of course, that might just be due to my ignorance). The ISP
for the production version of PHP indicated that I should come here for
help, so here I am.
Can anyone shed some light as to what is (or might be) going on?
Any help or guidance that can be offered will be greatly appreciated.
Check the output buffering settings. You say no errors are displayed, but are
you sure that errors are set to be displayed?
You mention the headers_sent() result immediately after the header() function
call is true. If the header() function call had worked it would not be true, it
would be false. You have output being sent to the client before that header()
function call.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is header() malfunction due to PHP5.3.3 - 5.4.11 transition?
On Feb 9, 2013, at 2:00 PM, Jonathan Eagle jeo...@attglobal.net wrote: I'm having a problem with a very straightforward routine; Jonathan: No offense to your routine, but you may want to review this: http://sperling.com/php/authorization/log-on.php If anyone finds an error, please post. Cheers, tedd _ t...@sperling.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is header() malfunction due to PHP5.3.3 - 5.4.11 transition?
Stuart,
Thanks for getting back to me you were right - I had misread the
headers_sent() Return Value statement. When I went back and tested
it turns out that the 'initialize' routine is somehow prematurely
sending output out. So, now I have to figure out which of the ten
called routines and classes/objects in the initialize script are the
culprit.
I greatly appreciate the assistance,
Jonathan
On 2/9/2013 2:34 PM, Stuart Dallas wrote:
On 9 Feb 2013, at 19:00, Jonathan Eagle jeo...@attglobal.net wrote:
I'm having a problem with a very straightforward routine; one that works
in one PHP installation but not on the other. The only difference that I
can see between the working version and the non-working version is that
the one that doesn't work is running on the later version of PHP. The
following basic log-in routine works fine on my personal development
server, running PHP 5.3.3, but doesn't work on the production server,
hosted by 11.com that is running PHP 5.4.11.
?php
require_once('../includes/initialize.php'); //== $session object
init'd and set to false
if(!$session-is_logged_in())
{
header(Location: login.php);
exit;
}
?
login.php is in the same directory as the file that has this code at the
very top of the file.
Everything works as expected right up to the 'exit;' line.
* $session-is_logged_in() is false
* when tested immediately after the 'header(Loc...)' statement,
'headers_sent()' reports true.
* no error messages result (like: 'header already sent', etc.)
Instead of the program flow moving to 'login.php', the URL indicates
that the destination is the original file, except that the file is empty
- zero bytes. I've tried accessing the routine via three different
computers, all running different MS operating systems from XP to Win7
and they all behave identically. The behavior is also consistent
between browsers (i.e., FireFox, Chrome, and Windows Explorer).
I also did a $_SERVER variable dump immediately before and after the
'header(...' line, expecting to see a difference in at least one of the
'REDIRECT_*' elements, but both outputs where identical with the
exception that the $_SERVER ouput after the header statement was
executed was missing the following line:
[HTTP_CACHE_CONTROL]= max-age=0
It doesn't look relevant to me, but I include it to be thorough.
I looked through the PHP changelog pages, but I don't see mention of the
problem (of course, that might just be due to my ignorance). The ISP
for the production version of PHP indicated that I should come here for
help, so here I am.
Can anyone shed some light as to what is (or might be) going on?
Any help or guidance that can be offered will be greatly appreciated.
Check the output buffering settings. You say no errors are displayed, but are
you sure that errors are set to be displayed?
You mention the headers_sent() result immediately after the header() function
call is true. If the header() function call had worked it would not be true,
it would be false. You have output being sent to the client before that
header() function call.
-Stuart
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is header() malfunction due to PHP5.3.3 - 5.4.11 transition?
On 9 Feb 2013, at 21:00, Jonathan Eagle jeo...@attglobal.net wrote:
Stuart,
Thanks for getting back to me you were right - I had misread the
headers_sent() Return Value statement. When I went back and tested
it turns out that the 'initialize' routine is somehow prematurely
sending output out. So, now I have to figure out which of the ten
called routines and classes/objects in the initialize script are the
culprit.
I greatly appreciate the assistance,
The error message that should be being displayed tells you where output was
started. Check your error_reporting and display_errors settings to make sure
errors are being displayed and you should be able to save a lot of time.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
On 2/9/2013 2:34 PM, Stuart Dallas wrote:
On 9 Feb 2013, at 19:00, Jonathan Eagle jeo...@attglobal.net wrote:
I'm having a problem with a very straightforward routine; one that works
in one PHP installation but not on the other. The only difference that I
can see between the working version and the non-working version is that
the one that doesn't work is running on the later version of PHP. The
following basic log-in routine works fine on my personal development
server, running PHP 5.3.3, but doesn't work on the production server,
hosted by 11.com that is running PHP 5.4.11.
?php
require_once('../includes/initialize.php'); //== $session object
init'd and set to false
if(!$session-is_logged_in())
{
header(Location: login.php);
exit;
}
?
login.php is in the same directory as the file that has this code at the
very top of the file.
Everything works as expected right up to the 'exit;' line.
* $session-is_logged_in() is false
* when tested immediately after the 'header(Loc...)' statement,
'headers_sent()' reports true.
* no error messages result (like: 'header already sent', etc.)
Instead of the program flow moving to 'login.php', the URL indicates
that the destination is the original file, except that the file is empty
- zero bytes. I've tried accessing the routine via three different
computers, all running different MS operating systems from XP to Win7
and they all behave identically. The behavior is also consistent
between browsers (i.e., FireFox, Chrome, and Windows Explorer).
I also did a $_SERVER variable dump immediately before and after the
'header(...' line, expecting to see a difference in at least one of the
'REDIRECT_*' elements, but both outputs where identical with the
exception that the $_SERVER ouput after the header statement was
executed was missing the following line:
[HTTP_CACHE_CONTROL]= max-age=0
It doesn't look relevant to me, but I include it to be thorough.
I looked through the PHP changelog pages, but I don't see mention of the
problem (of course, that might just be due to my ignorance). The ISP
for the production version of PHP indicated that I should come here for
help, so here I am.
Can anyone shed some light as to what is (or might be) going on?
Any help or guidance that can be offered will be greatly appreciated.
Check the output buffering settings. You say no errors are displayed, but
are you sure that errors are set to be displayed?
You mention the headers_sent() result immediately after the header()
function call is true. If the header() function call had worked it would not
be true, it would be false. You have output being sent to the client before
that header() function call.
-Stuart
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is header() malfunction due to PHP5.3.3 - 5.4.11 transition?
Matijn,
Thanks for the suggestion. Your suspicions were correct. I am now
tracking down the culprit.
Jonathan
On 2/9/2013 2:34 PM, Matijn Woudt wrote:
On Sat, Feb 9, 2013 at 8:00 PM, Jonathan Eagle jeo...@attglobal.net wrote:
I'm having a problem with a very straightforward routine; one that works
in one PHP installation but not on the other. The only difference that I
can see between the working version and the non-working version is that
the one that doesn't work is running on the later version of PHP. The
following basic log-in routine works fine on my personal development
server, running PHP 5.3.3, but doesn't work on the production server,
hosted by 11.com that is running PHP 5.4.11.
?php
require_once('../includes/initialize.php'); //== $session object
init'd and set to false
if(!$session-is_logged_in())
{
header(Location: login.php);
exit;
}
?
login.php is in the same directory as the file that has this code at the
very top of the file.
Everything works as expected right up to the 'exit;' line.
* $session-is_logged_in() is false
* when tested immediately after the 'header(Loc...)' statement,
'headers_sent()' reports true.
* no error messages result (like: 'header already sent', etc.)
Instead of the program flow moving to 'login.php', the URL indicates
that the destination is the original file, except that the file is empty
- zero bytes. I've tried accessing the routine via three different
computers, all running different MS operating systems from XP to Win7
and they all behave identically. The behavior is also consistent
between browsers (i.e., FireFox, Chrome, and Windows Explorer).
It seems like the header is not actually send, maybe because the headers
are already sent.
You can check what your server returned with the Developer tools in Chrome,
or Firebug in Firefox. It should have that header in its return, but I
doubt it's there.
I also did a $_SERVER variable dump immediately before and after the
'header(...' line, expecting to see a difference in at least one of the
'REDIRECT_*' elements, but both outputs where identical with the
exception that the $_SERVER ouput after the header statement was
executed was missing the following line:
$_SERVER refers to headers that were send from client to server, the
redirect header you set is with the headers sent from server to client.
I would try a file like this first:
?php
header(Location: login.php);
?
and see if that works. Then you can investigate further.
- Matijn
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is header() malfunction due to PHP5.3.3 - 5.4.11 transition?
My 'display_errors' is ON and my 'error_reporting' is 22517. I'm not sure what that means but it looks as if I should be getting error messages somewhere. Jonathan On 2/9/2013 4:02 PM, Stuart Dallas wrote: On 9 Feb 2013, at 21:00, Jonathan Eagle jeo...@attglobal.net wrote: Stuart, Thanks for getting back to me you were right - I had misread the headers_sent() Return Value statement. When I went back and tested it turns out that the 'initialize' routine is somehow prematurely sending output out. So, now I have to figure out which of the ten called routines and classes/objects in the initialize script are the culprit. I greatly appreciate the assistance, The error message that should be being displayed tells you where output was started. Check your error_reporting and display_errors settings to make sure errors are being displayed and you should be able to save a lot of time. -Stuart -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is header() malfunction due to PHP5.3.3 - 5.4.11 transition?
On Sat, Feb 9, 2013 at 9:59 PM, Tedd Sperling t...@sperling.com wrote: On Feb 9, 2013, at 2:00 PM, Jonathan Eagle jeo...@attglobal.net wrote: I'm having a problem with a very straightforward routine; Jonathan: No offense to your routine, but you may want to review this: http://sperling.com/php/authorization/log-on.php If anyone finds an error, please post. Cheers, tedd Well, I hope you're not actually storing passwords plain text in real life examples. Other than that, this method allows session hijacking. - Matijn
Re: [PHP] Is header() malfunction due to PHP5.3.3 - 5.4.11 transition?
On Sat, Feb 9, 2013 at 10:08 PM, Jonathan Eagle jeo...@attglobal.netwrote: My 'display_errors' is ON and my 'error_reporting' is 22517. I'm not sure what that means but it looks as if I should be getting error messages somewhere. Jonathan Most likely they end up in the logs instead of the screen. Try check the logs (on linux, they are usually in /var/log/apache). A general note (this also applies to tedd): The HTTP specification notes that the Location header should be followed by an absolute URI only. Even though probably every browser accepts relative URIs too, it's incorrect. You should replace it with http://myserver.com/login.php, or preferable, https://myserver.com/login.php . - Matijn
Re: [PHP] Is header() malfunction due to PHP5.3.3 - 5.4.11 transition?
Most likely they end up in the logs instead of the screen. Try check the logs (on linux, they are usually in /var/log/apache). This is being hosted on 1and1.com, so I don't think I direct access to those directories, but I have found a 'logs' folder off of the root. Looking through that I see what seems to be a bunch of error log files. I will look through those and see what I can find. Thanks again, Jonathan , On 2/9/2013 4:14 PM, Matijn Woudt wrote: On Sat, Feb 9, 2013 at 10:08 PM, Jonathan Eagle jeo...@attglobal.netwrote: My 'display_errors' is ON and my 'error_reporting' is 22517. I'm not sure what that means but it looks as if I should be getting error messages somewhere. Jonathan Most likely they end up in the logs instead of the screen. Try check the logs (on linux, they are usually in /var/log/apache). A general note (this also applies to tedd): The HTTP specification notes that the Location header should be followed by an absolute URI only. Even though probably every browser accepts relative URIs too, it's incorrect. You should replace it with http://myserver.com/login.php, or preferable, https://myserver.com/login.php . - Matijn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is header() malfunction due to PHP5.3.3 - 5.4.11 transition?
On Sun, Feb 10, 2013 at 12:19 AM, Stephen stephe...@rogers.com wrote: On 13-02-09 04:11 PM, Matijn Woudt wrote: On Sat, Feb 9, 2013 at 9:59 PM, Tedd Sperling t...@sperling.com wrote: Jonathan: No offense to your routine, but you may want to review this: http://sperling.com/php/**authorization/log-on.phphttp://sperling.com/php/authorization/log-on.php If anyone finds an error, please post. Cheers, tedd Well, I hope you're not actually storing passwords plain text in real life examples. Other than that, this method allows session hijacking. - Matijn Can you explain how a session could be hijacked? Thank you! -- Stephen Sure, Just basic session stuff first: When you start a session, PHP sends a cookie header in return to the client. This cookie header includes a session id. On next requests your browser will send this same session id back to the server. Now the server knows which session belongs to this client. Now to the session hijack stuff: I assume we are on a normal http server (not https), then this session id will be send plain text in the http headers. Now, assume we are both connected to a hotspot, then I will be able to read all traffic that passes on to this hotspot, a so called man-in-the-middle attack. Once you have logged in, I can get the cookie that contains the session id. Now I can request the private part if I send that same cookie with it. There are more forms of this attack, but they are more complicated. An SSL secured connection solves most, but even with https, it is possible to do this kind of attack. For more info I'd like to refer to google;) - Matijn
