NotionCommotion

Well, I'm kinda nice. For hashing, I used to use http://www.openwall.com/phpass/, however, now think http://php.net/manual/en/function.password-hash.php is preferred. In regards to Jacques comments about injection, addressing is VERY important. Your current approach can allow someone to easily delete your entire database, or worse. For an easy fix, look into PDO and prepared statements.

Ha ha, I saw the original post, and new you couldn't resist!

I start off by always checking my $_GET/$_POST/etc array, and making sure the data I expect is there. Next, check the query, and make sure it works directly with your database. I either echo to the browser, or use syslog().

Tom, There are about a million and maybe more ways to do this. What do you want regarding the user experience? A link next to each user? A select menu to select the user? An autocomplete to select the user? A checkbox next to each user? Or something else? Once you decide on this, there are many ways to implement, however, fortunately less than a million.

Don't know if I know what is best, but I could tell you how I do it. Single quotes when not much to insert or if the inserting stuff is constants or static properties. Double quotes and always put curly brackets around it even when not necessary. For the official answer, see http://php.net/manual/en/language.types.string.php.

PS. This was not directed to Jacques1, but to the endless journey to provide secure systems.

Ugg, when does it end? Assuming Michael is a good guy and he selects "admin" as his admin domain, and the "safe" subdomain is "sites" which the user cannot effect, his sites could be: michael.public.mysite.com michael.admin.mysite.com public.michael.mysite.com admin.michael.mysite.com michael.public.sites.mysite.com michael.admin.sites.mysite.com public.michael.sites.mysite.com admin.michael.sites.mysite.com But, if a bad guy comes along, they could be: payment.public.mysite.com payment.secure.mysite.com public.payment.mysite.com secure.payment.mysite.com payment.public.sites.mysite.com payment.secure.sites.mysite.com public.payment.sites.mysite.com secure.payment.sites.mysite.com Yes, I see a little benefit by putting the "sites" subdomain in. Which is best assuming we are including the "sites" subdomain? If we go without the "sites" subdomain, is the answer basically the same? Would I be best using mysite.com for signup and payment, and mysite.net for all the user's sites?

Your welcome! It is easy to make a silly mistake with relative paths. require() or require_once() (which you want for your situation) at least make the mistake obvious.

Check whether they are logged on (i.e. is a session set, etc). If not, header("Location: goAway.php"); exit; http://php.net/manual/en/function.header.php

I always store my queries as a string like Barand recommends. I also typically use PDO's prepared statements, and use the following class to view the queries when troubleshooting public static function showQuery($sql, $data) { $keys = array(); $values = array(); # build a regular expression for each parameter foreach ($data as $key=>$value) { if (is_string($key)) {$keys[] = '/:'.$key.'/';} else {$keys[] = '/[?]/';} //if(is_numeric($value)) {$values[] = intval($value);} if(is_numeric($value)) {$values[] = $value;} else{$values[] = '"'.$value .'"';} } $sql = preg_replace($keys, $values, $sql, 1, $count); return $sql; }

What are the values of $memberid and $q? If they are undefined or not what you expected, there is your problem. If they look applicable, then substitute them in your query and direct input the query into your DB, and see if you get any results. If none, systematically remove some of the WHERE clauses until you find out which one is limiting.

I like option 1

Thank you for your reply maxxd, My original plan for a singleton object was to invoke it in the parent script and not pass it to any classes that need it since it was global in nature, and I could access a property in it as mySuperSingleton::mySuperSinglton()->someProperty. Effectively, I would be doing the same thing as using a global variable which I now understand is not desirable. My contention regarding constants is that they could be abused just the same as globals, and I am sure I have been guilty of doing so. For instance, what if in the entry point of my script, I queried the DB and defined 500 constants based on the returned records? Now those constants are global throughout all my script. In practice, I didn't declare 500 constants, but I have done a few. Another area I've used constants is for defining file paths to my root directory, my class directory, etc, etc. This seems more acceptable, but I don't completely understand the future repercussions. Other uses I have done are for defining constants such as my Google maps key or my recaptcha keys. Again, seems more acceptable, but again would like advice from others. So, my question is what are acceptable uses for constants, and when are their use detrimental for reasons similar to using global variables?

<?php ini_set('display_errors', 1); error_reporting(E_ALL); echo('sanity check1'); require_once('/path/to/chart.php'); chart($_POST['userinput']); echo('sanity check2'); ?>

I am starting to come around and agree that my approach was not correct, and I should pass the object as an argument. That being said, defining a bunch of constants is no better than using a global variable (or some surrogate for a global such as a singleton class), right? Maybe even worse since it is harder to identify all the user defined constants? I suppose I could use get_defined_constants(true)['user'], however. When is it appropriate to use constants throughout an application?

Just to confirm, http://yourdomain.com/phil/x.php is the small PHP script you are showing, right? Maybe read/write privileges? What does the following give you? <?php echo ('Current script owner: ' . get_current_user().'</br>'); echo(exec("Rscript /var/www/html/phil/figs/map.R").'</br>'); shell_echo(exec("Rscript /var/www/html/phil/figs/map.R").'</br>'); ?>

Assuming "ref" in your database corresponds to the checkbox, this line... echo '<td><input type="checkbox" name="check_list[]" value="'. $row[1]. $row[2]. $row[3].$row[4].$row[5].$row[6].$row[7].$row[8].$row[9].'"></td>'; should be... echo '<td><input type="checkbox" name="check_list[]" value="'. $row[0].'"></td>'; That being said, why have the mini-loop to display columns? Typically, you just want the row loop and echo each column independently (at least that is how I do it I also usually use associated or object outputs from the DB so need to use the name).

body { background-color: black; }

Well, yes laziness, but it does make the code more concise. As of yesterday, I have never heard the term "dependency injection, and just learned about the god object now (http://en.wikipedia.org/wiki/God_object). Is tightly coupling always a bad thing? Note that my god object would be only properties, and maybe a method or two to add properties. If I didn't wish to use a third party framework, do you have general recommendations on how to implement a "configurable dependency injection container"?

Forget about the part about DB connections, and back to the original question. I have a homegrown MVC architecture, and I have an object with a bunch of properties which are used by the controllers and models. I would rather not pass each given property on a need to use basis, but just pass the whole object. Instead of using a global variable or a singleton object, should I be doing something like... <?php $bigObject=new bigObject(); $bigObject->bla="blabla"; $controller=new someController($bigObject); $controller->someTask(); class controller { protected $bigObject; public function __construct($bigObject) { $this->bigObject=$bigObject; } } class someController extends controller { public function someTask() { $model=new someModel($this->bigObject); $data=$model->getSomeData(); //Deal with view } } class model { protected $bigObject; public function __construct($bigObject) { $this->bigObject=$bigObject; } } class someModel extends model { public function getSomeData() { return array(1,2,3); } } ?>

You "could" parse your CSS file through PHP. That being said, you shouldn't as it ultimately leads to a troubleshooting nightmare. One option is just to store a CSS class name in your DB, and have PHP write that class when you are rendering your HTML. You of course would need CSS to assign the proper color to the given class. If you really want any possible color, I would just include a bit of CSS in your HTML file. <style type='text/css'> .background { background-color:<?php echo($backgroundcolor);?>; } </style>

I realize you are just testing, but this is a big no-no. Read up on SQL injection if you don't know. Easiest solution is to use PDO's prepared statements as Ch0cu3r describes.

Hello Chris, Maybe you know all this, and if so, tell me so and I will shut up. The only reason I harp on it is I feel it is the number one important thing beginners need to understand. Not understanding leads to frustration as I have personally experienced. If you already know, disregard, otherwise... There are two things that talk to each other: the client (AKA the IE/FF/Chrome/etc browser) and the server (AKA your PHP server). The client communicates to the server via three ways: GET request. Basically includes the information in name/pairs in the URL, and is typically used when the client just wants to get more stuff. POST request. Definitely not in the URL, but I think a header or something. Typically used when the client wants to change the state of the server (i.e. write to the database). COOKIE request. Used to tell the server information about who the client is. SESSIONS are also used for this, but are just a glorified COOKIE where the real information is derived from the key given in the cookie. The server just pumps stuff to the client. In your case, it will probably be just HTML, however, it could also be JSON, XML, etc. If you don't get this working right, nothing else will work right. Don't worry about you SQL, etc, unless you know this is working. The whole purpose of var_dump($_POST) or print_r($_POST) is just to know that the client is communicating to the server. Have I made myself clear? Get this part working before doing anything else! If your server is attempting to access POST (or GET or COOKIE) data which doesn't exist, go back to square one, and find why it isn't being sent. Hope this helps!

Don't think you need binary trees, just simple math. What are you summing over? Probably could just do in in SQL, however, I suppose if you want, you could iterate over an array.

Never mind. Looks like I was trying to access $_SESSION[2996699736].