I've wanted to redirect the user from login.php to myPage.php when a certain button is clicked. I was successful using the header command, however now I want to change myPage.php to myNewPage.php but everytime I click on login.php it automatically takes me to myPage.php eventhough the header command is removed, or changed to myNewPage.php. I also tried the header_remove command but with no success and tried to remove google chrome cache, any ideas ? Note: My project partner has the same source code and manages to connect to login.php normally without redirection.
So I've deleted my project from everywhere and pulled it from my github repository afterwards and the problem was fixed. Still don't know the source of the problem or how to fix it though but if u encounter this situation this is a way to bypass it.
I used window.location.replace in my HTML file to test if the redirect works. Then I deleted the script function that redirected the web page but my HTML file won't stop redirecting.
So..I deleted the file completely, cleared my cache, cleared history, and everything and the web page still redirects to another page. The only thing that worked was that I changed my file name from index.html to index.php. However, even though index.html doesn't exist anymore after deleting and renaming it, it still redirects to another page when I enter in the URL
Anyone know how to fix this? I'm using domain.com btw.
EDIT: closed my browser and cleared my cache again and it for some reason worked. Not sure why it didn't work before that.
Double check to make sure the file is deleted. Since you cleared your cache, that seems to be the only option. Unless you have a caching network such as a CDN between you and the web server or unless your host has your site in its own cache.
I am facing a strange scenario. basically on my every web page i am doing
session_start();
if(!isset($_SESSION['login']))
header("Location: login.php");
to ensure every user has logged in first. I am working in chrome and what happens is if I login to my web application and open any page it works fine. At the same time if, in another tab, I login to my hosting server, I am logged out of my web application. If I login to my application again, I am logged out of my hosting server!!
What am I doing wrong? is there a problem the way I am checking or setting the session variable?
I am setting the session as follows:
//if authentication successful
session_start();
$_SESSION['login'] = "1";
I have a very similar problem, and I think this happens just because two sessions with the same name, in the same place of the same domain can't coexist.
Maybe a solution should be to use session cookies. You can set a cookie just for a folder and not for the whole domain. This way I think you can manage 2 sessions at the same time, but I'm not sure.
Try this:
session_start();
setcookie(session_name(), session_id(), 0, '/public/');
Where /public/ might be the specific folder where your site is located, or the application path (thanks Paul for pointing out this).
Then you will check if session is set:
$session_cookie =
isset($_COOKIE[ini_get('session.name')]) ?
$_COOKIE[ini_get('session.name')] :
null;
Probably this won't work, since the other session might be "stored" in the root folder of your web application. But if you are able to do the thing above also for your hosting server, you should resolve your problem.
You can also try to set a different name for the session in your web application.
Hope this helps.
I think you'll find the cause is that both hosts have the same network name e.g. test.www.example.com and www.example.com
Just use a different network name for the test machine and it should work or make sure you explicitly use non-overlapping values for session.cookie_domain
I have a problem similar if not identical to the problem in this thread:
Randomly Losing Session Variables Only In Google Chrome & URL Rewriting
But all solutions in that thread don't work for me. I'm getting a strange behavior from only Google Chrome in my PHP/MySQL App. If I try it with Firefox, it works, but Chrome doesn't.
I navigate to some place in my shopping cart and at several places in the code I'll store session data. Don't worry about me starting the session or anything related to that, I've got 11 years in webapp dev, all is done fine.
In all browsers, I can var_dump($_SESSION) and get my data back, but in Chrome it doesn't keep the data. Also note that the session does get passed on, I can look in the network monitor and I see the cookie being sent and many other things related to session work but that one $_SESSION['last_viewed_element'] is not kept. I also can't seem to set anything else, all gets lost.
EDIT:
Problem resolved by switching from SESSIONS TO COOKIES...
I had a very similar problem, in my case the problem was a 404 called due to a missing favicon.ico in Chrome only. The 404.php called the footer which altered the Session Variables.
I hope that helps someone.
The issue could be your server is looking for favicons, if it is not found the server throws out a 302 redirect, which kills the session variables.
I had this issue and was able to fix it. Chrome keeps looking for a .ico file and for some reason it was affecting it. Once I placed the .ico file in the root of the site everything started working. Crazy but true.
I faced same problem, but on IIS with ASP.Net MVC. IE and Firefox were doing fine, but on Chrome I was losing session data. Eventually found out that a 404 error was clearing a cookie in Chrome. Below are the steps I followed to find the problem and resolve. I suggest others to try:
On Chrome, Use Tools -> Developer Tools. Refresh the page so "Developer Tools" starts showing data.
On Developer tools, Check Resources -> Cookies. Right after a successful log in, I had 2 cookies for the domain I was testing. On navigating to the page where I lost session, one of the cookies did not show up anymore. The screenshot was taken after the fix, showing both cookies:
Now check Network tab. Look carefully for any resource (html/image/css/js/...) which has any error. I had a 404 error for a font file. The 404 error was caused by missing mime type in IIS.
fixing the 404 error cleared the problem in Chrome. The screenshot, again taken after fix, had all resources with OK status:
The bonus was, investigating this problem helped me find out missing mime type in IIS, which was affecting more pages on all browsers.
Had same problem and finally solved. Login set session with domain.com but in the redirect it was www.domain.com. IE and FF seem to assume www and no www are same but Chrome doesn't. Found by checking Host in network log for each page load.
Just try this before wasting your time
If you are already logged in your webspace ( control panel / Cpanel / Plesk Panel )
in the same browser. Then logout from that control panel and clear the
cookies and try Again
In case of
session data lost in chrome only
In my case I just reset chrome browser
Go to chrome://settings/ then click advanced then reset
The code I was working with had the same issue. Solved by removing the following:
session_id($_GET['sid']);
session_write_close();
I solved the problem by removing the line:
base href="http://mysite/"
from the head tag in the HTML code.
Looking on the following link:
http://code.google.com/p/chromium/issues/detail?id=45582
I belive the issue is with PHP getting the request that did not match a file and then not properly handling 404's correctly. I had to tell Nginx to match any URL with favicon.ico and then return a 404.
Here is my line for Nginx:
if ($request_uri ~ 'favicon') {
return 404;
}
HA! i finally solved it!
When doing a header() redirect in PHP, you must do a die() right after it. THAT only solves it for all browsers except for Chrome.
For Chrome you also gotta do a session_write_close() right before the header()
Sweeeeeeeeet success
In your php ini file try setting
session.save_path = /path/to/your/tmp
On some servers, sometimes the session needs an explicitly direct session file to save in a local directory or otherwise some weirdness happens.
This solved my problem instantly: go to chrome://settings/cookies then locate your localhost then remove its cookies. The solution is so simple, it's worth a try
We had the same issue yesterday the whole day.
What (seemingly) solved it (for us) was a chrome update.
We had Version 45.0.2454.93 und since the update to version 45.0.2454.99 the problem didn't occure again ...
I had similar problem, I discovered the reason which was very strange.
In my case one image url inside a css class was wrong!! The browser coudn't load the image and because the page was a sign up form with password field, the browser reset the session for security reasons.
I am not sure if your case is similar to mine. But for me the reason was the formation of URL.
With chrome, when typing the URL as "http://www.domainname.com" and setting the session variables there.
and redirecting with "http://domainname.com" without the WWW. the sessionid is not reused.
This resolved my issue hope this is help
You are probably loosing sessions only on your development environment, and it may be most probably because of 'same origin policy' of Chrome. If so, then this is your solution Disable same origin policy in Chrome
I found my version of the issue was exactly as described here and here and so I want to add a further qualifier to the above that
Google Chrome (v.59, stable) Inspector does not tell you that the favicon.ico is inaccessible and does not tell you the page is 302 redirected.
I my case it was just ini_set('session.cookie_secure','1');. I was checking site locally on XAMPP. On FF no problem but when accessing chrome it just kept loosing session.
After all, no answer, problem still exists, i just made a switch to using cookies instead, if anyone ever gets that problem with chrome+wordpress at the same time, dont lose more time, switch to cookies...
I found a "solution" (is not a problem but only effects!!) ...
if in your page use ajax, ajax is asyncronus ...
If I call a function that working on SESSION than i call another page that working on session, some times the first call is not finish before second start and effect of the first overwrite response of the second.
I resolve problem with async:false in every ajax call.
Ext.Ajax.request({
url: '/io/resetsession.php',
**async: false**
});
Ext.Ajax.request({
url: '/io/loaddata.php',
**async: false**,
.....
});
I am developing a site on my localhost, where everything works fine, but now that the site is uploaded to the HTTPS side of our inserted ONLINE /inserted server, the $_SESSION variables don't get carried over from the login.php to the index.php page. Both are located on HTTPS, the process never goes out of HTTPS. As I said, everything worked fine on my localhost.
My localhost's PHP is version 5.3.2 and the HTTPS server is 5.2.6. The only difference in settings I can identify regarding sessions is session.use_only_cookies is On on my localhost and Off on the HTTPS server.
Can anyone please shed some light as to why the session variables are not transferred? PS. I do have session_start(); in both login.php and index.php.
Thanks in advance.
Have you checked that the session cookie is carried over between the HTTP and HTTPS requests? And that the same session token is present on both sides?
If the cookie established via the HTTPS page is marked as "secure only", it will not be transmitted to non-SSL pages, so you'd get a brand new empty session on the non-secure pages, which would give you the symptoms of "missing" session variables. They're not really missing, just in some other session which isn't active now.
There are a few things that can go wrong.
Make sure both login.php and index.php are accessed through https. session.cookie_secure defaults to off, but you never know.
Also make sure they are they both on the same domain. Cookies are set per-domain.
Maybe there is some oddball cookie setting? You can view the current session cookie settings with: session_get_cookie_params()
You can also verify how the cookie is being set in your browser (if at all), for Opera you can right-click in the page, select "edit site preferences", and use the "Cookie" tab. Don't know about other browsers from the top of my head ...
Another possibility is a borked session.save_path, run session_save_path() without any arguments to get the current session_save_path, make sure the user running PHP (typically but not necessarily the same user running the webserver) can write to this directory.