doubledee

July 3, 2012

Requinix,

Okay, so I tried adding this code...

}else{
	// Slug Not found in URL.
	// This will never fire!!
	// Apache catches missing slug and re-routes to "articles/index.php"

//NEW
	// Redirect to Display Outcome.
	header("Location: " . BASE_URL . "/articles/index.php");

	// End script.
	exit();

}//End of ATTEMPT TO RETRIEVE ARTICLE

...and it *appears* to do what I need.

Any comments?

And just for my own edification, can someone show me how to accomplish the same end effect using a mod_rewrite and redirecting to the default directory file which is "/articles/indoex.php" in this case?

Thanks,

Debbie

July 3, 2012

// This will never fire!!
If the code is as simple as you posted then yes that most certainly will fire: when there is no "slug" in the URL.

My file is much more complicated than that, but I posted the code that is relevant.

And I know for a fact whatever code I had in my .htaccess did a redirect for me, because that is why I added the comments above. (Originally I had error-handling code that was supposed to fire, but it never did because of some mod_rewrite, so I took that erro-handling code out and added the above comments.)

On that note, there's no need to get Apache involved: your article.php can very easily redirect, as you apparently had once before.

Yes, I could do it in PHP, but it is very common to have Apache redirect to an index.php file when no file exists or like I am describing.

I would like to restore things back to what I had...

Thanks,

Debbie

July 3, 2012

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.

I just went though ALL of my scripts and tried them both Logged-In and Logged-Out.

I am happy to say that all of my scripts ran as expected (i.e. ran successfully or displayed an error-handling message), except the one file which had issues. (Ironically, my "article.php" file was the only one with issues, yet the first one I tried?! So freaked out and created this thread prematurely! Whew!)

And it looks like the problem with 'article.php" can be fixed if I can just get some help in the MOD_REWRITE forum as I apparently accidentally deleted something my .htaccess file?!

Thanks,

Debbie

July 3, 2012

I have an "article" directory with two files: "article.php" and "index.php"

If "article.php" is called but there is no slug in the URL, I would like Apache to kick in and re-direct the user to "index.php" which is a Listing of Articles.

I had this working before, but apparently messed up my .htaccess file.

Here is a code snippet to provide some context...

// ******************************
// Attempt to Retrieve Article.	*
// ******************************
if (isset($_GET['slug']) && $_GET['slug']){
	// Slug found in URL.



}else{
	// Slug Not found in URL.
	// This will never fire!!
	// Apache catches missing slug and re-routes to "articles/index.php"

}//End of ATTEMPT TO RETRIEVE ARTICLE

?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

What code do I need to put in my .htaccess to make this happen?

Thanks,

Debbie

July 3, 2012

His answer was specific. His code showed you the quickest way to reliably destroy all data within a session, and append your message to the now empty session.

Here's a spoon-fed breakdown, though by this point you really should understand his snippet, or at least be able to figure it out on your own.
foreach - Iterate through the following array:
  array_keys($_SESSION) - Get all the keys that exist in $_SESSION, and return an array containing them
  as $key - assign the next value of the previously generated array to the variable $key
  Since there are no curly-braces for this loop structure, we know there's only a single line involved in it
    unset($_SESSION[$key]) - unsets the value of $_SESSION with the current $key
$_SESSION['resultsCode'] = 'LOGOUT_SUCCEEDED_3475' - assign the needed value to the now empty session, so it exists when the redirect occurs.
[code]

Regardless, my advice holds true. You're using sessions to pass messages between pages, which is not ideal.

You really are incapable of going more than a week without petty insults, aren't you?

I could half-way deal with that if you bothered to read anything that anyone says...

Debbie

July 2, 2012

Huh????

Debbie

That's a terrible question, and it deserves a terrible answer:

RTFM.

No, I asked a very specific question and provided quite a bit of code in my OP.

I have no clue what Requinix was referring to. (Which is strange, because he is usually spot on.)

Debbie

July 2, 2012

It's perfectly reasonable to destroy whatever is in the current session and start another one anew.
foreach (array_keys($_SESSION) as $key) unset($_SESSION[$key]);

$_SESSION['resultsCode'] = 'LOGOUT_SUCCEEDED_3475';
// and redirect

Huh????

Debbie

July 2, 2012

I have tweaked my Log Out script to display a message that the User successfully logged out (or didn't), and then allow the User to either Log-In again or Go to Home Page.

In order to do this, I just used my standard "message.php" script which is where I handle all messaging for my website (i.e. Success and Failure Messages).

In order for "message.php" to work, it is expecting a code in the $_SESSION like this...

		// Update Succeeded.
	$_SESSION['resultsCode'] = 'LOGOUT_SUCCEEDED_3475';

The problem with how my original "log_out.php" script was written, is that I was logging out (and erasing the SESSION variable) and so "message.php" would not work properly.

So I made these changes, and I would appreciate it if someone could verify if my logic is right and I am successfully and *thoroughly* logging out the User!!

log_out.php

// Verify Update.
if (mysqli_stmt_affected_rows($stmt1)==1){
	// Update Succeeded.
	// Member logged out from Database.

	// ******************************
	// Log Out User from Session.		*
	// ******************************
	$_SESSION['loggedIn'] = FALSE;


	// ************************
	// Clear Out Variables.		*
	// ************************
	unset($_SESSION['sessMemberID']);
	unset($_SESSION['sessUsername']);
	unset($_SESSION['sessFirstName']);


	// ********************************
	// Erase Session Cookie Contents.	*
	// ********************************
	setcookie("PHPSESSID", "", time() - 3600);


	// Update Succeeded.
	$_SESSION['resultsCode'] = 'LOGOUT_SUCCEEDED_3475';

}else{
	// Update Failed.
	$_SESSION['resultsCode'] = 'LOGOUT_FAILED_3476';

}//End of ATTEMPT TO LOG-OUT USER FROM DATABASE


// Set Error Source.
$_SESSION['errorPage'] = $_SERVER['SCRIPT_NAME'];

// Redirect to Display Outcome.
header("Location: " . BASE_URL . "/account/messages.php");

// End script.
exit();

messages.php

	// Log Out Succeeded.
	case 'LOGOUT_SUCCEEDED_3475':
		echo '<h1>Log Out Succeeded</h1>';
		echo '<p>You have been successfully logged-out. (3475)</p>';
		echo '<ul>
				<li>
					<a class="button2" href="' . BASE_URL . '/account/log_in.php">Log In</a>
				</li>
				<li>or</li>
				<li>
					<a class="button2" href="' . BASE_URL . '/index.php">Go to Home Page</a>
				</li>
			</ul>';

	// Finish Destroying Session.
	session_unset();
	session_destroy();
	$_SESSION = array();

	break;


	// Log Out Failed.
	case 'LOGOUT_FAILED_3476':
		echo '<h1>Log Out Failed</h1>';
		echo '<p>A problem occurred during log out.</p>';
		echo '<p>Please try again. (3476)</p>';
		echo '<a class="button" href="' . BASE_URL . '/account/log_out.php">Log Out</a>';
		break;

Is it okay how I moved this code from "log_out.php" to "messages.php" and saved it for the end???

	// Finish Destroying Session.
	session_unset();
	session_destroy();
	$_SESSION = array();

	break;

See any problems with what I did?

Any *security* issues??

Thanks,

Debbie

July 2, 2012

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.

But when combined with PHP validation, MaxLength helps you to get the cleanest data the first time...

It's quite annoying when a site rejects a password because it's two long or contains an "invalid" character.

So how wide - physically - should I make my Password field?

Maybe it doesn't even matter since the User can't see what they are typing?!

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.

Regex can be used to ensure Password-Strength...

Debbie

July 2, 2012

Content on your index page... e.g. news sites or forums. Of course you also have your members-only sites (like facebook)

Anyways I think it is kind of a moot point as Mahngiel pointed out. I too highly doubt a high percentage of users will logout just to go do more around the site. Most either navigate away to another site or login with different user credentials.

Valid point!!

I am leaning towards - consistent with the rest of the messaging on my website - displaying a message "You have successfully logged out" in the center of the page, and keep my usual Page Header and side bars in case they want to log in as someone else, or they do want to navigate somewhere else.

I think that combines what everyone has said above into a unified log-out solution.

Thanks,

Debbie

July 2, 2012

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

Well, to read an Article you need a query string in addition to the "article.php" file itself, e.g.

http://local.debbie/articles/consider-becoming-an-s-corporation

So if I just loaded "article.php" by itself I get...

Notice: Undefined variable: articleID in /Users/user1/Documents/DEV/++htdocs/06_Debbie/articles/article.php on line 278

Call Stack

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

July 2, 2012

How can you take a PARAGRAPH and hash it or whatever and stick it into a char(128) field and not lose anything and not have any collisions?!

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.

Okay, I get what you are saying, but there still needs to be some upper limit because of my Form Fields, right?

I mean I guess you can leave off "maxlength", but it seems like bad form - no pun intended - to not limit the size of Form Fields...

Maybe I could switch things back to something like this...

<label for="pass2"><b>*</b>Confirm Password:</label>

<input id="pass2" name="pass2" type="password" maxlength="40" />

Debbie

July 2, 2012

Perhaps, but what if you want additional information? Are you going to end up storing the entire user table in a session?

Nope.

I draw the line at...

- sessMemberID

- sessFirstName

- sessUsername

Besides, running a simple select query on every page load isn't really a big deal.

It just seems like a waste in order to get something like a Member's First Name or Username...

I can see running a query every time you load the entire Member's Profile.

Debbie

July 2, 2012

So if someone types in a PARAGRAPH for his/her Password, it won't break anything?!

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?

Sure!!

How can you take a PARAGRAPH and hash it or whatever and stick it into a char(128) field and not lose anything and not have any collisions?!

If my field was char(2) and I had a set of passwords that was each the contents of books in the local library, there is NO WAY you could not have collisions?!

Debbie

July 2, 2012

Here is a sample of how I have things structured in the Web Root...

index.php

/account

/account/profile.php

/account/log_in.php

/account/log_out.php

/account/my_account.php

and so on...

/articles

/articles/index.php

/articles/article.php

and so on...

/components

/components/header.inc.php

/components/footer.inc.php

and so on...

/utilities

/utilities/functions.php

Other Directores

I am using about as simple of a structure as you can. Basically just like you would use in the old days when you just had HTML files and hyperlinks?!

I don't include much, usually just either my Config file, or maybe "functions.php" or any files in the Components directory.

Debbie

July 2, 2012

I may be wrong but I think the more information that exists in your session, the more memory you use for every page load.

Generally, I only store the user ID in the session and then run a query for that ID to get their info.

But that is what I am trying to avoid...

I mean, don't you think it is much more overhead to have to query the database on EVERY PAGE instead of just storing the tiny 8-30 character Username in the $_SESSION on Log In??? :shrug:

Debbie

July 2, 2012

My Password can be between 8-15 characters, for what it is worth...

Don't set a maximum limit on the password. There is literally no reason to do that, and you're just going to annoy people. The hash will always be the same size regardless of the input.

Interesting side note...

So if someone types in a PARAGRAPH for his/her Password, it won't break anything?! :confused:

It is funny you mentioned this, because I JUST spent a lot of time changing all of my HTML Forms from 40 to 15 because I thought I had made a mistake and that I should limit the upper size since that is what is defined in my Regex.

Hmmm.....

Debbie

July 2, 2012

If you look closer, you'll see I have 3 parameters and not 4...

Oops! I thought that dot was a comma. You are right.

David, you will be getting a bill from my cardiologist?!

Debbie

July 2, 2012

I don't think there is much you can do to prevent errors in that scenario. There will obviously be uncontrollable errors if profile.php relies on constants or a database connection created in a script that include'd it.

What most CMS and frameworks do is check to make sure if the pages have been include'd or not by checking for a constant. For example in CodeIgniter, everything is routed through the index.php file (which is pretty common). The index.php file defines a BASEPATH constant, so all subsequent files in the framework check that the constant is defined, because that means it was not accessed directly but through the framework as expected.

Well, since I am not using OOP or MVC this go around, do you have advice on what to do to combat this (beyond your advice below)?

I am being too paranoid here, or is this a security risk I need to actively address?

Another thing you could do is use an .htaccess file to deny users from viewing those files.

1.) What would be the implications of that?

2.) Would it affect performance?

3.) Could it break my scripts?

4.) Would it be a maintenance nightmare?

Debbie

July 2, 2012

How much information can you actively store in your $_SESSION to where it is still "okay"??

Currently, when a Member logs in, I write this data to my $_SESSION...

// ******************

// Log In Member. *

// ******************

// Set Session variables.

$_SESSION['loggedIn'] = TRUE;

$_SESSION['sessMemberID'] = $sessMemberID;

$_SESSION['sessFirstName'] = $sessFirstName;

I feel this is very reasonable.

But what I am pondering is this...

Would it be a "mortal sin" - or a security risk - if I were to add one more thing to my Session like this...

// ******************

// Log In Member. *

// ******************

// Set Session variables.

$_SESSION['loggedIn'] = TRUE;

$_SESSION['sessMemberID'] = $sessMemberID;

$_SESSION['sessFirstName'] = $sessFirstName;

$_SESSION['sessUsername'] = $sessUsername;

On every page (i.e. in the Header file), I need the Member's "username" so that when they click on their name, they are re-directed to their Profile.

It sure would make my life easier to just keep it persisting in the $_SESSION if that isn't adding too much.

Thoughts?

Thanks,

Debbie

July 2, 2012

		$currHash = hash_hmac('sha512', $pass . $salt, VINEGAR);
That should do it. But what is that VINEGAR there? The fourth parameter is a boolean indicating whether you want raw (binary) output or not. Unless VINEGAR is a constant with a value of FALSE, you are getting raw data back, which would be 1/2 the length of the printable value.

If you look closer, you'll see I have 3 parameters and not 4...

Debbie

July 2, 2012

		$currHash = hash_hmac('sha512', $pass . $salt, VINEGAR);
That should do it. But what is that VINEGAR there? The fourth parameter is a boolean indicating whether you want raw (binary) output or not. Unless VINEGAR is a constant with a value of FALSE, you are getting raw data back, which would be 1/2 the length of the printable value.

Ah man, don't go break my code at this late stage?!

I dunno...

I was told that this code would be the most secure way to create a Hash... :shrug:

		$currHash = hash_hmac('sha512', $pass . $salt, VINEGAR);

It has been working for the last several months, and I thought it was right?!

Did someone give me wrong information??? :'(

Debbie

July 2, 2012

The size of the hash returned by hash_hmac() is controlled by the chosen algorithm, in this case SHA 512. So, you would have to look up that algorithm to get the answer (I don't know what it is).

I think what Pikachu was saying is to run strlen() against the result and it will tell you the size. For any given algorithm (md5, sha1, etc.) the result will always be the same length for that algorithm, regardless of the input string (or file).

I took his advice and got 128.

I was just wondering why I didn't see it in the Manual, but you answered that part for me.

So, I have a char(128) for my hash so I assume that is what I want/need, right?

Debbie

July 2, 2012

I am wrapping up testing all of my scripts before I go live with Release #2.

One test I was thinking of doing is loading each script - by itself - and making sure I don't get any errors.

For example, normally to display a User's Profile, you would click on a hyperlink like this...

/account/profile.php?user=$DoubleDee&tab=about-me

My "profile.php" was never designed to be loaded directly, but I am thinking it should be able to be loaded and at least not spew out any nasty error messages.

If you were a hacker, wouldn't that be a good approach to take to learn more about a system...

Navigate the website normally, take an inventory of every script's name, and then try and load those files directly and see what errors occur.

Any thoughts on this idea of mine?? :confused:

Thanks,

Debbie

July 2, 2012

strlen

Why is this not documented in hash_hmac() ??

Debbie

Sign In

doubledee

Posts

Joined

Last visited

Content Type

Profiles

Forums

Posts posted by doubledee

Redirect to directory index.php

Redirect to directory index.php

Loading Files by Self

Redirect to directory index.php

Log Out script

Log Out script

Log Out script

Log Out script

Size of Hash?

Log-Out Behavior

Loading Files by Self

Size of Hash?

What to store in $_SESSION ??

Size of Hash?

Loading Files by Self

What to store in $_SESSION ??

Size of Hash?

Size of Hash?

Loading Files by Self

What to store in $_SESSION ??

Size of Hash?

Size of Hash?

Size of Hash?

Loading Files by Self

Size of Hash?

Browse

Activity

Important Information