Which Mysqli Connection Error Format To Use ?

[2020]

Hi,

3 different tutorials teach 3 different ways on how to get php mysqli echo connection errors.

Which one should I memorise out of these 3 you advise ?
I'd like your rankings on these 3 atleast ....

1.
https://www.php.net/manual/en/function.mysqli-connect.php

$link = mysqli_connect("127.0.0.1", "my_user", "my_password", "my_db");
	if (!$link) {
    echo "Error: Unable to connect to MySQL." . PHP_EOL;
    echo "Debugging errno: " . mysqli_connect_errno() . PHP_EOL;
    echo "Debugging error: " . mysqli_connect_error() . PHP_EOL;
    exit;
}
mysqli_close($link);

2.
https://www.tutorialrepublic.com/php-tutorial/php-mysql-connect.php

$link = mysqli_connect("localhost", "root", "");
 
// Check connection
if($link === false){
    die("ERROR: Could not connect. " . mysqli_connect_error());
}
 
// Print host information
echo "Connect Successfully. Host info: " . mysqli_get_host_info($link);
 
// Close connection
mysqli_close($link);

3.
https://www.geeksforgeeks.org/php-mysqli_connect-function/

    mysqli_connect("localhost", "root", "", "GFG");
 
    if(mysqli_connect_error())
        echo "Connection Error.";
    else
        echo "Database Connection Successfully.";

Q2. On the connection point check, you give your rankings on these following 3 based on your preference.
I ranked like this:

A.

 if(mysqli_connect_error())

B.

if($link === false){

C.

if (!$link) {

Q3. On the connection error reporting point (error message echoing point), you give your rankings on these following 3 based on your preference.
I ranked like this:

A.

die("ERROR: Could not connect. " . mysqli_connect_error());

B.

echo "Connection Error.";

C.

    echo "Debugging errno: " . mysqli_connect_errno() . PHP_EOL;
    echo "Debugging error: " . mysqli_connect_error() . PHP_EOL;

Briefly, let me know:

A). Which connection error checking point to use and which error message echoing point to use.

B). If you got your own that is better and more helpful then explain why it is better over these 3 and any others.

[Barand]

I prefer option 4.

EG

mysqli_report(MYSQLI_REPORT_ALL|MYSQLI_REPORT_STRICT);

$conn = mysqli_connect('localhost', 'someuser', 'wrong_password', 'test');

 

[2020]

1 hour ago, Barand said:

I prefer option 4.

EG

mysqli_report(MYSQLI_REPORT_ALL|MYSQLI_REPORT_STRICT);

$conn = mysqli_connect('localhost', 'someuser', 'wrong_password', 'test');

 

Thank You.

But you forgot to explain why you like option 4 over other 3.

And, you forgot to echo the connection error. let me see how you echo your error. What format you use.

[2020]

@requinix,

@macguyver

 

I need you two's inputs too.

[mac_gyver]

code that unconditionally (always) outputs the raw database statement errors for the connection, query, prepare, and execute statements, only helps hackers when they intentionally trigger errors, since these errors contain things like the database hostname/ip address, database username, if a password is being used or not, part of the sql syntax, and web server path information.

the only time you should output the raw database statement errors is when learning, developing, or debugging code/query(ies) and you are viewing the site as the developer/programmer. at all other times, you should log these errors. the simple way of doing this is to use exceptions for errors and in most cases let php catch and handle the exception, where php will use its error related settings to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) you would then remove any discrete error handling logic, since it doesn't add any value for a legitimate visitor to your site, and it will no longer get executed when there is an error (execution transfers to the nearest exception handler for the type of exception or to php if there is none.) the line that Barand posted enables exceptions for errors for the mysqli extension.

[2020]

13 hours ago, mac_gyver said:

code that unconditionally (always) outputs the raw database statement errors for the connection, query, prepare, and execute statements, only helps hackers when they intentionally trigger errors, since these errors contain things like the database hostname/ip address, database username, if a password is being used or not, part of the sql syntax, and web server path information.

the only time you should output the raw database statement errors is when learning, developing, or debugging code/query(ies) and you are viewing the site as the developer/programmer. at all other times, you should log these errors. the simple way of doing this is to use exceptions for errors and in most cases let php catch and handle the exception, where php will use its error related settings to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) you would then remove any discrete error handling logic, since it doesn't add any value for a legitimate visitor to your site, and it will no longer get executed when there is an error (execution transfers to the nearest exception handler for the type of exception or to php if there is none.) the line that Barand posted enables exceptions for errors for the mysqli extension.

Phew! A lot to digest. No offense, would help if you CAPITALISE your first letter of the sentence.

I never really understood the EXCEPTION thing. I have to research on this to understand your reply.

Only thing I understood from you is to get php show errors on my DEV version for debugging purpose and not on the production version or it somehow gives the hacker an exray of the skeleton of my php script's security side. And if I still want php to show these errors then best show it to me on a file that is accessible to Admin only and not to the world. Especially, not to a visitor as it will scare them the  hell out of my website.

Did I understand you atleast 15% ? Like I said, I have to research on the php EXCEPTION thing before I can understand what you really saying.

Thank You.

Edited July 12, 2020 by 2020

[StevenOliver]

@2020,

Error: process stops, and tells you what you did wrong.
Warning: process continues, and tells you what's wrong
Exception: if error occurs, the code executes what you have in place (called an "exception handler") should such an exception occur.

In development (as opposed to "live for public viewing), I have:
1.) On top of all my PHP pages:
error_reporting(E_ALL); ini_set('display_errors', 1);

2.) In the non-public file above the public_html directory
mysqli_report(MYSQLI_REPORT_ALL|MYSQLI_REPORT_STRICT);
$db = mysqli_connect("localhost" , "username" , "pass" , "database");

(Never ever ever have your mysql credentials in your public www directory.... the day will come when PHP for whatever reason decides to stop working and everybody will get to see your credentials)

I didn't even notice mac_gyver did not capitalize his sentences, I'm here for info, not to be grammar police 😀

But from what I understand mac_gyver is saying (I'm the worst PHP person on this entire forum) is:
1.) turn all the errors on during testing, but MAKE SURE all error reporting is turned off when your site is live for the public.
2.) You can create exception handlers in your php/mysql code so you can debug specific parts of your code, if you want. Otherwise, Barand's #4 suggestion, combined with PHP error reporting on top of all your PHP pages should be sufficient (in most cases) to display most if not all the errors in your code.

[2020]

@StevenOliver,

 

Thank you very much!

I did not know the differences between the 3 (error reporting, warning, exception handler).

Though, I will need to learn more on exception stuff.

I didn't know we shouldn't put db credentials on public_html. Thanks for bringing this to my attention.

One question, if we put it outside the public folder, then how can files inside the public folder access the credential files without the www ?

[Barand]

1 hour ago, 2020 said:

One question, if we put it outside the public folder, then how can files inside the public folder access the credential files without the www ?

By referencing the file system path to the file or by defining an included files folder in your php.ini file.

[StevenOliver]

Oh, I learned something again. I used to do it this way:
<?php
require("../my_secret_file.php");
?>

(The ../ part tells PHP to go up to the directory just above the viewable public_html directory).

But I like Barand's answer: by defining these hidden directories in your php.ini file, it's a bit more secure. Again, if some idiot switches off PHP at your Shared Hosting provider, everyone will be able to see the require("../my_secret_file.php") in plain text. Of course, they still won't see what's in the secret file, but they will know where it's at :-)

You know those interviews they do on TV where the interviewee does not want to be seen.... so they have all the lights out. It's totally dark, and his voice is disguised. During the interview, someone accidentally comes in the room and switches on the light hahahaha. THAT can happen with PHP. And, of course, stuff like that happens while you are on a vacation, or in the middle of the night. So when you log into your site, all of a sudden you see your PHP code everywhere. Or.... worse, you go to your "www.my_supposedly_secure_page.com" and it DOWNLOADS to your desktop as a downloaded file.......THATS always fun. 😀

Edited July 16, 2020 by StevenOliver

[2020]

What is the difference between these 2 and which one better ?

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

mysqli_report(MYSQLI_REPORT_ALL|MYSQLI_REPORT_STRICT);

[2020]

12 hours ago, StevenOliver said:

Oh, I learned something again. I used to do it this way:
<?php
require("../my_secret_file.php");
?>

(The ../ part tells PHP to go up to the directory just above the viewable public_html directory).

But I like Barand's answer: by defining these hidden directories in your php.ini file, it's a bit more secure. Again, if some idiot switches off PHP at your Shared Hosting provider, everyone will be able to see the require("../my_secret_file.php") in plain text. Of course, they still won't see what's in the secret file, but they will know where it's at :-)

You know those interviews they do on TV where the interviewee does not want to be seen.... so they have all the lights out. It's totally dark, and his voice is disguised. During the interview, someone accidentally comes in the room and switches on the light hahahaha. THAT can happen with PHP. And, of course, stuff like that happens while you are on a vacation, or in the middle of the night. So when you log into your site, all of a sudden you see your PHP code everywhere. Or.... worse, you go to your "www.my_supposedly_secure_page.com" and it DOWNLOADS to your desktop as a downloaded file.......THATS always fun. 😀

Thanks. But i didn't get (understand) this part:

"Or.... worse, you go to your "www.my_supposedly_secure_page.com" and it DOWNLOADS to your desktop as a downloaded file.......THATS always fun."

[2020]

On 7/14/2020 at 7:02 PM, Barand said:

By referencing the file system path to the file or by defining an included files folder in your php.ini file.

Show me how to do that. I'm not experienced much with .ini files. Don't understand why they for. What do they do ? Though, have fiddled with them in past following tutorial guidelines but have forgotten what I fiddled or how I fiddled with it. Memory: Blank!

I think it was for greaterising/higherising (my invented words on the spot) the server file permission or memory or whatever!

Edited July 16, 2020 by 2020

[StevenOliver]

2 hours ago, 2020 said:

What is the difference between these 2 and which one better ?

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

mysqli_report(MYSQLI_REPORT_ALL|MYSQLI_REPORT_STRICT);

This is an easy question! Line two has the word "ALL" in it! 😀

[StevenOliver]

1 hour ago, 2020 said:

Thanks. But i didn't get (understand) this part:

"Or.... worse, you go to your "www.my_supposedly_secure_page.com" and it DOWNLOADS to your desktop as a downloaded file.......THATS always fun."

One day I decided to check out my own Shared Hosting website, typed in the URL, and instead of a page appearing, a "file" downloaded to my computer desktop. Turns out that the hosting provider did a mass "upgrade" which broke the custom code in my .htaccess file, which in turn caused all my PHP pages to be considered as "files," which all got downloaded to anyone who visited any of my pages. I learned 2 lessons:

a.) Don't have poorly written .htaccess code which can be 'broken'
b.) Don't have any sensitive data (like your mySQL "conn.php" username password, etc.) in any public directories. Either put them up one level, or, like Barand said, define them in your php.ini so that later, even you won't be able to find them 😀

[StevenOliver]

1 hour ago, 2020 said:

Show me how to do that. I'm not experienced much with .ini files.

I have no clue. Google will have to help you there.

[2020]

2 minutes ago, StevenOliver said:

I have no clue. Google will have to help you there.

I was asking Barand. He must know it. I don't like googling too much. A lot of old codes/techniques and buggy codes. That is why I bug the forums.

Edited July 16, 2020 by 2020

[mac_gyver]

from the documentation -

Quote

 

Supported flags

Name                                               Description

MYSQLI_REPORT_OFF                  Turns reporting off 
MYSQLI_REPORT_ERROR             Report errors from mysqli function calls 
MYSQLI_REPORT_STRICT            Throw mysqli_sql_exception for errorsinstead of warnings  
MYSQLI_REPORT_INDEX              Report if no index or bad index was used in a query 
MYSQLI_REPORT_ALL                   Set all options (report all)

 

 

 

[2020]

5 minutes ago, StevenOliver said:

One day I decided to check out my own Shared Hosting website, typed in the URL, and instead of a page appearing, a "file" downloaded to my computer desktop. Turns out that the hosting provider did a mass "upgrade" which broke the custom code in my .htaccess file, which in turn caused all my PHP pages to be considered as "files," which all got downloaded to anyone who visited any of my pages. I learned 2 lessons:

a.) Don't have poorly written .htaccess code which can be 'broken'
b.) Don't have any sensitive data (like your mySQL "conn.php" username password, etc.) in any public directories. Either put them up one level, or, like Barand said, define them in your php.ini so that later, even you won't be able to find them 😀

Good thing I don't mess with .htaccess unless some tutorial forcing me to. But then I forget what I learnt about .htaccess. or .ini file.
Frankly, I only deal with public_html and can remember things there. Anything outside it, I just copy methods from tutorials to get things done and then forget it a month later how i did it or what I did.

[2020]

2 minutes ago, mac_gyver said:

from the documentation -

 

 

Thanks for the elaboration.

Switching this:

MYSQLI_REPORT_ERROR 

 

to this like barand advised:

MYSQLI_REPORT_ALL