ManiacDan

Yes, of course it's simple and not flexible, because you said that you googled for solutions and couldn't understand them because they were too complex. Suddenly you would understand me if I explained it properly in high complexity? Why should I spend half an hour writing an article for you, personally, when you've already said you read articles and they were no good? You could also make a separate table for the user levels, that's true, but involving multiple tables was too complex for you I thought, given: Your groups could be leveled as well. You could have a group for "global admin" as well as an admin for each section. What the groups are and how they apply are up to you.

I second everything mjdamato said.

filter_var

Right, we need to see more of the code. it's not in the snip you provided. -Dan

Ok, these are the points you need to understand: 1) You cannot mix PHP and javascript. You've been told twice already and you're still doing it. setcookie() is a PHP function, and therefore cannot be inside your javascript. Ok? Read it again. Ok now move on. 2) PHP is a language used to generate strings. Some of those strings are HTML and javascript, and in that sense you can mix PHP/JS syntax inside your PHP script, but once the JS makes it to the user's browser it cannot execute PHP functions. This is confusing, I know, but you have to understand that a PHP script runs in the PHP interpreter on your server, and all the output of that script forms an HTML/JavaScript document that it sent, in whole, to your user's browser where it it parsed inside an HTML/JavaScript processing engine that is ignorant of PHP. 3) setlocale() in PHP does nothing for your site text, it will only change the output of built-in functions like date(). The article you linked to specifically mentions that you have to store all your translations in a special array and access them through a templating system. They use the locale as the key to that array, but that's all. 4) This cannot be the error. Always ALWAYS copy and paste errors to us. You have it right there on your screen. Copy and paste it. Your solution is to make a page which can change its output language (using a set of language files/tables that you design by hand) based on a global variable like a cookie or the locale. Then, put a language selector on your website which POSTs or otherwise redirects the user to whatever page they're currently on, but with a new language selected. Your templating system should handle printing the proper translation. -Dan

Add a user_level to your user table. Add a page to edit people's user levels. On every page, when you check for their login, also check to make sure they have the appropriate user level. Done. That's the most basic summary, you can expand on it any way you like, but it DOES involve a lot of code if you want to do it right.

Mod_rewrite is an apache module that uses a regular expression engine to take your first kind of URL and turn it into your second kind.

Google for user access control or user levels. It's very simple.

Since we've started a pity party, I'd like to clarify that Xyph didn't send you a warning for private messaging him, I did. What with it being against the rules and everything. Not knowing means you didn't read the rules, so your cunning argument of "other people broke the rules first" didn't sway me. Just clearing things up for the people-who-are-not-RaythMistwalker who come back to this thread to read about the ragequit.

Alright guys, let's try to calm down. Matt, we're perfectly willing to answer any questions you have, but what you said was "I acknowledge that you told me to read the article, and I have not yet read it, but I have some questions here that are covered in the article which you've told me to read and I still have not read." Nobody is going to respond favorably to that, not random posters on the internet and not even your teacher (whom is paid to put up with it). Read the article, and come back if you still have questions. If you've read the article and you still have questions, then please let's discuss it. We don't, that's why we provided you with a 10 page article about the topic which includes an entire encryption class you can download and use without understanding how or why it works. We're not trying to be jerks, but you're in well over your head and continued to ask relatively basic questions while admitting that you hadn't read the article that answers them. Go read. Come back when you're done and we'll continue. Good questions should be in the format of "the article says <quote> but I don't quite understand why"

Yet another syntax error. Slashes in Windows go the other way.

Matt, if a company with a breached password database said "well maybe you should have taken security more seriously" instead of apologizing, their customers would sue en masse (unless they're PS3 customers, naturally). The article in xyph's signature (which we really couldn't point out more unless I physically changed it to a big blinking box at this point) covers the answer to your next question about sha/md5, as well as later questions in your post. As for "what if my password is Qu!&!&!" or whatever: the larger the rainbow table, the more likely it will include random characters. A rainbow table of the entire english language is only 5mb. Including special characters, exclamation points, 1337-speak, and other variants would increase that size to 20mb maybe. Still not the biggest database and a comparison to an unsalted users table wouldn't take more than a few minutes. This is (roughly) what I did to make my site secure. Example variables with descriptive names are used. $secretSalt was an alphanumeric string that we generated when the user logged in. Also note that as an example I used md5 and sha1 in this example, read xyph's article for more correct information. if ( $userId % 2 ) { $encryptedPass = md5(sha1($password . $secretSalt)); } else { $encryptedPass = sha1(md5($secretSalt . $password)); } -Dan

See there where the loadModule line is wrong? That's what we've been saying this whole time. You're loading the wrong module.

Ok, back up. Windows: Your operating system. Required. Apache: The web server. You have version 2.2 PHP: The programming language. You have some version of PHP5, which sub-version doesn't matter. php5apache2_2.dll: The DLL necessary to connect Apache 2.2 with PHP5 under Windows. PHPMyAdmin: Completely irrelevant.

1) Automated submission and retrieval tools absolutely are a violation of the TOS unless each submission is explicitly typed out by hand. If that's what your tool does, then there';s no real reason for it to exist. However, if that's what you want and it conforms to their TOS (each entry is manually typed out by your users every time it's to be submitted) then fine, we can help. 2) There is no javascript on the page you showed aside from the form.submit() in all the onclick attributes. If that's all you want to emulate, use snoopy or curl to submit the form directly to the action itself. -Dan

To be fair, if he's really a linux tech he shouldn't be required to know how to start Apache on Windows. Hell, I don't know. Requinix is right about the file though, you had the wrong one. Use the right one, and make sure it's in the right place. Also make sure your syntax is correct as the error is syntax error.

The reason why craigslist uses JS is to prevent people like you from doing things like this.

This is due to session locking. The session file is locked by the first script and won't be unlocked until the script is finished (or calls session-write-close). Your second script, therefore, has to wait for the lock to be released before session_start can be called reliably. Your solutions are: 1) Fix that page that takes so damn long, no web page should take more than a second or two to execute. 2) Don't use sessions in the first page. 3) Unlock the session in the first page before you begin your long-running operation. Do not attempt to assign anything to a session variable after you do this on that first page. 4) Rewrite your session handling so the scripts can read/write in parallel. (Note: You are not good enough to do this one).

In the database, but that's all the info you get. Revealing the exact details of a security system isn't the best idea.

Why not continue this thread until we all die! I wrote the login system for a large social network. The salts were unique for every user, and they were not values exposed to the user in any way. Also, the mod of another user-unique value was used to determine which of our 2 rotating cyphers would be used first.

Err...did you miss the part where I said I work for a payment processor? We handle millions of credit card payments a day. Good trolls usually say things that make sense.

There are other way of dumping the contents of a table - Injection vectors we may not know exist yet. Right. It's possible for bad guys to list your password page through injection attacks, compromised database passwords, exploits in database security, exploits in system security, etc. Don't think "my friend frank will never steal my database and he's the only one who knows the password." In the time this discussion has taken place my office network has been attacked tens of thousands of times (I work for a payment processor).

if your database security is so poor that you end up revealing your user's plaintext passwords I hoped they're hashed. True, but they first must get it I still don't think you're quite understanding what we're saying: If you don't salt your passwords, and someone gets your database, then they WILL HAVE the user's plaintext passwords, either eventually or immediately through rainbow table attacks. Ok, read that again. If they have your database and your passwords are not salted, they will get the plaintext passwords out of it. Get it? Good. Salting your passwords properly prevents someone who has a copy of your database from translating the hashed passwords back into plaintext so they can be used on other sites.

Having your own database breached is generally a bad thing, but if your database security is so poor that you end up revealing your user's plaintext passwords (which they might use for online banking or email) then you have a whole other problem. You have to contact all your users (if you can) and tell them to change all their passwords everywhere else on the internet (assuming they use the same password for everything). You might be on the hook for any financial damages incurred due to your poor security (depending on the jurisdiction) and you'll certainly lose a lot more customers than if you had simply lost their order history but their passwords were safe. Everyone read the article in xyph's sig, it really is good.

When I visited it defaulted to english, and the language menu worked. Your translations are rather poor, however. Are you using a paid service or just Google Translate?