2 questions on "the right way to do X'

JonWoolf

My apologies if these topics have been covered before, but I tried a couple of searches and I can't even think of the right search terms to use in order to look for answers in the forum archives. I have 2 questions concerning the "accepted" way to do things in PHP/MySQL.

1) In PHP, you can handle input from an HTML form either by sending it to a separate PHP file or by making the form part of a PHP file which then calls itself to process the form inputs. I've done it both ways in exercises for myself. Is there a consensus on which way is better? Does it matter if the form is a one-shot thing like a registration vs. a repeating event like entering records into a database? Personally, I find that the first way is easier for me to design and code.

2) When writing PHP code that accesses a MySQL database, I've been writing the database login information directly into the PHP code. Is there any reason why I can't or shouldn't have the login stuff in a single .php file, which I then INCLUDE into other PHP files as necessary? Do I need to worry about somehow disguising or encrypting the login information?

Thanks in advance for any replies I get.

-- Jon W.

Derokorian

1) I would follow what's easiest to design and implement for you. Unless you work at a company that says it must be done a certain way. I personally prefer posting to itself because this allows me to easily show the form again (with already entered data) when errors occur, such as invalid input.

2) If your server is compromised this is the only way to see the PHP source code, in that aspect if your server is compromised the hacker will be able to figure out easily how you obfuscated the login credentials. To me this makes it a moot point and even harder to maintain. I would say definitely put the login information in a single file. Your number one goal should be to reuse code you've already written.

Of course these are my opinions, YMMV.

NogDog

You can make things slightly more secure by putting the config file outside of the web root directory hierarchy, so that it cannot be directly accessed by HTTP calls. Or you can add a bit of code at the top of the config file to exit and throw a 404 if it is being directly called.

<?php

if(realpath(__FILE__) === realpath($_SERVER['SCRIPT_FILENAME'])) {
	header("HTTP/1.0 404 Not Found");
}

// rest of config file...

Derokorian

@ I do something similar, except for I check for a constant that's defined at the beginning of every request (Namely 'ROOT' which is the application root). But all configs are out of the web root, which was hard for me to understand early on 🙂

NogDog

As the Perl users like to say, "There's more than one way to do it." 🙂

If a config file only defines constants and/or variables, nothing much wrong can happen if it somehow gets called directly via HTTP. But I figure if it's never supposed to be accessed directly, then don't let it, just in case someone at some point sticks something in there you don't want to get called when it shouldn't be, or it might output error messages, etc. If you're the sort of person who wears both a belt and suspenders and keeps a length of twine in your pocket just in case, you could put the file outside of the web root, stick my piece of code in there, and check to see if some constant is defined. 🙂

traq

NogDog;11036833 wrote:
…. If you're the sort of person who wears both a belt and suspenders and keeps a length of twine in your pocket just in case, you could put the file outside of the web root, stick my piece of code in there, and check to see if some constant is defined. 🙂

Actually, if I were that sort of person, I'd do this (scroll down to "What Can You Do").

johanafm

traq;11036849 wrote:
Actually, if I were that sort of person, I'd do this (scroll down to "What Can You Do").

I'd +1 it for both this and other reasons. You can change your credentials without touching code. You may want different settings for different web servers, while the application code remains the same and is distributed via github.

NogDog

Though I'm not sure that would be doable without sysadmin support on at least some shared hosting plans?

traq

True. Ironic that it's not practical in the one situation it would really make a difference. But giving sensitive files a different owner is a good idea even on a private server

JonWoolf

Derokorian;11036827 wrote:
1) I would follow what's easiest to design and implement for you. Unless you work at a company that says it must be done a certain way. I personally prefer posting to itself because this allows me to easily show the form again (with already entered data) when errors occur, such as invalid input.

Makes good sense; thanks. In my past programming jobs I've always tried to follow the "whatever fits the situation" rule; problem is, I'm new to PHP, and I'm trying hard to learn how to write it "right" and make my code look good. Last thing I want to do is write it this way when everybody says it should be written that way.

-- Jon W.