requinix

Let me put it this way: Is $sql supposed to be a prepared statement or not?

There is no difference. I just posted the problematic code. For reference. Ideally you would take another look at it and realize what the problem is, but if not you, someone will.

$sql = "SELECT * FROM users WHERE email = $email"; $stmt = mysqli_stmt_init($conn); if (!mysqli_stmt_prepare($stmt, $sql)) { echo 'SQL error 2'; $my = mysqli_report(MYSQLI_REPORT_ERROR|MYSQLI_REPORT_STRICT); echo "- $my (2)"; exit();

Where the data comes from is completely irrelevant. All the PHP has to do is return the correct JSON. That part looks fine. How about the Javascript that makes the AJAX call? What have you tried for that?

If expires is a Unix timestamp (ie, a number and not a string), which is what date(U) suggests even though the placeholder says it's a 's'tring, then instead of CURDATE() it would be UNIX_TIMESTAMP().

What have you done for the AJAX stuff so far?

Not since the death of XHTML. <br> is correct. HTML does not do self-closing tags.

You're trying to call send() on a PEAR_Error object. That would be $smtp. Apparently, $smtp is an error. You should check what the error is.

Approach #2 sounds like #3, and they both sound like #1 but with more work. If the token is for a single purpose and it inherently includes the necessary information to determine what that purpose is then the token by itself has everything you need.

Okay, yeah, that's not really "overloading" as the rest of the software industry calls it. I didn't even remember PHP called it that. Creating properties and methods dynamically like that isn't a great practice, even if it is somewhat common in PHP. It can create unusual behaviors that are hard to debug. Try to avoid it. However, using __get/set/isset* as a means of accessing fake properties is alright. It's mostly a matter of using the -> syntax as shorthand for something else. Consider a Config class that loads data from a file. The pure OOP method of accessing that a value "foo.bar" would be like $config->get("foo")->get("bar"), but you could repurpose the -> operator for properties to allow $config->foo->bar. Neither "foo" nor "bar" should be defined as properties on the object because they're dynamic, so you implement __get to behave the same way as a get() method. In fact, very often a Config class will have both and __get calls get() - mostly because get() tends to support a default value, which you can't supply through ->. __call is similar in that you might need to call fake methods, but it's less common and I avoid using it. Methods are basically never the sorts of things that should be done dynamically and should only happen in rare cases, none of which come to mind right now. __callStatic is even rarer and is pretty much only for static singletons. * If you implement one of those then you should implement all three of them: __get and __isset are an important pair because getting values often includes checking if it is set first, and __get and __set should be a pair to keep consistency with how someone may use the -> operator (even if that means, for read-only objects, that __set always errors).

What version of PHP are you running?

As far as security goes, a simple link is not going to be secure. You can't verify identity, only that the person has access to the email account. Are you sure that's sufficient? If so then your hands are basically tied: create a single-use (probably) token/random identifier and embed it into the link. You can also audit the use of the link, eg. not just by logging the usage but also whether the usage happened with a logged-in account. For indicating the action to perform, there isn't a whole lot of difference whether the token identifier includes the action to perform or not. However, if it's not part of the token (and is in the URL) then you'll probably want validation that the user is requesting an action authorized by the token, and at that point you already have sufficient information from the token itself (given that it's designed to be used for one purpose) that you probably don't need to put it into the link anymore. So the token will inherently be identifying both the user and the action.

MySQL can do this more easily than PHP with its TIME_TO_SEC function.

There's a website people sign into, right? Can't you use that? Have the link take them to whatever URL and use the regular website authentication to verify identity?

Also note that PHP errors do not show up in your browser's developer console*. They will be outputted as messages right into the page, or they'll show up in a log file, or they'll not show up at all, depending on how your PHP is set up. It's confusing to me to need to say this because you clearly saw the Undefined Index notices earlier. Are you using some PHP extension to get errors into the console? Does it support doing that with fatal errors too? (* edit: unless you have one of those PHP+browser extensions that lets you do that, but those are rarely used anymore)

Overloading as in multiple methods with the same name but different signatures (argument lists)? Checking because we're mostly PHP here and PHP does not have overloading.

There are two other problems, but they should be giving you error messages. Do you see any error messages?

$_POST["userid"] and $_POST["password"] will only exist after the form has been submitted. The first time you load the page, obviously it won't have been, but that code there is still trying to run. That thing you commented out? //if($_SERVER["REQUEST_METHOD"] == "POST"){ That detects whether the form was submitted. You need it.

No, for a couple reasons: 1. Regular assignment (=) assigns values. $username gets the value of $confirm_password - it's not literally saying "$username is the same thing as $confirm_password". 2. Technically, $a = $b = $c does not say $b=$c; $a=$b but actually $b=$c; $a=$c. It's a minor point that basically never matters. So the statement is really more like $confirm_password = ""; $username = "".

Not getting errors is a good thing. How about you try describing your problem? What is supposed to happen and what is actually happening?

Don't use IE? Really. Microsoft doesn't even want people to use IE anymore. I don't think they even install it in Windows anymore. But if you insist, how about a screenshot?

You've been given the answer: "yes, but you have to write code to do it". Even if it's just tracking you, the process is still the same. PHP won't do all this for you. However, if it's just you then maybe you don't need the session. Maybe just logging the information is enough and you can look through the logs?

You cannot track the user back through every page they visited. You can track them as they browse your website and you can sometimes (not always!) see what page they were on immediately before the current one. The answer is what gw1500se said: if you want to know what someone does after they click a button then track what they do after the click the button. Store each page in an array in the session, and when they get to the page you care about you can pull that array out. This is commonly referred to as "conversion tracking" or something similar. It's common for virtually every website that has some ecommerce or monetary aspect to it in order to see what drives people to the "goal" (them spending money) and what does not. So if you want to know more about the concept, there's some keywords for you to research.

Often those two conditions can be combined into one actual rewrite: move to https://www if the request is http or it's not www. Like for Apache, a RewriteCond with [OR] plus another RewriteCond.

www versus no-www matters. http vs https should not. Canonicalize everything and redirect appropriately.