gizmola

Haha. Reminds me of:

I didn't look at the code closely enough to even notice session_register(). But as it's deprecated, I think we can advise that any of those calls should be rewritten: session_register("myUserName"); Change this to: $_SESSION['myUserName'] = $myUserName; Do this for all occurrences of session_register(), rename the php.ini to php.ini.local and see if things now work correctly.

I don't see code that would be fixed by having register globals on.

What you probably want to look into is RewriteCond. These are conditions that when met, can be used to drive a rewrite rule. There are a variety of different variables pulled from the server environment that you can use. For example, if these directories exist, then this should handle it: RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^(.*)$ /index.php/$1

Oh man. register_globals --- really insecure and long deprecated feature. You really need to update your scripts so that they use $_GET and $_POST so you can turn that off.

You have 2 options: a key'd array where you pick one or the other to be the key, or just an array of arrays. Since I don't see you accessing this array by keys, I'm just going to show you the array of arrays. Something like this should work: $menu = array(array('title' => 'Home', 'link' => 'index'), array('title' => 'About Us', 'link' => 'about'), array('title' => 'Members', 'link' => 'members')); // make your links $menuhtml = ''; foreach ($menu as $menuitem) { $menuhtml .= '' . $menuitem['title'] . ' ||'; } echo rtrim($menuhtml, '|');

A notice is not an error -- it is a "notice". It's very clear what the notice is telling you. You are attempting to make a boolean evaluation using $error['ads_title'] however, this array element doesn't exist. In a situation like this you can use isset() first to shortcircuit evaluation. if (isset($error['ads_title']) && $error['ads_title'] != '')

So it's not in the root? It's in /somefolder/about.php?

You need to break things into individual pieces. First - you need a script that takes a parameter (the member_id) from a url and queries for that individual member, then displays the information in an html page. You will get the param inside the script from the $_GET[] superglobal array. Let's assume that script is named showmember.php -- Then a call to get member with member_id 5 would be: showmember.php?id=5 Inside your showmember.php script at the top: $id = (int)$_GET['id']; if ($id > 0) { $query = 'SELECT * from members WHERE member_id = $id"; // do your mysql query, fetch, display data if found else show not found message } Now all you need to do on your list form is to have an anchor tag that creates the link to showmember.php?id= with the appropriate member_id you get in your result for the row, in the same way you are displaying other information. You might want to make the anchor around the firstname and lastname columns or you could just have a link in a column that says: "See Profile". For your search form, start with an html form that provides all the options you would want available in the form. You would add to your script a similar section at the top that gets the contents of the submitted form from the $_POST superglobal. Based on the existence and contents of elements in your form, you will want to create the query criteria, by adding elements to the WHERE clause. For example if your form has a state drop down, then you would include the state portion. Hopefully this gets you moving in the right direction.

Is about.php in the root of your site? What is the document root and where are these mod rewrite rules?

You can obfuscate it, but obfuscation is not security. I discuss this in this thread and provide one possible solution: http://www.phpfreaks.com/forums/index.php?topic=337566.0

Well, it's relevant because innodb has row level locking whereas myisam does not. I'm not sure I understand your design. You can not have one process that locks a row, and then have another process that comes along and unlocks it.

It doesn't matter whether you hash the salt or not. What's important is that when you hash the password, you add the salt to the plaintext: $savedpw = md5($pw . $salt);

How is that helpful?

The number 1 rule of regex, when you don't need a regex don't use a regex. RewriteRule ^about$ /about.php [L]

Yes use javascript. This is called creating a "modal" dialogue. http://www.designlabelblog.com/2009/03/20-ways-to-create-javascript-modal.html

Yes it's very simple, you issue SELECT... FOR UPDATE. You have to wrap this with a transaction. When you commit the lock(s) will be released. However, the "other" point should really do whatever work is required inside the transaction, or the locking would be fairly pointless.

Ask a few people you will get a few different answers. This topic has been beaten to death in numerous other threads. -Use a hash. A hash is not encryption. It can not be decrypted. That is the strength in using it. The most commonly used hashes are md5() and sha1(). Since you brought up a salt, a hash is where a salt comes into play. -Yes use a salt. And use a different salt for each row (saved in a seperate column for that purpose). The point of a salt is that *if* your database were to be entirely compromised and someone was to have access to the complete database, using a salt for every different row makes the creation of a custom rainbow table pointless. That is not to say that if there is one single account that they are interested in, they couldn't generate a custom rainbow table using that salt, but what ends up being impractical is generating a rainbow table in the hopes of getting hits on a number of different accounts. It really doesn't matter what a salt is in this case -- but you want it to be random gibberish. One important thing to do is to enforce good passwords. Require them to be a certain length, include numbers and/or special characters, and in general don't let people use simple words or their email address, login names etc. This has nothing to do with encryption but is another hedge against disclosure after compromise, which assumes the worst. One other thing to do, is make sure that your system detects bad passwords. After a certain number of bad passwords are attempted within a short period of time, you should add additional barriers (different approaches include requiring a captcha, slowing the attempt by a factor of seconds per bad attempt, or locking the account for a period of time after some reasonable threshold of consecutive bad attempts has been made. This dissuades bot driven brute force hacking.

I think what the poster is really asking for is, a way to obfuscate the id. No, you can't use md5 for that, because md5 is a one-way hash.

It's because your first regex allows letters. So it accepts the 'v'.

You are not detecting when the ctrl key is being pressed, so even though ctrl-v is a special combination, the keycode for v fails your numeric only regex, which defeats the paste functionality when using a key combination. Unfortunately, if you allow this, you will bypass your key by key checking. Even now you can see this is in action, by copying something that would not be legal into your paste buffer (try foo!!!!) and paste it into your text fields and you'll see that it bypasses your regex restriction.

This isn't how we do things here. Read the php manual, read some tutorials, google, buy a book on Amazon. When you have some code, we can help you. What you're talking about doing is as basic as can be, but it's driven by an understanding of your own database structure, and SQL. Do you even have a simple SQL query you've tested out in phpMyAdmin?

Adding a second unlink is exactly what you need. What error are you getting? Not that this is related, but this line of code is completely wrong: header("Location: [url=http://jhrevell.com/manage]http://jhrevell.com/manage[/url]"); Should be something like: header("Location:/manage");

http://akrabat.com/zend-framework-tutorial/

take a look at mcrypt