Session retaining info?

[kilbey1]

I need help determining what is causing a SQL statement to remain the same, no matter what criteria. After a user logs in, and a search is put into a form, it returns something like the following:

SELECT SQL_CALC_FOUND_ROWS * FROM resume INNER JOIN candidate WHERE resume.Section_ID = '1' AND MATCH (resume.Section_Value) AGAINST ('html' IN BOOLEAN MODE) AND candidate.Candidate_ID = resume.Candidate_ID AND candidate.Location IN ('AL', 'Alabama') LIMIT 0 , 10 

But when I go back to the search form, and new criteria is entered, the EXACT same sql statement appears in the resulting page.

What might be causing this? Sessions? Am I logging out after each form submission?

Thanks,
Eve

[MrPixel]

Well ... to start with, what parts of the query are supposed to change? I see no variables.

[kilbey1]

Well, any criteria can change really, but an example ('html' IN BOOLEAN MODE) AND candidate.Candidate_ID = resume.Candidate_ID AND candidate.Location IN ('AL', 'Alabama') - as in say looking for an HTML person in Alabama, or an SAP expert in California.

I've attached consultants.php, the file I'm working on. Note session_start(); and the session_destroy(); at the bottom (now commented out). I think that is what's causing the SQL statement to retain it's previous state, no matter what I put into the search form.

Is there another place I should destroy my session?

[MrPixel]

From a quick look, you are saving all your search variable in a session.

You shouldn't do

$_SESSION['my_var'] = $_POST;

It taints the session, which is otherwise much more trustworthy then the user submitted POST variables, thus nullifying one of the advantages of sessions. First, and most basic, rule of security: Make sure all user submitted data is what you think it is!

I think this is also the source of your problem. You don't need to store everything in the session. That is, some values should be persisted "forever" because they don't change between every single page request. A language setting is a good example. And some values, such as search variables, only need to be kept for the next page load. Storing all your search variables in the session will quickly make your search form frustrating: a user will enter a value in Field #1 the first time, and Field #2 the second time ... but they'll be searching on Field #2 AND Field #1, because it's still in the session. If they fill in ALL the fields the first time, they could fill in NO fields the second time, and still get the same results. I might suggest just storing the search terms in a local array, or maybe $GLOBALS, then using those for the search, and insert the values into the form on return. Since the important fields can't be hidden, they'll probably notice, and change some of them if the results aren't what they were looking for.

On a totally unrelated note, you can get the number of affected rows without sending a new query to the database: mysql_num_rows() tells you how many rows are in a result set, and mysql_affected_rows(), the number of rows affected by UPDATE, DELETE etc ....

[kilbey1]

This seemed to work:

		if(!isset($_SESSION['somename']) && isset($_POST))
		{
			// First time there is a $_POST array
			// We copy it to the session var for our form values to persist
			$_SESSION['somename'] = $_POST;
			session_destroy();
		} 

Where the session is immediately destroyed after the search form is submitted. This seems to work...

Otherwise, can you give me a snippet of code that may better serve my purpose? I'm trying to find a way of getting this to run without redoing this again, since I'm now on a deadline.

[MrPixel]

I've got plenty of my own work to do ... but just a few thoughts:

1. If you destroy the session almost immediately after starting it, what's the point of starting it?
2. Your form is begging for a SQL injection. Is meeting your deadline important enough to risk the loss or corruption of your database?
3. Using $GLOBALS (easiest), a globalized variable (harder, but still easy), or a data object (not so easy) will make your variables available everywhere, and avoid the problems involved in using $_SESSION for this purpose.

[kilbey1]

Ok, then I'd better break this down, because I only know enough coding to be truly dangerous (as you noticed via your comment of SQL Injections).

1. $GLOBALS. I have not used this, and have heard through the grapevine that keeping globals wide open is dangerous? If that's not the case, then all I have to do is slap a $GLOBALS near the top of my page and I'm good to go? I then get rid of all my session junk? I am reading the info on predefined variables, but it's not really pointing out what to do with $GLOBALS once it's in there.

2. SQL Injection. I have only used a revised Dreamweaver script for a secure login, one which enhanced it so the SQL injections would not occur. I"ll try to find the article again and apply it, otherwise, perhaps you know of a code repository that gives me a function I can apply to prevent such an attack.

[MrPixel]

Here's how you might go about it:

1. Make a list of all the information you plan on collecting from the user.
2. For each item, decide the strictest possible definition of allowable items. ie., the variable ID can only be an unsigned integer less than 1000, or "state" must be only two letters, and contained in an array of state codes you previously defined.
3. If you have free form data (ie., messages or comments), make sure you get familiar with strip_tags(), htmlspecialchars(), htmlentities(), addslashes(), and stripslashes().
4. Write a validation script that makes user submitted data available to your program (in $GLOBALS, or a data object, for example) ONLY AFTER it has met the requirements you defined in #2. Delete any $POST, $GET, or $_COOKIE variables that don't.

Then, use your data as you see fit.

[kilbey1]

Ok, my states are protected in that they can only be chosen via a dropdown menu...I have no freeform data.

Won't this protect me somewhat?

function backslash(&$arr, $escape)
{
   $magic_on = get_magic_quotes_gpc();

   if($escape && !$magic_on):
       foreach($arr as $k => $v):
           switch(gettype($v)):
               case 'string' :
                   $arr[$k] = addslashes($v);
                   break;
               case 'array' :
                   backslash($arr[$k], true);
           endswitch;
       endforeach;
   endif;

   if(!$escape && $magic_on):
       foreach($arr as $k => $v):
           switch(gettype($v)):
               case 'string' :
                   $arr[$k] = stripslashes($v);
                   break;
               case 'array' :
                   backslash($arr[$k], false);
           endswitch;
       endforeach;
   endif;       

}
backslash($_POST, true);

I could do the same for all $_GETs.

[kilbey1]

Btw, what I've done is removed all session info, changed to $_POST. The data that appears is correct, but my page numbering does not. When I click on page 2, no query exists from the previous page.

I believe this is why I originally was told to use sessions.

[MrPixel]

Originally posted by kilbey1
Ok, my states are protected in that they can only be chosen via a dropdown menu...I have no freeform data.

This offers protection analogous to a paper condom; it will only protect you from users who are a) honest (ie., chaste), or b) don't know how to manipulate POST, GET, or COOKIE data (ie., too young to know what goes where.)

For example, I use Firefox. One of my favorite extensions is called RequestPoison.What it does is allow me, the web developer, to submit arbitrary content to any form element on a page of my choice. Additionally, I can add elements to the form that aren't even on that page. The whole point is to provide a means for web developers to be able to test the security of their web apps. And for this, I love it. But it also has the effect of facilitating malicious users. And this is just one of many.

The point: always, always, ALWAYS check that the user submitted data is EXACTLY what you think it is. Or put differently, NEVER EVER trust data that you didn't explicitly create in the first place.

As for backslash() ... it's alright. It will not protect you from XSS (Cross-Site Scripting) attacks, however, as it allows HTML through without a peep. Use explicit length limits, and htmlspecialchars() and/or htmlentities(), to get around this.

You may want to look at the OWASP web site, which has a lot of great info on web application security.

As for the paging issue ... sessions are not a bad choice for pages ... but

$_SESSION = $_POST;

is a far cray from

if (preg_match('/^[0-9]{1,4}$/', $_POST['page']))
    $_SESSION['page'] = $_POST['page']; 

[kilbey1]

Ok, so the trick is to build in user validation before submitting anything? I will build it in for every field, in that case.

And if this is a problematic point, see if this is safe to use now. (Can you break out the preg_match to tell me what it's supposed to be doing?)

		if(!isset($_SESSION['somename']) && isset($_POST))
		{
			if (preg_match('/^[0-9]{1,4}$/', $_POST['somename'])) {
    			$_SESSION['somename'] = $_POST;
			}
		} 

EDIT: Crud! Page numbering working, but once ABAP is put in, always remains ABAP, never checks for HTML if skill is changed to HTML. 🙁

Btw, I'd be glad to post an URL to view it in action.

[MrPixel]

Originally posted by kilbey1
Ok, so the trick is to build in user validation before submitting anything? I will build it in for every field, in that case.

Sort of ... I'd put it differently: validate all data before USING it. You can't control what they type, but you can easily discard bad data. Also, do not count on the fact that people have to login to use a script - most users pick passwords like password or the name of a close relation or pet, so just because they authenticated doesn't mean they are who you think they are. Using SSL, and forcing good passwords (like 1sdBh9j1U$ ) really helps in this regard, though most people don't like being given secure passwords because they're usually so hard to remember.

And if this is a problematic point, see if this is safe to use now. (Can you break out the preg_match to tell me what it's supposed to be doing?)

Sure.
Slashes indicate the beginning and end of the pattern. They're required.
A caret ^ matches the beginning of the string. It's like saying, "Whatever is after me MUST be the first character". In the same way a dollar sign $ matches the end of the string.
Anything in brackets [ and ] is called a character class. In this case, I have 0-9 ... the range of digits from zero to nine.
The numbers in braces { and } indicate the number of times to match what preceded it; in this case, at least once, but not more than 4 times.
Summing up, the pattern /^[0-9]{1,4}$/ matches ONLY numbers 0 to 9999.I imagine you'll need to figure out a more appropriate pattern to validate $_POST['somename'].

You can learn all about Regular expression patterns at php.net. Just to warn you though, regular expressions can be very complex; it takes a lot of coffee and some trial and error to really wrap your head around regular expressions. Once you have, though, you'll have an extremly powerful tool at your disposal. This program may be useful as you try to write and debug regular expressions.

[kilbey1]

See if I'm on the right track. This is the root code.

//if the session isn't set but we are POSTing the form...		
if(!isset($_SESSION['somename']) && isset($_POST))
		{
//copy the post to the session
$_SESSION['somename'] = $_POST;
		}

Now, I should only allow the post to be copied if certain criteria are met. In this case, I have to build in a reg expr for, say, the 'skills' field where data is all letters of any length that may or may include a + or - sign for boolean. Then check the city field which again is all letters, no + or - allowed in this case. Person's last name and first name checked similarly.

So to check the person's last name, I might set up something like:
/^[A-Z]$/
?

And so on and so forth via IF statements within the base code above, allowing it to be copied only if the reg expresssions are true?

[kilbey1]

And perhaps ctype_alpha (etc.) will work? IE...

		if(!isset($_SESSION['somename']) && isset($_POST))
		{
						if(ctype_alpha($_POST['lastname'])) {
				echo "OK";
			} else {
				echo "NOT OK";
			}
		}

Ugh. I really need to get this finished. New problems I didn't foresee and my boss wants this like yesterday. 🙁 I'm hoping this will be a shortcut. Here's the ctype info .

[MrPixel]

You're on the right track with the validation. But it might be easier if, instead of just copying the whole $POST if everything is ok, you can just let through variables on a one by one basis:

if (in_array($_POST['state'], $valid_states))
    $_SESSION['state'] = $_POST['state'];

As for the ctype functions, they are very useful and quite fast ... however, people with names like O'Reilly or Berners-Lee won't make it through a ctype_alpha() test.

[kilbey1]

So we're talking...(excuse me for sounding dense)

$valid_states = array("AL" => "Alabama", "CA" => "California", etc.)
if_(in_array($_POST['state'],_$valid_states)) {
____$_SESSION['state']_=_$_POST['state'];
}
$valid_lastnames = preg_match_all('some_reg_expr_here', $_POST['lastname']);
if_(is_string($_POST['lastname'],_$valid_lastnames)) {
____$_SESSION['lastname']_=_$_POST['lastname'];
}

Second doesn't seem right. Lastname, Firstname would be done similarily once gotten.

My criteria to find are...

1. skills (boolean search, allowing alpha, +, -, or "", non-case sensitive)
2. firstname (alpha non-case sensitive)
3. lastname (alpha, ' or - non-case sensitive)
4. city (alpha non-case sensitive)
5. state (either 2 letter or full state name)

[MrPixel]

Originally posted by kilbey1
So we're talking...(excuse me for sounding dense)

[/quote]
You don't ...

And it looks like you're on the right track (except maybe those extra underscores in there :D ) ...

[kilbey1]

Does this look doable? Bear in mind, I know nothing about reg expressions. 🙂

Is there a way I can get away from putting all 50 states in, and instead pull from a database?

		if(!isset($_SESSION['somename']) && isset($_POST))
		{			
			$valid_skills = preg_match_all('/:alpha:,+,-,"/', $_POST['skills']);
 			if_(is_string($_POST['skills'], $valid_skills)) {
				$_SESSION['skills'] = $_POST['skills'];
			}
			$valid_states = array("AL" => "Alabama", "CA" => "California")
			if_(in_array($_POST['state'], $valid_states)) {
				$_SESSION['state'] = $_POST['state'];	
			}
			$valid_lastnames = preg_match_all('/:alpha:/', $_POST['lastname']);
 			if_(is_string($_POST['lastname'], $valid_lastnames)) {
				$_SESSION['lastname'] = $_POST['lastname'];
			}
			$valid_firstnames = preg_match_all('/:alpha:/', $_POST['firstname']);
			if_(is_string($_POST['firstname'], $valid_firstnames)) {
				$_SESSION['firstname'] = $_POST['firstname'];
			}			
			$valid_lastnames = preg_match_all('/:alpha:/', $_POST['lastname']);
 			if_(is_string($_POST['lastname'], $valid_lastnames)) {
				$_SESSION['lastname'] = $_POST['lastname'];
			}
			$valid_city = preg_match_all('/:alpha:/', $_POST['city']);
 			if_(is_string($_POST['city'], $valid_city)) {
				$_SESSION['city'] = $_POST['city'];
			}

	}

[MrPixel]

Originally posted by kilbey1
Does this look doable? Bear in mind, I know nothing about reg expressions. 🙂

Is there a way I can get away from putting all 50 states in, and instead pull from a database?

Sure why not? Just make sure you don't use outside information (ie., ids, table names) to get it.

I think this should suffice:

if(!isset($_SESSION['somename']) && isset($_POST))	{			
	if (preg_match('/[a-z\+\-"]*/', $_POST['skills']))
		$_SESSION['skills'] = $_POST['skills'];
	$valid_states = array("AL" => "Alabama", "CA" => "California")
	if (in_array($_POST['state'], $valid_states))
		$_SESSION['state'] = $_POST['state'];	
	if (preg_match('/[a-z '\-];/', $_POST['lastname'])) {
		$_SESSION['lastname'] = $_POST['lastname'];
	if (preg_match('[a-z '\-]+/', $_POST['firstname'])) {
		$_SESSION['firstname'] = $_POST['firstname'];
	if (preg_match('/[a-z\-]+/', $_POST['city']);
		$_SESSION['city'] = $_POST['city'];
}