Web Development Questions That Don't Need Their Own Thread v2

[landocalrissian]

I'm re-installing wamp to see if that fixes it

EDIT: Nope still the same, although I've got back the server configuration
[url]http://puu.sh/5r5B[/url]

EDIT: It is parsing the PHP there's quite a bit of PHP before it starts doing that
[url]http://puu.sh/5r5R[/url]

[hzy]

your server might have short tags disabled, try replacing <? with <?php in your script.

[StinkyJoe]

[QUOTE=Fizzadar;32206570]Not really (as Jelly said, excess cookie sending).

Store the users IP in the session, match that against the IP, limits session stealing to computers running on the same external IP.[/QUOTE]

Using the client IP is not the ideal solution, for two reasons:
&#9472; It may cause issues for users in public places, who have no direct control over their connection. (think libraries, dorms, offices, etc).
&#9472; I don't have any hard numbers for this, but I think it's safe to assume a fair amount of [URL="http://en.wikipedia.org/wiki/Man-in-the-middle_attack"]MitM[/URL] attacks also happen in public places, where more often than not the attacker will also be under the same IP address as the victim.

As usual, the best approach is to layer different methods:
&#9472; Do not accept session IDs through GET or POST parameters.
&#9472; Store the client's User-Agent, match the same field in the request against the stored one on every hit (or on every sensitive operation).
&#9472; Refresh the session ID frequently, when appropriate.
&#9472; Require password confirmation on sensitive operations.
&#9472; If applicable, check the HTTP referrer - there are cases where you do not want to accept direct access to a resource unless it was internally linked (see: CSRF, XSS).
&#9472; If you're really dealing with important information, [B]use SSL[/B].

[landocalrissian]

[QUOTE=H4Z3Y;32213773]your server might have short tags disabled, try replacing <? with <?php in your script.[/QUOTE]

Yeah that was it, I've changed it in the PHP settings so I don't make that mistake in the future as well. Thanks for the help

[Lequinx]

[QUOTE=StinkyJoe;32213836]Using the client IP is not the ideal solution, for two reasons:
&#9472; It may cause issues for users in public places, who have no direct control over their connection. (think libraries, dorms, offices, etc).
&#9472; I don't have any hard numbers for this, but I think it's safe to assume a fair amount of [URL="http://en.wikipedia.org/wiki/Man-in-the-middle_attack"]MitM[/URL] attacks also happen in public places, where more often than not the attacker will also be under the same IP address as the victim.

As usual, the best approach is to layer different methods:
&#9472; Do not accept session IDs through GET or POST parameters.
&#9472; Store the client's User-Agent, match the same field in the request against the stored one on every hit (or on every sensitive operation).
&#9472; Refresh the session ID frequently, when appropriate.
&#9472; Require password confirmation on sensitive operations.
&#9472; If applicable, check the HTTP referrer - there are cases where you do not want to accept direct access to a resource unless it was internally linked (see: CSRF, XSS).
&#9472; If you're really dealing with important information, [B]use SSL[/B].[/QUOTE]
Thanks, useful as always.

Another question: Does PDO automatically prevent against SQL injection? Or is it just the prepare method?
(learning PDO)

[StinkyJoe]

[QUOTE=Lequinx;32227103]Thanks, useful as always.

Another question: Does PDO automatically prevent against SQL injection? Or is it just the prepare method?
(learning PDO)[/QUOTE]

If used properly, PDO does in fact prevent SQL injection attacks - just be sure you're using parametrization properly (either through the PDOStatement::bindValue or PDOStatement::bindParam methods, or by passing the values to PDOStatement::execute).

Bad:

$cmd = $pdo->prepare("SELECT * FROM tbl WHERE id=$id");
$cmd->execute();

This bypasses parameter sanitation through direct concatenation.

Good:

$cmd = $pdo->prepare('SELECT * FROM tbl WHERE id=:id');
$cmd->execute(array('id' => 10));

A placeholder is put in place of the parameter and the value given to the PDOStatement::execute method, the PDO library takes care of the rest.

[Lequinx]

Does it only work for PDOStatement::execute, or can it work for PDOStatement::query also? I am selecting from the database, and then rowCounting it.

[StinkyJoe]

[QUOTE=Lequinx;32227407]Does it only work for PDOStatement::execute, or can it work for PDOStatement::query also? I am selecting from the database, and then rowCounting it.[/QUOTE]

PDOStatement::query does not exist, what you're thinking of is PDO::query, which should be used for internal queries where the input is trusted - you CAN sanitize input yourself, but at that point you're better off using proper prepared statements. The same thing applies to PDO::exec, which ONLY returns a number of affected rows, while PDO::query returns a PDOStatement object, ready to fetch from.

[Lequinx]

[QUOTE=StinkyJoe;32227455]PDOStatement::query does not exist, what you're thinking of is PDO::query, which should be used for internal queries where the input is trusted - you CAN sanitize input yourself, but at that point you're better off using proper prepared statements. The same thing applies to PDO::exec, which ONLY returns a number of affected rows, while PDO::query returns a PDOStatement object, ready to fetch from.[/QUOTE]

Oh, so you can select from a table in a pdo prepare statement? If I'm understanding right.

If so I must have read something wrong. I thought select queries could only be made in PDO::query.

[Octave]

[QUOTE=Lequinx;32227527]Oh, so you can select from a table in a pdo prepare statement? If I'm understanding right.

If so I must have read something wrong. I thought select queries could only be made in PDO::query.[/QUOTE]Yes. Any SQL query can be used in a prepare statement.

[Lequinx]

Alright, so I'll stick to prepared code instead of straight up query.

And one more thing, is it best to

try {
    // pdo statements
} catch (PDOException $e) {
    echo $e->getMessage();
}

or is that too much every time?

[StinkyJoe]

[QUOTE=Lequinx;32227527]Oh, so you can select from a table in a pdo prepare statement? If I'm understanding right.

If so I must have read something wrong. I thought select queries could only be made in PDO::query.[/QUOTE]

Oh, not at all. Think of PDO::query as a simpler method for quick or internal queries - one where user input is not used. You can run the same queries you would run with PDOStatement::prepare/execute, without the benefit of parametrization.

PDO::exec is a lot like PDO::query, but you do NOT get a result set back - this is useful for operations where you are, for example, inserting or deleting data. Once again, remember, this method does NOT support parametrization and should generally not be used with user input.

[editline]11th September 2011[/editline]

[QUOTE=Lequinx;32227585]Alright, so I'll stick to prepared code instead of straight up query.

And one more thing, is it best to

try {
    // pdo statements
} catch (PDOException $e) {
    echo $e->getMessage();
}

or is that too much every time?[/QUOTE]

FYI, echo'ing out the error is a major security flaw - but I'll assume you're using that merely as an example. Personally I handle PDO exceptions on a per-case basis - there are some queries where an exception being raised is actually perfectly normal in the program flow context - for example, imagine a username already being in use, and a field constraint causing an error - in that case it may be appropriate to handle the PDOException at that level. Otherwise, I assume exceptions to be an edge-case, and leave them up to a global error handler.

[Lequinx]

[QUOTE=StinkyJoe;32227615]Oh, not at all. Think of PDO::query as a simpler method for quick or internal queries - one where user input is not used. You can run the same queries you would run with PDOStatement::prepare/execute, without the benefit of parametrization.

PDO::exec is a lot like PDO::query, but you do NOT get a result set back - this is useful for operations where you are, for example, inserting or deleting data. Once again, remember, this method does NOT support parametrization and should generally not be used with user input.[/QUOTE]

Alright, makes sense. I should probably stick with PDO::query and PDO::rowCount to return number of rows of PDO::query. But this means I'll have to sanitize the user input since the user input is the variable being checked in the database.

[Octave]

[QUOTE=Lequinx;32227728]Alright, makes sense. I should probably stick with PDO::query and PDO::rowCount to return number of rows of PDO::query. But this means I'll have to sanitize the user input since the user input is the variable being checked in the database.[/QUOTE]No, you should used prepared queries for those:

$user_query = $dbh->prepare('SELECT users.* FROM users WHERE username = :username');
$user_query->bindParam(':username', $username, PDO::PARAM_STR);
$user_query->execute();
$result = $user_query->fetch(PDO::FETCH_ASSOC);

[Lequinx]

[QUOTE=Octave;32227937]No, you should used prepared queries for those:

$user_query = $dbh->prepare('SELECT users.* FROM users WHERE username = :username');
$user_query->bindParam(':username', $username, PDO::PARAM_STR);
$user_query->execute();
$result = $user_query->fetch(PDO::FETCH_ASSOC);

[/QUOTE]

I see, but how would I get the number of rows, like mysql_num_rows? That's giving me an associative array.

[deadeye536]

[QUOTE=Lequinx;32228213]I see, but how would I get the number of rows, like mysql_num_rows? That's giving me an associative array.[/QUOTE]

[url=http://php.net/manual/en/pdostatement.rowcount.php]$user_query->rowCount();[/url]

[Lequinx]

[QUOTE=deadeye536;32228349][url=http://php.net/manual/en/pdostatement.rowcount.php]$user_query->rowCount();[/url][/QUOTE]
I got confused because of this:
[QUOTE=StinkyJoe;32227615]PDO::exec is a lot like PDO::query, but you do NOT get a result set back[/QUOTE]

[TehWhale]

[QUOTE=deadeye536;32228349][url=http://php.net/manual/en/pdostatement.rowcount.php]$user_query->rowCount();[/url][/QUOTE]That doesn't return the number of rows in a select query.

[Lequinx]

Requesting stinkyjoe!

[TehWhale]

stinkyjoe is the only one that knows pdo yeah ask him

[TheDecryptor]

Not all DB engines expose that information via the PDO layer, MySQL does, but SQLite doesn't (etc.)

[StinkyJoe]

wtf guys it's 6am

AFAIK, that information is not exposed, like TehWhale said, for SELECT statements. You can use the MySQL function [B]FOUND_ROWS()[/B] (with a PDO::exec call), but for most scenarios it's probably easier to just use the following:

count($statement->fetchAll(PDO::FETCH_ASSOC))    // returns an int

The legacy mysql library pretty much did the same if I remember correctly - all results were fetched, buffered and counted internally.

[Pugsworth]

Are there any ways to get all the tabs in a window with javascript?

[StinkyJoe]

[QUOTE=vexx21322;32228872]Are there any ways to get all the tabs in a window with javascript?[/QUOTE]

Pretty sure that's a big no, as it'd violate user privacy, even if getting the number of tabs seems like a completely innocent thing to do.

[Fizzadar]

[QUOTE=vexx21322;32228872]Are there any ways to get all the tabs in a window with javascript?[/QUOTE]

Only with a plugin for the browser...

[editline]10th September 2011[/editline]

and where the fuck is my avatar?

[Jelly_]

[QUOTE=Fizzadar;32229491]Only with a plugin for the browser...

[editline]10th September 2011[/editline]

and where the fuck is my avatar?[/QUOTE]

Garry disabled them for blues.

[deadeye536]

[QUOTE=TehWhale;32228446]That doesn't return the number of rows in a select query.[/QUOTE]

Works just fine on my end;

$sh = $dbh->prepare('SELECT * FROM sometable');
$sh->execute();
print $sh->rowCount();

Returns 23, the number of rows in the table.

[hugg]

So right now in my project I use cookies with a username, and hashed password from the database (so I can use the info to check if they're a valid user if they actually do something). Is there anything I should do differently?

[MuivirT]

I am looking for a proper hosting service which supports ASP.NET 4.0 websites.
Preferably located in the Netherlands. Does anyone know a propper host which supports ASP 4.0?

[TheDecryptor]

[QUOTE=FlashStock;32231961]So right now in my project I use cookies with a username, and hashed password from the database (so I can use the info to check if they're a valid user if they actually do something). Is there anything I should do differently?[/QUOTE]
Instead of using their password, use the time they log in instead (so username + time), that way the hash will change each time they log in (You'll want some means of expiring it as well), and it stops somebody getting a copy of their hashed password.