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**,
.....
});
Related
This is the URL of the site I am referring to: http://www.nagorik.org/
The site seems to be working fine.
However, when I am trying to access the admin site through http://www.nagorik.org/wp-login.php, I get the following message in Firefox:
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
This problem can sometimes be caused by disabling or refusing to accept cookies.
Any idea why this might be happening?
Some notes:
I checked the error log file; nothing new in it.
I have nagorik.org redirecting to www.nagorik.org
Firefox has detected that the server is redirecting the request for
this address in a way that will never complete. This problem can
sometimes be caused by disabling or refusing to accept cookies.
Let's try to check the cookie settings to see if it helps.
https://support.mozilla.org/en-US/kb/enable-and-disable-cookies-website-preferences
One issue I see is you're missing a ton of Wordpress files in /wp-admin/. You might want to consider reinstalling wordpress or at least re-uploading the /wp-admin/ directory.
I have recently updated my wordpress to 3.8. Since then I appear to not be able to login to Wordpress.
I get the error message "ERROR: Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress." thing is cookies are working fine. They ARE enabled. I've cleared them tried different browser everything. I think it might be something in the WP settings.
I have tried the fix for commenting out the cookie check in the wp-login.php
I would appreciate any help getting my wordpress site working again.
Try to add below code in your theme's function.php
//fix for cookie error while login.
setcookie(TEST_COOKIE, 'WP Cookie check', 0, COOKIEPATH, COOKIE_DOMAIN);
if ( SITECOOKIEPATH != COOKIEPATH )
setcookie(TEST_COOKIE, 'WP Cookie check', 0, SITECOOKIEPATH, COOKIE_DOMAIN);
One more option which worked for me, I developed my client's on my server and it's URL is "www.mydomain/clients/clientname" when i deployed it to client's server on main domain i was getting this cookie issue in WordPress backend, tried almost every solution available online but this one worked for me.
Go to wordpress database and check "wp_options" option table and change url to you domain URL Woila! worked for me.
See if this can help someone.
I think you have just cleared your cookies and then trying to login to your site. If you are doing such then I suggest, you have to refresh your browser's tab after doing clear cache cookies and then login. Hope it may help you out. Thanks.
I managed to fix the problem although I am not 100% sure what caused it.
Firstly I changed the name of the plugins folder. This allowed me to atleast login.
I then renamed the folder back to plugins. This will now show all the plugins again, however they will now be deactivated.
I went through each plugin login out each time to see if I could login. When I found the plugin I deleted it. I then reinstalled it and tested the login / logout. It works fine now.
Happy but bemused at why it failed in the first place.
I hope this help someone else. The plugin causing the apparent problem seemed to be Youtube Channel Gallery
Cheers.
I have faced the same problem.
The problem is with version update of wordpress in my case and reset the password using http://codex.wordpress.org/Resetting_Your_Password after I added
error_reporting(E_ALL);
ini_set('display_errors', 1);
after I see the problem is
Warning: Cannot modify header information - headers already sent by (output started at /zz/zzz/file.php)
after checking the file contains extra lines after PHP end tag(?>). Removed the empty lines and spaces after the end tag solved the problem.
Hope it will help someone.
I realize that this is an old thread, but chances are that the problem resurfaces from the past like it did for me. I accidentally discovered the problem using a link to my login page without the SSL enabled. To give a quick fix I merely changed http:// to https:// in my browser and was able to log in to the admin panel. I had the problem a few months back and forgot that I updated my bookmarks to https, but the login link in the WP meta links in the widgets takes you to the unsecure page (which just bit me yesterday again). I'm not positive that this is the only cookie issue, but it has caught me twice now. I skimmed the wp-login.php and I think that line #768
$redirect_to = preg_replace('|^http://|', 'https://', $redirect_to);
may be the problem, but sadly my time challenge doesn't allow me to check further...
You no need to worry about this issue in wordpress. It is the problem from functions.php page in your theme. The problem is that you need to remove spaces after and before closing of PHP tags. I mean
1
5
6
Note you need to clean up the code as follows.
1
I think you got my point. I faced the same issue and searched for the solution number of times. Finally I downloaded my theme into my local editor checked that functions.php page and cleaned up it as above. Finally, I resolved this issue. But, I spent 2 days to get the solution. Thanks. Braj
I have a rails app running on Heroku, and I am trying to get a Wordpress blog set up on /blog for my domain for SEO purposes. I have Rack::ReverseProxy set up in my rails app pointing to the blog's subdomain, and have all of the configuration on the Wordpress side set up so all of the css and links work correctly. The problem I'm having is that when I go to /blog/wp-admin I am redirected to /blog/wp-login?redirect_to={blog's subdomain}&reauth=1, and after trying to log in I'm sent to the same page.
I've noticed that I'm not being cookied for the login even though Wordpress's Test Cookie is being set for the correct domain. I've even traced it through and in wp-includes/pluggable.php in wp_set_auth_cookie where it actually sets the cookie after a successful login, the calls to setcookie are returning true, but immediately after the cookies aren't added to my session (even though the Test Cookie does come through in the headers successfully)
Am I going down the wrong direction looking there? Are there any settings I should investigate to be able to log in this way?
I had this exact problem, and I finally tracked it down to a bug in rack-reverse-proxy. The set-cookie header was being sent in an improper format, so only the first cookie was being interpreted correctly by the browser. That happened to be the wordpress test cookie. All the other (useful) ones were being thrown away, so of course I could not log in.
I plan to submit a bug and branch to rack-reverse-proxy but in the meantime I fixed it with this patch in my config.ru:
class MyReverseProxy < Rack::ReverseProxy
private
def create_response_headers(http_response)
response_headers = super(http_response)
if response_headers
if response_headers["Set-Cookie"].is_a?(Array)
response_headers["Set-Cookie"] = response_headers["Set-Cookie"].join("\n")
end
end
response_headers
end
end
# this is to make /blog show my wordpress blog
use MyReverseProxy do
reverse_proxy_options :preserve_host => false
reverse_proxy(/^\/blog(\/.*)$/, 'http://your-blog-server.com$1')
end
I don't have an answer but I have a few suggestions to get a better understanding of what's going on.
If you are using Google Chrome, open the Network panel of the Developer Tools and watch what happens when you login.
Check to see which domain the cookies are being set for, when you look at the response headers for the POST request that processes your login, you should see Set-Cookie header(s), check whether that domains is .domain.com or blog.domain.com and see if that request is trying to forward you to a different place.
Another possibility is that your Wordpress installation may be configured differently than you want it, for example the site URL being www.domain.com/blog instead of blog.domain.com
Is it possible for you to go to the login page at blog.domain.com/wp-admin/?
I've set up a new server for my magentocommerce.
Unfortunatly when I moved the domain to the new location (tests have been done using another domain) a weird issue started happening: when the login page displays on the frontend, or the backend and I (and customers, of course) do submit the right credentials the page refresh, the cookie gets set but the form is displayed again. It's such a cache being served instead of the right content (catalog).
The only solution actually is delete the cache on the browser and retry.
I've used varnish http accelerator for two days, but since I've had too much issues dealing with it I uninstalled it and cleaned things up (now there's only the apache instance to serve user requests).
I also installed APC caching and Fooman Speedster.
What can it be to cause this issue?
Can you please help me to get in the right direction to fix this issue? On the old server it was not happening, but since that time there have been some modification to the store (nothing to do with authentication anyway).
The apache error log does not report anything, the only thing in there is PHP: syntax error, unexpected BOOL_TRUE in /etc/php5/apache2/conf.d/apc.ini on line 4 which has to do with the line apc.enabled = 1.
Look at the System -> Configuration -> Web tab in the admin panel and see if the Cookie Path and Cookie Domain are set correctly for the new server. You can do it directly in the database as well. In this case, search for rows with web/cookie/cookie_path and web/cookie/cookie_domain paths. Setting them to empty values in the admin panel or NULL in the database may also help.
You should also clear Magento cache (System -> Cache Management) and APC cache (here's how to do it: How to clear APC cache entries?).
I don't know if it solves your specific form problem but we had the same error in the apache error log.
Our failure was, we've copied the apc.ini code from http://magebase.com/magento-tutorials/speeding-up-magento-with-apc-or-memcached/. They use "#" for comments.
Turns out we had to use ";" for comments. After these changes, there were no more errors in the apache error log.
I have a problem where i am losing the PHP session between 2 pages.
The session_start() is included in a file called session-inc.php into every page requiring a session to be set. This works for all pages on the site except one particular page, member-profile.php. When this page is visited a new session with a different id (same session name) is set and used instead.
A few more details:
Session name is set manually
All pages are on the same server under the same domain name
If i put an additional session_start() above the include('session-inc.php') in the member-profile.php file, the session is carried over correctly
I have tried setting the session_cookie_domain and session.session_name in the .htaccess, this worked for this domain but it stopped the session being passed over to out payment domain
We are running apache 2.2.6 with php 5.2.5
Putting the session_start() above the include('session-inc.php') in the member-profile.php file is the quick and dirty fix for this problem, but i am wondering if anybody know why this would be happening.
Cheers
Will
According to PHP documentation, session_start must be called before any output is sent back to the browser-- could this page have a rogue CR/LF, Unicode byte-order mark or similar that is causing output before you include('session-inc.php')?
While migrating a legacy site from PHP4 to PHP5 I noticed a php.ini configuration setting that causes php to auto-start the session upon every request. It's an alternative to placing session_start() onto every page...
There are multiple ways to enable this setting:
Put the following line into php.ini:
session.auto_start = on
or put this into your apache virtual-site config or .htaccess file:
<IfModule mod_php5.c>
php_flag session.auto_start on
</IfModule>
and it should make $_SESSION changes available across all pages
I have just encountered this problem. Interestingly, browsing via http://127.0.0.1 instead of http://localhost helped me.
I just spent all day diagnosing this issue in my Ionic3 - to - PHP project. TL; DR - make sure your client is actually sending session credentials.
In the interest of helping anyone who makes this mistake, I will share how I found the problem.
I used these tools to diagnose the session on both the client and server:
1) Add a test file with phpinfo() to the server to review PHP session options.
2) Review the PHP code to make sure that no output, intentional or un-intentional occurs before the session_start() line. Check the status bar of Visual Studio Code to make sure the Byte Order Mark (BOM) is absent from the PHP files.
3) Review server PHP logs (in /var/log/nginx/error.log for me). Add error_log() lines to the php file to dump the session_id() or $_SESSION array.
4) Use tcpdump -An 'port 80 or port 443' to view the actual HTTP requests and replies. (That's where I discovered the missing cookies).
For an Ionic3 data provider the correct syntax for the client is:
var obsHttp = this.http.post(url, body,
{ headers: new HttpHeaders({
'Content-Type':'application/x-www-form-urlencoded'
}),withCredentials: true }).timeout(this.timeoutTime);
Notice the withCrentials:true
One needs to call subscribe on the obsHttp() observable to send the request.
Found the issue
There was a byte order mark at the beginning of the main includes file of the second domain. as stated by ken, cant have any output before a session start, it was not setting the session correctly.
SOLUTION:
session.auto_start = on
in file: php.ini
It solved the issue of re-generating session id on page reload (page refresh / change pages).
The issue appeared after the update of CPanel (and included Multi PHP), even the php version remained the same.
The PHP.ini file didn't had that variable at all.
Went in Cpanel -> MultiPHP INI Editor -> Editor Mode (not Basic, in basic you do not have this setting) and added the line. Press Save.
TIPS / WHEN TO USE THIS SOLUTION:
To determine if that is the problem, put a line at the very beginning and at the very end of your index.php file to check the session id. Use function:
session_id();
Navigate through pages / reload the page. If the session_id value changes the problem is not in your code and this solution should solve your problem (the session is lost outside of your code).
I also tried to verify the availability of saving session on the web server (session.save_path) but, even if it was a lead, it was not the case.
I imagine this is a "feature" of Cpanel with MULTIPHP UPDATE that will happen quite often.
I had this problem, and the cause was that PHP was ignoring all cookies after the first 100. (I asked this question to try to find out why, but so far nobody has figured it out). The browser was sending the PHPSESSID*, but since it was the 110th cookie, PHP was ignoring it.
To figure out if this problem is what's affecting you, use your browser's dev tools to look at the cookies that the browser is sending with the request, and compare that list to the $_COOKIE array in PHP. They should be the same. But if the browser is sending a PHPSESSID*, and there's no PHPSESSID* in $_COOKIE, then that would explain why sessions aren't working.
I solved the problem by not having my site use so many cookies, which is good practice anyway.
*PHPSESSID is the default session name. Your site may use a different name.
To solve the session_id change after each request, you change the parameter session.auto_start and session.cookie_httponly into the php configuration file.
to find the used php configuration file
php -i | grep "php.ini"
then you open it, and try to find the parameter session.auto_start . you set
session.auto_start = 1
session.cookie_httponly = 0
finally you restart your httpd/apache service.
Found the issue
In my case it was due to Varnish Settings please check your varnish settings. PHPSESSID you can exclude the cookie from the Varnish Settings.
I'm not an expert, but found a solution after careful investigation of domain name in the cookies info of two webpages opened on Firefox. (Right click on the page, select inspection and the storage). checked domain names and found that one with www.example.com and the other without www (example.com). changed all the page links to same format and the problem solved for my case.
Found the problem was a byte order mark (BOM) being ouputted at the start of the file. Got rid of it and it sorted out the session problem.