ManiacDan

I haven't seen it, but if there's an API then it's supposed to be used. What kind of code do you have? What is it supposed to do?

Screen-scraping the microsoft website is against their terms of service.

But I just said...I use them. They're valid email addresses and it's annoying when they don't work. It take a lot more than you think to actually upset me. All I'm saying is that you, personally, cannot possibly make the declaration that certain kinds of email addresses don't count. Once your have a form that marks a valid email as invalid, it is broken. You may have broken it on purpose for various reasons, but it's broken. You're just going to annoy people like me (and, apparently, you) by disallowing valid emails. As for my comments about australia, I've seen users decide that filter_var is not what they want and roll their own email validation. Each and every one of them forgets about the stacked TLDs like com.au. There are better ways to combat spam aside from breaking email validation. You could do duplicate analysis without the plus-addressing part. You could run IP analysis. There's plenty of other ways without rolling your own email validation.

1) Your statement includes quotes around the variable: WHERE ID='$obitid' 2) Famous last words. 3) the HREF attribute (like ALL HTML attributes) must be surrounded by double quotes.

But the problem I have with that is: That means you have to write your own custom validation which will absolutely 100% fail to match someone's actual valid email address. Writing your own custom validation takes you a lot of time and it can't be correct. I have never seen anyone (amateur or professional) write a proper email validation regex on their own. So if you say "I have a reason not to use filter_var," then from my experience you're also saying "screw people from australia and anyone who uses plus addressing and anyone who's email ends in a number and any number of other categories that I can't think of right now."

Well that's why I use filter_var. It will allow ALL valid emails, and disallow anything else. What goes through filter_var has to match the email specification, which means that somewhere, somehow, sending an email to that address will reach a valid box (or potentially a valid box). Then you do the second phase, the "click here to confirm your account" link in the email itself. Putting your own validation spin on things will only annoy the users more. I've had addresses with weird TLDs, and I like to use plus-addressing (like I demonstrated above). Most custom by-hand email validators don't allow maniacdan+theSiteName@phpfreaks.com That's what I like to use to do proper filtering on my gmail box.

With custom TLDs that would be even more annoying, and would break on IP addresses instead of hostnames. Still though, if it's a valid email address, I say allow it. Even if that means a@b gets through. It's valid, let it through. Do further email validation to make sure the validly-formed email is actually accessible by the human being the filled out the form.

If they're smallint and auto-increment: 1) Why are you quoting them, they're numbers. 2) What happens when you overload the smallint datatype? It will run out at 32767 rows. 3) If you're expecting a number, how did you get an apostrophe?

That's very true, but that's also a valid email address. As is maniac+dan@ff::0 There's an interesting debate about where your line could be drawn. -Dan

You should use basic date math, and the greater-than operator. No functions, this can be done in a query assuming your tables are properly set up. What have you tried already? What table structure do you have? What PHP code do you use? Be brief and to the point, but give us something other than "how do I make a click only happen every 15 minutes"

Which tells me: 1) Your IDs are not numeric. You should fix that 2) You're not passing strings through mysql_real_escape_string, which would have solved this problem entirely.

Tables should never be used for LAYOUT. The "CSS > Tables" line is referring to layout. If you want a left navigation and a header image, don't use tables for that. If you want to display a table...use a table.

Agreed, obitid is probably the problem. Like what was stated above, print out your fully-formed query and look at it to find the error. There's probably an apostrophe in your obitId Also, sunfighter's tip is wrong. MySQL and PHP are separate languages. The error you were getting was coming from the MySQL server, which ONLY knows about the single-line query you sent it. -Dan

If you're displaying tabular data, use tables. That's what they're for.

I think all javascript scrollbars wreck usability. Many of them don't respect the page up/down keys, home, end, or shift+arrow keys to move/select text. That's basically all I use.

You've been developing with error_reporting turned off. Never do that again.

Have you done any error-checking or error-handling?

According to mygamercard.com, this business is failing. Microsoft has closed the support channels that enabled it,and for-profit companies are starting to abuse the existing services to the point where they may not be usable.

The w3c suggests the following for a general purpose first-pass email validation in javascript: function validateForm() { var x=document.forms["myForm"]["email"].value; var atpos=x.indexOf("@"); var dotpos=x.lastIndexOf("."); if (atpos<1 || dotpos<atpos+2 || dotpos+2>=x.length) { alert("Not a valid e-mail address"); return false; } } However, I don't think you've understood the main point: Do not rely on javascript. javascript cannot ever be relied on for anything. It's used to make a page pretty where available. It can be altered or disabled by the user. You cannot use it for ACTUAL validation. You must use filter_var for that. -Dan

How does your code differ from the manual? From what I saw, you were using ? instead of named params. Are you sure those work? I didn't read the whole manual because I'm not trying to get this to work, but what I saw all had named params. Find the section that does it your way, see what's different.

"Known only to your code" means "don't make it your domain name or put it on a post-it." What with it being a bare word in your code (or a config file), it can't actually be a secret in the strictest sense of that word. As for key stretching, that's exactly why that was developed. Cryptography is a constant war. First we had md5. That wasn't computationally complex enough, so we came up with sha. Then rainbow tables became relatively easy to use, so we added salting. GPUs were involved in password cracking, so we couldn't even do that anymore, so we went to key stretching and better hash functions. The war will continue forever. (Disclaimer: Not an accurate representation of an actual timeline, don't use this for research papers or cite it during an argument). -Dan

Alright, some numbered questions: 1) Avoiding leaking server details: Your production server should have errors off entirely, only logging them to a file that's not readable by the public. Errors all the way ON in your dev environment, OFF in your production environment. Do not ever dump SQL, usernames, or file locations to the screen. That's why error pages are so infuriatingly vague. "Oops" gives an attacker no information. 2) Input filtering. You probably got confused at the line: if (!preg_match('/^[a-zA-Z0-9_]{1,60}$/', $user)) preg_match is a PHP function that parses regular expressions. Regular expressions are their own language (compatible with perl, the unix command line, and many other languages) and they're pretty difficult to understand. This particular preg_match will return if the username is between 1 and 60 characters, and it only allows letters, numbers, and the underscore character. 3) The source of pwqcheck: This is too difficult to do line by line. It appears to be writing commands to the unix command line though...which is pretty stupid. It requires the pwqcheck program to be installed and configured. It doesn't appear to actually sanitize the password though. I wouldn't use a command-line library for password validation. This is the perfect spot for a regex. I assume you understand why echo does what it does, and that was just an example.... 4) A "salt" is a random string that's known only to your code, which you stick onto one end of the password or the other (or in the middle, whatever) to increase the complexity of the string and to make the hash less susceptible to rainbow tables. While your users may use the password "fluffy," if you include a salt to make the salted string "fluffy*nuc49nc*$&*Th" then that string is far less likely to appear in a rainbow table. See? Sha/md5/hash, after the plaintext password has been salted, are used to one-way hash the resulting salted password so that the resulting value is not reverse-engineered. So to summarize: A salt is a string you add to a plaintext password to make the resulting hash (using a hash method like md5, sha, or crypt) MORE secure. Salting is not a hashing method. Every salt is eventually crackable, but the methods they use to generate the hashes are so complex that they cannot be reverse-engineered mathematically. You can only crack them using brute force. Salting slows the brute force process. Everything is always crackable. Even SSL is crackable, and with the advent of quantum computers coming (fingers crossed) in the next 15 years, we'll see instant cracks for the most complex cyphers. We'll have to completely re-work security when we start doing quantum computation. Sony stores their passwords in plaintext. Simply declaring that you're secure doesn't do anything unless you're actually secure. Look at Valve for a good example. Valve's servers were compromised and their database stolen. However, the one-way salted and hashed passwords cannot be retrieved even by the person who has possession of the database. The inner workings of the actual hashing functions are too complex for me to handle here. You can look up videos and explanations of how each individual hash function does its thing. It's extremely complex, there's a lot of math involved, and it's really hot all that interesting, even to math/cryptography nerds like me.

Yeah...PHPOrCaffiene's first post didn't show up for me at all. I just saw you (freelance84) posting what I thought was the wrong information two different ways. Either way, filter-var on the PHP side is the only "correct" solution, plus some JS validation using regex. While it's true that filter_var implements regex, it's not a wrapper per se. I never said anything about regex being wrong or...anything like that. If you use filter_var you get the right regex. If you write one yourself you get the wrong regex. Therefore, use filter_var to get the right regex. I'm a big fan of writing regex (in fact I moderate a regex forum as well), but only when there's no other solution available.

Per the manual, the array passed to execute() must have key names that match your bound param names.

Ok, a number of things: 1) I didn't notice that the OP was using javascript. Never rely on javascript for validation. The PHP filter_var function I linked to is the only 100% reliable way to validate emails. You can use JS to make it pretty, but don't rely on it. 2) The link posted by freelance84 is wrong. Don't use ereg, ever. It's deprecated and will be removed in future versions of PHP. 3) The regex provided by freelance84 is also wrong. Sure, it will succeed for many (most) emails, but it's not correct. -Dan