Magento: Warning in PHP in default Adminhtml controller - magento

When debugging Magento, I found this strange warning.
Warning: mysql_real_escape_string() [function.mysql-real-escape-string]: Access denied for user 'apache'#'localhost' (using password: NO) in /mnt/www/t2/app/code/core/Mage/Adminhtml/Controller/Action.php on line 508
In the function checkforSqlInjectionInAction()
From my understanding this warning comes when you cannot open a connection to the database. However in my configuration, I am not using local server, hence this is natural that we cannot connect to the local server.
This warning is in the checkforSqlInjectionInAction().

Welcome to the wonderful world of debugging someone else's Magento code. The core Magento code doesn't contain a method named checkforSqlInjectionInAction, so you're already dealing with a core hack created by someone else's code.
As for your specific error, mysql_real_escape_string will ask the MySQL database what the correct escape character sequence is. However, this function was designed to work with PHP's original MySQL module
The MySQL connection. If the link identifier is not specified, the last link opened by mysql_connect() is assumed. If no such link is found, it will try to create one as if mysql_connect() was called with no arguments. If no connection is found or established, an E_WARNING level error is generated.
Since Magento doesn't use mysql_connect, PHP attempts to creation a connection using the default 'apache'#'localhost' username, with no password.
You should be making your SQL statements using either raw PDO, or the read/write Magento connection resources. These objects allow you to create queries with bound paramaters, where there's no need to manually escape a database string.

Related

"Error: Token Mismatch" After adding a 2nd server to phpMyAdmin

I've been searching and trying to solve this problem for about 3 weeks. I'm stumped. Please help!
I added a second server to phpMyAdmin by adding the following lines to the end of my "config.inc.php" file in the installation directory.
$i++;
$cfg['Servers'][$i]['verbose'] = '<SERVER 2 NAME REDACTED>';
$cfg['Servers'][$i]['host'] = '<SERVER 2 ADDRESS REDACTED>.rds.amazonaws.com';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['compress'] = false;
$cfg['Servers'][$i]['auth_type'] = 'cookie';
$cfg['Servers'][$i]['AllowNoPassword'] = false;
$cfg['Servers'][$i]['ssl'] = false;
After I added this server, we started getting the "Error: Token Mismatch" popup randomly when running some SQL queries or performing certain actions while logged in to server #2. We never got it on the first server we had set up for several years, and I matched all the server configuration settings to those of the first server. The issue is not 100% reproducible with SQL queries, but it does seem to be 100% reproducible when I try to add users to the database via phpMyAdmin's user creation page.
Steps:
log in (select server #2 in the "Server Choice" drop-down menu)
click "users" tab at top of page
click "add user" link
fill out the required fields and click "go"
At this point I always get the "Error: Token Mismatch" popup.
Things I've tried so far:
clear cache / cookies (I do this every time I change settings)
use different browser (tried Chrome, Firefox, and Safari)
change ";session.save_path" variable to “/tmp” in php.ini file
Do "chmod 1733" on the sessions save directory
Made sure there is free space available (19GB free)
After all this, we still get the error.
Software:
PHP: 5.3.29
Apache: 2.2.23 (Amazon)
SQL type: 10.1.23-MariaDB
Database client version: libmysql - 5.5.24
PHP extension: mysqli
phpMyAdmin: 4.2.2
Hardware:
phpMyadmin server hardware: Amazon EC2 m3.large
SQL database server hardware: db.m4.2xlarge
Any suggestions for places to look or things to try are greatly appreciated.
One thing that caught my eye is that you mention the ;session.save_path variable; the semicolon in front of it is a comment so for the directive to be recognized you'll have to remove the semicolon. Check the output of phpinfo.php to verify that the change was successful.
Other than that, it's tough to guess. You're using an old PHP and old phpMyAdmin version, so I'm not saying an upgrade will or won't fix the problem, but you really should upgrade.
One workaround would be to have two phpMyAdmin installations; you can have phpMyAdmin in two different folders, with each one pointing to a different MySQL server. It sounds like it was working fine with one server so if you do it this way, each instance will only have one server and hopefully you won't have the problem.

Need to change DB password in Joomla

The DB password was recently change for a website I'm working on (for reasons I won't get into). As such, Joomla is no longer able to connect to the DB, prompting the error message: Database connection error (2): Could not connect to MySQL.
Fortunately, I do know that I need to simply update the password in the configuration.php file to use the new password, but all of my attempts at making the change have failed. For security reasons I'm sure, I am completely unable to upload my modified configuration.php file. Normally I'd be happy to hear that the configuration file can't be modified, but in this one instance I need to modify it.
How would I go about modifying the file?
You options would be:
Upload new configuration.php via FTP file with new DB password value, however as you mentioned, you're unable to upload it.
Login to your hosting control panel and upload the configuration.php file via the built-in File Manager
Login to and change the password back to it's original value
Get in contact with your hosting provider and find out as to why you're unable to upload the config file.
One of the above options should work, however if all else fails, your last resort will be to contact the person who changed the DB password and ask them to change it back.
Being unable to upload / modify the configuration file, smells like a permissions issue. Maybe the file has permissions set to 444. Many FTP clients allow manipulation of the file permissions. You can set them to 644 for the config. file and then save it. If you can't do this through the FTP client, then try it within the cPanel.

Codeigniter global error override

Is there a way in Codeigniter to override global errors. For instance if an DB error or PHP critical occurs it wont show the error itself but something like 'Our admin guy is fixing the issue' and the error is just logged and emailed.
Codeigniter lets you handle error messages your way, depending on the HTTP status.
Refer to this documentation on error handling
In addition to #Pos5e5s3dFr3ak's answer, you should handle as many errors as you can manually. For example, if you have a database error, your code should acknowledge (or 'catch') it and perhaps load the appropriate view, or pass it onto a library that will log an email the fault, instead of displaying the intended result.
This method can be used as an alternative, or as an addition to the original answer - sometimes you need not locate the error just by its HTTP response Status Code.
As an example, you may find that the database engine in use is down. If this is the case (you would have to determine if it is indeed down - ie. you are not getting the desired response), you would pass the user on to example.com/error/database, for example.

Magento Error: SQLSTATE[HY000] [2013] Lost connection to MySQL server at 'reading initial communication packet', system error: 113

I have copy the magento website from one server to another and done all the necessary changes and now when i opened my new site the following error is coming
There has been an error processing your request
Exception printing is disabled by default for security reasons.
Error log record number: 1237612538
It is showing the numbers of errors first is
a:4:{i:0;s:115:
"SQLSTATE[HY000] [2013] Lost connection to MySQL server at 'reading initial communication packet', system error: 113"
;i:1;s:2374:"
#0 /home/content/32/9503032/html/lib/Zend/Db/Adapter/Pdo/Mysql.php(96): Zend_Db_Adapter_Pdo_Abstract->_connect()
Here is the solution:
Are you sure changed db credentials correct in xml file?
1 .Recheck db credentials with username and password correct or not?
File permisions
compilation mode enable/disable
clear cache
clear sesion
try it
if you want to more detail in error, you can change a little bit step as follows
go to Magento Folder
Magento Folder
errors
local.xml.sample to local.xml
Refresh Page. You will see more detail errors.

MOSS search crawl fails with "Access is denied ..."

Recently the search crawler stopped working on my MOSS installation. The message in the crawl log is
Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)
The default content account is an admin on the site collection that I am trying to crawl.
Almost every result for this error on Google tells me to add the DisableLoobackCheck registry key with a value of 1. I have done this and rebooted and the error continues.
The "Do not allow Basic Authentication" checkbox in my crawl rule screen is unchecked.
Is there anything else that could be causing this error? Something with file system or database permissions maybe?
Edit: All signs seem to indicate that the "DisableLoopbackCheck" should fix this, but it doesn't seem to work. Could I be doing something wrong when I enable this?
I'm doing it in My Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa, where I create a new DWORD key called DisableLoopbackCheck and give it the hex value 1.
It turned out not to be related to DisableLoopbackCheck. The problem was that the search was accessing the site through its external URL. You are supposedly not supposed to be able to access a site from within a server using the same URL that you use to reach it from the outside, at least in pre-SP1 MOSS. But I was doing this for about two years somehow. MS Support tells me they don't quite understand how it was ever working. So it looks like I ran into an issue that should have been manifesting all along. I'm not sure what caused it to appear suddenly, maybe some routine patching of the server. The solution was to extend the web application so it was accessible internally through the machine name, then point the crawler at that.

Resources