Thanks...That fixed the problem.
I have looked at sessions, but not much.
I have my own algorithm that generates a 50-character long random code, enters it into the user's account database (along with a datestamp), and passes the code as a transparent variale along the hyperlinks.
Each page then verifies this code against the username variable (also passed along the hyperlinks), and checks that the datestamp is not more than one hour old.
The datestamp is updated everytime a link is clicked, that passes the above tests so that a user is not auto-logged out unless they stop using it for an hour.
If a login is rejected, then the header is diverted to another page - as this "header problem" has been about. Else it continues with that page.
I'm not certain whether this is a better/faster/easier way of doing things that with the Sessions Support in PHPLIB, and I don't know too much about it it...but my method only takes about 4 lines of code at the top of each page. The only two main ways my login can be hacked is if the hacker gets into my accounts database on the server to retrieve the logincode, or intercepts the transparent variables and knows how to pass them through the link.
I am working on a new version, which sends the hyperlink to every new php page as a variable, but as it is verified it gets updated with a new logincode, that is generated using the last logincode as a key. Then, when the page loads up, the new login code is sent. So if it gets intercepted as it is being sent outbound, it doesn't matter - because it is already out of date!
This is better than using cookies with seessions, because what if the user has cookies disabled - and what if two PHP pages are being accessed at once by the same machine? Does one page overide the cookie containing data about the other?