Quick mod_rewrite question

GJSNeptune

[H]F Junkie
Joined
Mar 31, 2004
Messages
12,372
I'm still a bit fresh with mod_rewrite. I have what I need so far working, but I'd like to be covered in case the URL contains terms that don't exist, in which case the URL should be redirected.


Example:
http://www.domain.com/admin/task

Rewrite:
RewriteRule ^/?(admin)/?(stats|submit|messages|breakinternet)$ /domain/admin.php?do=$2 [L]


If someone were to enter /admin/eaticecream, how can I rewrite the URL to go back to /admin?
 
i would suggest having a simpler rewrite rule that accepts anything after /admin/ and let the php script handle validating whether it's a legitimate option. that way you don't have to keep modifying the htaccess file if you add more admin options. with the php script you could also set the location header to redirect back to admin.

but if you really want to do it with htaccess i believe if you add another rule after the first that will accept anything after admin that just redirects to admin (ignoring the captured group) it should work since any of the real options will have been processed by the first rule and the next rule will not be processed since you're using the L flag

i.e.
RewriteRule ^/?(admin)/?(stats|submit|messages|breakinternet)$ /domain/admin.php?do=$2 [L]
RewriteRule ^/?(admin)/?(.+)$ /admin [R,L]

at least i think that's how it should work
 
+1 for using PHP for this. It's just so neat and efficient to have an index page that includes pages based on what your "do=" is set to. With a quick switch you can handle it and set the "default" to whatever page you want to load when it's set to a section you don't have.
 
I usually design my index page as kind of a reverse "include header/footer". Instead of taking the content that's semi-static and throwing it into a header and footer file, I instead take the dynamic content and insert it into the index page.

Here's a simple example of a typical index file I would setup for a site that has multiple sections.

Code:
<?php
	switch ($_GET["m"]) {
		case "page1": {
			$pageTitle = "...";
			$metaDescription = "...";
			$metaKeywords = "...";
			$pageHeading = "Page 1";
			$pageFile = "page1.php";
		}
		case "page2": {
			$pageTitle = "...";
			$metaDescription = "...";
			$metaKeywords = "...";
			$pageHeading = "Page 2";
			$pageFile = "page2.php";
		}
		default: {
			$pageTitle = "...";
			$metaDescription = "...";
			$metaKeywords = "...";
			$pageHeading = "Hello";
			$pageFile = "home.php";
		}
	}
?>

<!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" xml:lang="en" lang="en">
	<head>
		<title><?php echo $pageTitle; ?></title>
		<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
		<meta name="description" content="<?php echo $metaDescription; ?>" />
		<meta name="keywords" content="<?php echo $metaKeywords; ?>" />	
	</head>

	<body>
		<div id="page-container">
			<div id="page">
				<?php
					echo "<h1>",$pageHeading,"</h1>";
					require_once $pageFile;
				?>
			</div>
		</div>
	</body>
</html>

With some modications it can be enhanced to generate the meta information dynamically, or can be slightly more complex to take whatever the m (module) is and set a specific title/etc. based on the results of a database query (like for a specific blog post that gets loaded for m=blog).
 
I'm certainly no expert at CSS or PHP, but I'm OCD about code being clean, efficient, and containing only what's needed. Please tell me if there's anything wrong with my currently-employed philosophies, and how they could be done better.


With the idea of relying more on PHP than mod_rewrite to filter URLs, I'm thinking of having index.php be the only HTML page, pulling functions from other pages based on the nature of the tasks needed. One advantage I see is that if I change the basic structure of index.php, I don't have to change it on the other HTML pages. I already do this to some degree, only I have a couple other HTML pages.

Currently my index.php is made up of chunks that I take from page.php, which contains just about every module I've coded so far, like header, footer, even fetching blog entries, a specific entry, etc. It's getting pretty big. I'm now thinking of breaking up the modules/functions into pages more specific to their nature. So page.php has only page layout (and maybe meta) modules, admin.php contains modules for admin tasks, blog.php has modules for blog stuff, etc. Is this a good practice? I really hate cluttered root directories.


I'm using sessions quite a bit right now. My login system is cookieless, although I'm the only user. When I log in, I have the session ID change. That's about all I've done so far for session security. What else can I do? I've also looked into salting passwords, but I'm confused about validating them, especially if the salts are random. Even though I'm the only user (right now), I'm treating it as if I'll open up registration when I'm more comfortable with my abilities.
 
You should try to separate your modules/groups-of-logic-that-do-a-specific-task into their own base. This ensures maximum flexibility and maintainability.

If you want re-usable code that's ultra efficient and organized you shouldn't even have stuff like a "blog" module, at this point you're too high up. A typical blog page/section can be broken down into at least 8 or 10 separate groups of code that end up resulting in blog functionality when put together.

Setting up a salt is nothing too fancy.

Your user table only needs a single password field.
On user create, generate a random string and append it directly to the plain text password sent from the form.
Then md5 the result of the 2 combined values and store that in your password field.
Hello and welcome to having a salted password, it's that easy.

You will need to add in some type of "Forgot your password?" functionality though because reversing the password will be effectively impossible.

If you work with cookies just make sure you don't store the password in plain text in the cookie file.
 
No, I get how to salt the password. What I'm confused by is how to validate it, at least when the salt is randomized for each registration. How would you check it against the login form input?
 
Depends on how you setup your db. You could opt to include a 'salt' field and then store the random salt value there.

To validate against it just build the final hash from what you have in the database. In this case, the plain text password + the salt. md5() the combined value of that to the password field in the database.
 
I think I get what you mean about organization. Instead of calling functions from separate files, call separate pages based on the request inside the content area of index.php.
 
Not so much that, I meant you should be always looking for ways to break down your applications into groups of logic that can be re-used effectively. The whole idea of this is to stop copy/pasting code and slightly modifying it and to start using functions you wrote to do the same thing without the copy/paste spam.

Fetching blog entries or a blog post is nothing really. You're just running a query to return a certain data record or records. Why would you need to dedicate a function for this?

You should have a generic db wrapper that allows you to quickly get a record or list of records that you want and return it in a non-layout dependent format.

Suddenly you're able to pull data for a blog or anything that's stored in a db without having to copy/paste/slightly modify existing code. Your code becomes a million times easier to manage and you can expand onto it without having to worry about breaking something.
 
Quick PHP question if anyone can answer it. My comment form is processed by PHP_SELF. If the form inputs are determined to be valid, and the comment is successfully posted, the user is redirected to their new post where it's displayed.

However, if there are any errors with the form, I can't figure out how to redirect the user to the form and still show the errors. On the page with the comment form, I first check to see if the form has been submitted. If it has, then data is validated. Then the form is displayed. Then comes the code for inserting the data.

The one way I can think of that would likely work is to use a separate PHP file to process the form, and then to redirect as needed. I'd like to keep it PHP_SELF if possible. Ideas?
 
Back
Top