Web Development - WAYWO - #8

[KmartSqrl]

LOL. I just looked at the calendar and realized that the stuff I was trying to get done this week doesn't actually need to be done until the end of next week for us to hit the ideal timeline we set up (pushing it out another week wasn't a big deal so I wasn't super concerned about finishing 100% today).

Because I had the dates in my head wrong, I have all next week to polish the ecommerce stuff that I built this week :)

Hooray!

[Ac!dL3ak]

[QUOTE=Suedeshoes;40174385]Sounds like you resized hte disk, but not the partition. Something like GParted will fix it, and there's command line tools for it as well.[/QUOTE]

16GB is the size of the partition, not the disk.

[editline]6th April 2013[/editline]

[img]https://dl.dropbox.com/u/11275736/Src/2013-04-06_01-03-26.png[/img]

[Vietnow]

You know those issues you get that are caused by something so insignificant, yet cause your entire website to fail? I've had three of them in the last 24 hours.

Excuse me while I wash all that stress out of my body with copious amounts of alcohol.

[Ac!dL3ak]

[url]https://github.com/redjazz96/orator[/url]

woop

it's websockets for rails

I'm constantly modifying it, and I want to see what I can do better, any ideas?

[editline]11th April 2013[/editline]

Maybe have it automagically assume the orator name...

[editline]11th April 2013[/editline]

I'm working on an implementation of it here

[url]https://github.com/redjazz96/chattr[/url]

I found out I'll need to add a rake task to orator in order to get it working with Rails completely, so that'll probably be what I'll do next; after that, I'll also move the event mappings out of the actual orators and put it in a separate file, like the regular routes. I'll also probably move most of the logic out of the orators, because it looks really messy right now.

[editline]11th April 2013[/editline]

also what the fuck [url=https://rubygems.org/gems/orator]~650 downloads[/url] on rubygems, and it's not even past version 1.0

[j4NZKUE]

[url]http://ezyimg.com/5qY5b8[/url]

Have been working on my own weatherapp. [url]http://weatherapp.janlehtinen.com[/url]

Soon with Geo location support and going to make a better design

[xmariusx]

[QUOTE=j4NZKUE;40261855][url]http://ezyimg.com/5qY5b8[/url]

Have been working on my own weatherapp. [url]http://weatherapp.janlehtinen.com[/url]

Soon with Geo location support and going to make a better design[/QUOTE]

It doesn't work :(
[url]http://architech.fi/weatherapp/index.php?location=T%C3%B8nsberg&submit=Submit[/url]

[j4NZKUE]

[QUOTE=xmariusx;40266730]It doesn't work :(
[url]http://architech.fi/weatherapp/index.php?location=T%C3%B8nsberg&submit=Submit[/url][/QUOTE]

yea still need to fix some special character encoding, thanks for the info :)

[Sharpshooter]

Working on a GMOD loading screen at the moment, well its finished but I just hit a bit of a problem. Its my first time using PDO and I decided that as the database interaction on the loading screen isnt vital I would catch any database errors and drop them to a log file, its worrying to find though that PDO is quite happy to display the database password in error messages. So I swapped to PDO as a more secure lightweight alternative to traditional database abstraction layers only to find a pretty bad security flaw. What do.

Anyone have any ideas or encountered this before? I don't want to just turn errors off really.

[Coment]

[QUOTE=Sharpshooter;40268267]Anyone have any ideas or encountered this before? I don't want to just turn errors off really.[/QUOTE]

Try with

                   try {
                        $DB = new PDO(<details of your database>);
                        $DB->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
                        } catch(PDOException $e) {echo 'ERROR: ' . $e->getMessage();}

; then, do any PDO operations with:

 try {
<your PDO queries and all that>
  } catch(PDOException $e) {echo 'ERROR: ' . $e->getMessage();}

[Sharpshooter]

Still does it unfortunately, here is the error I am talking about:

<13-04-13 20:37:36> <Client IP Address = 127.0.0.1> <Error: exception 'PDOException' with message 'SQLSTATE[28000] [1045] Access denied for user 'root'@'localhost' (using password: YES)' in H:\WAMP\www\loading_screen\index.php:33
Stack trace:
#0 H:\WAMP\www\loading_screen\index.php(33): PDO->__construct('mysql:host=loca...', 'root', 'mockpassword')
#1 {main}>

not comfortable with it just displaying the database user password like that.

[TehWhale]

you're entering the wrong password if it tells you 'access denied for user x'

[Sharpshooter]

[QUOTE=TehWhale;40269740]you're entering the wrong password if it tells you 'access denied for user x'[/QUOTE]

Yeah I know, but if I select the wrong database for example, or make a typo with it (or anyone else does it for that matter) then it dumps the string including the password into the log file. Surely its a bit of an oversight?

[KmartSqrl]

You shouldn't be developing on your production site in the first place, so those errors should never see your production server.

You also should be logging php errors but not displaying them on the production site so that nothing like this is ever seen on your live site.

[Sharpshooter]

I am not developing in the production environment, the error was just for an example, its true that they should never make it to a production environment, but then theres the issue of when things go wrong, or an implementation by one developer has an effect on a seperate function on the website which should be checked but could be quite easily overlooked.

The errors are logged and not displayed on the page so it isnt seen, I just figured that having no form of censoring on the password field is a pretty big mistake, I log the errors and don't display them to the user but that doesn't mean the next person will (although you should never spew out the technical error messages to the user).

In my case I can just deny access to the downloading of the file through the web server.

[CBastard]

Just been working on my developer/debug panel for my PHP framework. Currently it shows performance, queries (with the file and line it was called from), included files and any framework or application errors. Applications can also include their own break points and panels here.

[url=http://i.imgur.com/CyM5roh.png] [img]http://i.imgur.com/EDHX8jb.png[/img] [/url]

Any thoughts on separating it into tabs and other features that would be useful?

[asantos3]

[QUOTE=j4NZKUE;40266813]yea still need to fix some special character encoding, thanks for the info :)[/QUOTE]

Not only special character encoding:
[url=http://architech.fi/weatherapp/index.php?location=Tomar&submit=Submit]http://architech.fi/weatherapp/index.php?location=Tomar&submit=Submit[/url]
If you want to make a "international" weatherapp make it so it can give you a list of similar cities, even support almost all cities from all countries, maybe grab the info from multiple places (?). See google:
[url=https://www.google.com/search?q=tomar+weather]https://www.google.com/search?q=tomar+weather[/url]

[editline]13th April 2013[/editline]

Oh, what about wind, precipitation and include the next days.

[Darkwater]

[QUOTE=Sharpshooter;40269674]Still does it unfortunately, here is the error I am talking about:

<13-04-13 20:37:36> <Client IP Address = 127.0.0.1> <Error: exception 'PDOException' with message 'SQLSTATE[28000] [1045] Access denied for user 'root'@'localhost' (using password: YES)' in H:\WAMP\www\loading_screen\index.php:33
Stack trace:
#0 H:\WAMP\www\loading_screen\index.php(33): PDO->__construct('mysql:host=loca...', 'root', 'mockpassword')
#1 {main}>

[B]not comfortable with it just displaying the database user password like that.[/B][/QUOTE]

You might want to make it like this then:

$db = new mysqli(DB_SERVER, DB_USERNAME, DB_PASSWORD, $use_db);

And then in another file:

define('DB_PASSWORD', sprintf('%c%c%c...etc...', 12*24+5, 50+2*5, 10*20+40, ...etc...));

A quick look at either of the files won't reveal the password.

[editline]14th April 2013[/editline]

Btw are there any real advantaged with PDO over MySQLi?

[Sharpshooter]

Its immune to SQL injection I believe.

[shodan]

[QUOTE=Sharpshooter;40271178]Its immune to SQL injection I believe.[/QUOTE]

How can it be immune to SQL injection?
Do you build your query using the PDO instead of just a string?

[buhbang]

[QUOTE=Mega1mpact;40271364]How can it be immune to SQL injection?
Do you build your query using the PDO instead of just a string?[/QUOTE]

it escapes all the strings for you before you execute it by preparing.

[CBastard]

[QUOTE=jung3o;40271424]it escapes all the strings for you before you execute it by preparing.[/QUOTE]

Not if you don't use prepared statements or use them properly.

$statement = $pdo->prepare("SELECT * FROM supersecretstuff WHERE id = ".$_GET['id']);
$statement->execute();

or just.

$pdo->query("SELECT * FROM supersecretstuff WHERE id = ".$_GET['id']);

:v:

To anyone skimming this post, don't do this.

[buhbang]

[QUOTE=CBastard;40271509]Not if you don't use prepared statements or use them properly.

$statement = $pdo->prepare("SELECT * FROM supersecretstuff WHERE id = "$_GET['id']);
$statement->execute();

or just.

$pdo->query("SELECT * FROM supersecretstuff WHERE id = "$_GET['id']);

:v:

To anyone skimming this post, don't do this.[/QUOTE]

To anyone skimming this, please take a look at [url]http://php.net/manual/en/pdo.prepare.php[/url] before you do anything stupid.

[TehWhale]

The correct way is something along these lines:

$login = $this->dbh->prepare('SELECT uid, username, email, flags FROM users WHERE username = :username AND password = :password');
$login->bindValue(':username', $tUsername, PDO::PARAM_STR);
$login->bindValue(':password', hash('sha256', $this->salt . $tPassword), PDO::PARAM_STR);
$login->execute();

[editline]13th April 2013[/editline]

Criticize my code for me: [url]http://pastie.org/private/0ftlwpxviuzwrzxfnep2la[/url]

What should I improve on?

[CBastard]

I can't see anything wrong, it looks good, if it is wrong I'm doing it wrong as well :).

Personally I'd abstract out the PDO into a database class so you can reuse your error handling and potentially add other features but this isn't really necessary.

Here's mine currently: [url]http://pastebin.com/hesY4t9y[/url]. Usage is fairly simple and a bit cleaner.

$this->db->prepare("SELECT * FROM `utime` WHERE steamid64 = :id64");
$this->db->bind_value(':id64', $id64, 'string');
$this->db->execute();
$userdata = $this->db->prepQueryFirst();

[Darkwater]

Can't you just call $db->real_escape_string($str); and then insert it in the query when using mysqli?

[TerabyteS_]

[QUOTE=Darkwater124;40270827]You might want to make it like this then:

$db = new mysqli(DB_SERVER, DB_USERNAME, DB_PASSWORD, $use_db);

And then in another file:

define('DB_PASSWORD', sprintf('%c%c%c...etc...', 12*24+5, 50+2*5, 10*20+40, ...etc...));

A quick look at either of the files won't reveal the password.

[editline]14th April 2013[/editline]

Btw are there any real advantaged with PDO over MySQLi?[/QUOTE]

Obscurity is not security.
And PDO lets you prevent SQL injection attacks by making you use prepared statements.

[editline]14th April 2013[/editline]

A better idea would probably be to store the file with the password in a part of the server that is not directly accessible from the web (assuming it's a VPS) and then reading it from your web app.

[TTSDA]

Working on a litecoin info API.
This is the documentation site:

[URL=http://imgur.com/y4nMeIO.png][IMG]http://imgur.com/y4nMeIOl.png[/IMG][/URL]

[URL=http://i.imgur.com/9PZr3wL.png][IMG]http://i.imgur.com/9PZr3wLl.png[/IMG][/URL]

[URL=http://imgur.com/EHqVqTV.png][IMG]http://i.imgur.com/EHqVqTVl.png[/IMG][/URL]

[CBastard]

[QUOTE=Darkwater124;40275992]Can't you just call $db->real_escape_string($str); and then insert it in the query when using mysqli?[/QUOTE]

IIRC real_escape_string just replaces a number of characters used for injection whereas prepared statements enforce the structure of the query and prevents more advanced attacks that may get passed real_escape_string. Prepared statements also enforce data type to some extent.

Edit: looking into it the main vulnerability with real_escape_string is people just directly putting the output into the query without quotes. With prepared statements there is less chance of a developer error.

[Ac!dL3ak]

hello, world!

[ruby]

class SomeClass
def some_method
puts "Hello, World!"
end
end

SomeClass.new.some_method
[/ruby]

$query = $this->dbh->prepare("SELECT * FROM candy WHERE type = :type");
$query->bindValue(":type", $_GET["candy_type"], PDO::PARAM_STR);

test

[Killervalon]

wait, did garry put in new code quotes?

[IMG]http://i.imgur.com/6WDamYQ.png[/IMG]

[sp]please don't rate me late[/sp]