scootstah

Try adding GROUP BY tblModel.modelID

I don't know what you mean by "first and second one". But, I do see a problem in your code. At the top, you need to be reassigning $modno and not adding to its value. Also, you are calling trim() before you check if it exists - if it doesn't exist you're going to get an error. You can use typecasting here and make the code a bit simpler. $modno = (int) (isset($_GET['modno']) ? $_GET['modno'] : 0);

Nothing, they just seem clunky for this purpose. What if you need multiple database connections with different credentials?

On a side note, PHP's concatenation operator is a little bit cleaner $SQLstmt="SELECT * FROM tblModel,tblImages"; $SQLstmt .= " WHERE tblModel.modelNo = $modno"; $SQLstmt .= " AND tblModel.modelID = tblImages.modelID"; I also added the spaces xyph was talking about.

The problem with that approach is if something else is in curly brackets it will swap that out too. Like this: $result = my_query("INSERT INTO {some_table} ('{something in curlies}')"); Produces: INSERT INTO someprefixsome_table ('someprefixsomething in curlies') You could make the regex a little more elaborate, but I don't think the problem would go away. EDIT: I'm not a huge fan of loading my config files with constants, but it is an option. I'd probably go with something like: function config($key) { $config = include 'config.php'; if (array_key_exists($key, $config)) { return $config[$key]; } return null; } config.php return array( 'db_prefix' => 'prefix_' );

For the most part, they do it the way thorpe suggested. The only thing I have to add is make sure you use proper namespacing, instead of just $prefix, to make sure the variable is not replaced somewhere.

Have you tried the username without the host attached?

I don't know of any. You can use debugging tools to create stack traces and such, but I don't know if that will be any help or not. Unfortunately in these situations where there is no obvious application structure, you just have to take the time to work through the code and find out what it does. It is a pretty arduous task.

Post the code please.

Here's a pretty good article for session hijacking: http://phpsec.org/projects/guide/4.html

Have a look at this xkcd comic to see why you're wrong.

Who said the key was going to be revalidated on every load?

It doesn't matter if it is "encrypted", there is no reason to store passwords in a session. Ever. Besides, your code doesn't really offer any functional difference to storing a logged in flag in the session. You are simply checking to see if "username" or "password" keys exist, instead of a "logged_in" key.

You think storing a "logged in" flag is bad but storing their password is okay? Seriously?

Seems pretty silly to save whether or not a user is logged-in in their session. The session shouldn't be telling itself it is active, a 3rd party function should identify that as true or false. How else are you going to persist the login?

Just so you're aware, "maxlength" is purely visual feedback to the user. It is easily circumvented and offers no other use. If you want to enforce minimum lengths, you must do it with PHP. Which brings up another good point. You don't need to filter out characters for passwords either, since it's going to be hashed. It can't cause SQL injection because it is hashed before it gets there, and it can't cause XSS because you won't ever be displaying it in plaintext. So, again, there's no logical reason to filter characters.

Well, to read an Article you need a query string in addition to the "article.php" file itself, e.g. So if I just loaded "article.php" by itself I get... Maybe that just means I did not properly do all of the Error-Handling I needed to? I haven't tried loading all of my files directly, but the example above is what prompted this thread... Debbie Then it sounds like you just need to come up with some default behavior. For example if no article ID is available, maybe list all of the articles... or just redirect like kicken said.

So if you are directly loading the files anyway, I don't really understand what you are asking.

Because that's what hash algorithms are designed to do. There is just as much chance to get a collision from hashing "a" and "b" than there is from hashing the content from two different books.

If you're only ever going to use their username, then fine, put it in a session. But, there's a bunch of other things I can reasonably see being used from a user table on every page load. Like: a profile picture, forum posts, last login, etc. So, if those would be queried for anyway then you might as well get the username at the same time.

They can, but it is not the same as $_SERVER['PHP_SELF']. If you use $_SERVER['PHP_SELF'], people can add data to the URI which would then show up in the action,; ergo an XSS attack. However if someone modifies the action attribute, they are the only ones that are going to see it - it's not possible to effect anyone else that way. I don't really like $_SERVER['SCRIPT_NAME'] either though, since it disregards query strings. So my opinion is that you should either use a reliable way to get the current URI or leave the action blank/omit it.

I vote for the index. Unless your website is unnecessarily complicated, it shouldn't take them long to get back where they were.

Perhaps, but what if you want additional information? Are you going to end up storing the entire user table in a session? Besides, running a simple select query on every page load isn't really a big deal.

No. Hashes are commonly used to verify the integrity of files, which could be millions of bytes. Do you really think that small amount of data is going to hurt anything?

The answer to all of the above is: it depends how you have structured your application. If you have something like below then you can just deny the whole directory (if profile.php is include'd through index.php). docroot/ app/ profile.php news.php index.php If it looks more like below then it'll probably be slower and harder to maintain. docroot/ index.php profile.php news.php How is profile.php normally loaded?