I recently installed SSL certificate for my wordpress site(http to https) and now I'm unable to access Wordpress Admin. It refreshes the page and I am not logged in.
Is there something I forgot to change in my wordpress files?
I inspected the code and the login form is pointing to my old site (the http one) and when I look at the code in the file, the form action is set to site_url() and I can't seem to find where it's defined.
I had the exact same problem with my site on NearlyFreeSpeech.net, and the solution was not so simple as fixing the site URLs. That made no difference.
The underlying problem in my case, and the solution, were explained in the post copied below. Note that on my system, the SSL error created two problems, the one described here on Stack Overflow (wp-login refreshes without logging in) and a failure of WP to load stylesheets, which was the problem actually addressed in the forum post quoted below. The solution in the post solves both problems.
What you describe sounds like the browser refusing to load the
stylesheet, which typically happens when first creating an
HTTPS-enabled WordPress site or adding SSL/TLS to an existing WP site.
WordPress isn't very smart about "reverse proxies" like what NFSN
uses, where the user hits an outer web server that then talks to an
inner application server where WordPress actually lives.
If you think you have an SSL-enabled site, especially if it's a new
one, this could be your problem. You would need to edit your
wp-config.php file to add the following:
if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
$_SERVER['HTTPS']='on';
just above the "That's all, stop editing! Happy blogging!" lines.
Conversely, if you don't think you are using SSL on your site, this
won't do anything. Check the alias for your site on the NFSN site
control panel. If you see a padlock, you're set up in NFSN and need
the code above.
WordPress's implementation of SSL is kind of a botch. It not only
doesn't recognize SSL under environments like ours - it also is prone
to redirect loops if everything isn't changed in exactly the right
order. If the code above causes a site outage - you keep getting
complaints from the browser about redirect loops - then remove the
code and ask again. I'll see if I can find my notes about how to do
initial SSL setup.
You need to change the site url in wp-admin->Settings->General. Except now you need to go in through phpMyAdmin and do it manually in the wp_options table since you are locked out.
You get different cookies depending on http/https so you are getting the https cookie and then being redirected to http that has no cookie because of your Wordpress settings that say what url the site resides at.
It is possible to set the site URL manually in the wp-config.php file.
Add these two lines to your wp-config.php, where "example.com" is the correct location of your site.
define('WP_HOME','https://example.com');
define('WP_SITEURL','https://example.com');
For more refer here
or check in table wp_options column option_name = siteurl check the option_value
I have used this first:
i have
if (
isset($_SERVER["HTTP_X_FORWARDED_PROTO"]) &&
$_SERVER["HTTP_X_FORWARDED_PROTO"] == "https"
) {
$_SERVER["HTTPS"] = "on";
}
still not able to fix and nothing happened.
Then I used
define('WP_HOME','https://example.com');
define('WP_SITEURL','https://example.com');
and I was able to connect to wp with https.
Now I have only minor issues of conflict (mixed https/http content on my page) but most things work.
Thank you!
I went to the cpanel>filemanager and edit the file wpconfig.php
inside php tags i added
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) $_SERVER['HTTPS']='on';
Had a similar problem with my wordpress instance.
Using ssh I went in to the directory structure and changed te wordpress root folder permissions to 755 and the .htaccess file to 644.
chmod 755 wordpress/
After that I cloud access my admin panel again.
Go to phpadmin and find wp-options. Change siteurl and home to http. Its work :)
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 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**,
.....
});
Background -
I have my website code hosted on a linux server. My website allows new registrations for employers (http://www.gymandspajobs.com/Employer/Employer.php). The filled-up forms are verified by JavaScripts in the folder "/javascript" and if the information is found ok, the data is submitted via JavaScript HTTP request object and the PHP file "somefile.php" kept in the folder "/somefolder" under the root directory does the database inserts.
Problem -
When a new user tried to register using Firefox (I tested in WinXP SP2, Firefox - v3.5.2), the HTTP response I used to get (which I tapped in my JavaScript file) was
"You don't have permission to access /somefolder/somefile.php on this server." .
Surprisingly, the same functionality worked perfectly well in IE7 and Chrome.
Latest Update on the Problem -
I contacted my web hosting guys and my problem seems to have been solved after I received this reply from them.
We have disabled mod_security for your domain to fix it. We have entered the below lines to the .htaccess file under the httpdocs directory for your domain. We have also verified and successfully able to submit the Employer registration without any issues. ~~~~~ SecFilterEngine off ~~~~~
Though the problem has got solved, I think making "SecFilterEngine off" may not be the best solution to this problem as it compromises security. Hence I asked the hosting guys if there is a way to keep mod_security ON and yet get my functionality to work...... here is their reply.....
Q. is there any way my code can work yet keeping mod_security ON?
Ans. It is possible. But it is not easy. You have to modify the code in the file in such a way that the URI should not have the pattern "!(^application/x-www-form-urlencoded$|^multipart/form-data;)" because we found this entry in the apache error logs -
mod_security-action: 403
mod_security-message: Access denied with code 403. Pattern match "!(^application/x-www-form-urlencoded$|^multipart/form-data;)" at HEADER("Content-Type")
I am using the HTTP object and POST method via JavaScript as -
http.setRequestHeader('Content-Type','application/x-www-form-urlencoded')
Please guide me as to what changes do I need to do in the above line of code so that mod_security can be kept ON and yet my registration form will work?
Thanks and Regards,
-Rupak Kharvandikar-
In this situation the best thing to do is to threat that specific warning as a false positive because it is. Remember that mod_security doesnt support content encoding and false positives is a very normal thing when you are dealing with WAF's.
Disabling all mod_security rules just for one false positive is dumb though. Look for the id of the rule that is getting triggered and disable it "SecRuleRemoveById". In my box I created an additional config to place all the rules i want to disable.
modsecurity_crs_60_myignores.conf
SecRuleRemoveById 960903
SecRuleRemoveById 970903
SecRuleRemoveById 970902
I managed to create an account in Firefox without any issues.