Jacques1

Did you read the whole reply? When you don't call event.preventDefault(), then the form is actually submitted in addition to your Ajax request. So you'll see the error message for a short time, and then the page is reloaded with an empty message box. Or are you talking about a different problem? Then you'll have to be more specific.

Shouldn't there be something like event.preventDefault(); to prevent the form from actually being submitted? Your code is also wide open to cross-site scripting attacks, because you take $_GET['mode'] and happily drop it into the script element, allowing anybody to inject arbitrary code. Never insert user input into a JavaScript context. Use a whitelist of valid prefixes and only allow the user to choose one of those. Even better: Put the PHP value into a hidden element and read it from there instead of directly echoing it into the JavaScript code: <?php function html_escape($raw_input, $encoding) { return htmlspecialchars($raw_input, ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML5, $encoding); } const MODES = [ 'Desktop' => null, 'Foo' => null, 'Bar' => null, ]; if (isset($_GET['mode']) && array_key_exists($_GET['mode'], MODES)) { $mode = $_GET['mode']; } else { $mode = 'Desktop'; } $data = [ 'mode' => $mode, ]; ?> <div id="data" class="hidden"><?= html_escape(json_encode($data), 'UTF-8') ?></div> <script> var data = $.parseJSON($('#data').text()); alert('The mode is: ' + data.mode); </script> This reliably prevents any code injections.

I'm fairly sure the name of your database is not hercules.xymmetrix.net. That might be the hostname, but not the actual database name. Since trial-and-error won't help in this situation, you'll have to figure out your database credentials. What does your old code say?

What? I don't understand what you're saying. That doesn't make you a cryptographer. If you absolutely must have encryption, no matter how stupid it is, at least use a high-level library like libsodium which takes care of all the ugly details instead of relying on the developer to do that.

We cannot help you without seeing the actual code. Don't worry: Nobody will plagiarize a 10-line RPN parser. It's not like this was a novel idea. Generally speaking: You need to know the arity of each operator, because some of them are binary, others are unary (like the negation).

Silently redirecting the user whenever they try to access a nonexistent resource is extremely confusing, especially for automated clients. There's a good reason why we have error codes like 404. When a resource doesn't exist, the client should know.

Script kiddies (as well as professional attackers) are defeated through secure programming and competent system administration, not toy cryptography. Instead of wasting many days or even weeks on a highly questionable feature, it makes much more sense to spend a few hours on hardening the server. Do you have prepared statements everywhere? Content Security Policy? Clickjacking protection? Anti-CSRF tokens in all forms? Minimal database privileges? A separate PHP-FPM pool and Unix user for each website? Secure programming competent system administration. CBC has nothing whatsoever to do with authenticity. It's actually trivial to make the first block produce arbitrary plaintext by changing the initialization vector, and the other blocks aren't protected either. Authenticated encryption requires a correctly implemented combination of a cipher and a message authentication code (like Encrypt-then-MAC). There are also some special modes like AES-GCM which inherently provide authenticity, but those never made it into PHP, and I'm not aware of any plans to add them. But why are we even discussing this? It's not the job of a web developer to implement cryptographic algorithms.

What you want simply doesn't exist. Unless you're willing to spend thousands of dollars on dedicated crypto hardware, the best you'll get is some half-assed toy encryption. And you may not even get that. Blowfish is obsolete as well, and Mcrypt is an incredibly poor library. If those are your choices, forget about it. What are you talking about? PGP/GPG never claimed to work on a compromised system. It doesn't.

The example implementation is pretty much the worst you can possibly do with regards to encryption. DES is a toy algorithm from the 70s which was deliberately weakened due to export restrictions. Last time I checked, it could be broken in less than a day. Then you use the infamous ECB encryption mode known from the Adobe hack. And finally you abuse a human-readable string as the “key”, turning the already shaky implementation into a joke. To be blunt: With this kind of encryption, you're better off storing the data as plaintext. That's at least honest. Personally, I very much doubt that encryption even makes sense for the average website, because it's a lot of trouble for a very small benefit. Without a hardware security module, proper key management is virtually impossible. You definitely cannot stuff your keys into the session files, because then you have a folder full of keys with no access control and no cache management (the session garbage collector only runs occasionally). So really the only option is to have a single application key which is used to encrypt the data before you store it in the database. But your database probably is on the same server as the application? Then your key is stitting right next to the ciphertext, which isn't very useful. Implementing encryption with a low-level library like Mcrypt is also extremely difficult: You need to choose an appropriate algorithm and a sensible cipher mode. You have to generate a perfectly random initialization vector for every single plaintext and store it in the database. Encryption doesn't prevent the data from being manipulated, which is most likely an issue as well. So now you have to worry about authenticated encryption. This task is almost impossible for a layman, so you'll end up giving your users a false sense of security instead of actual security. If at all, you'd use a high-level library. But then again: What's the concrete benefit?

You need to run the set_vars.sh in the background so that the first Ajax request returns immediately. Then you periodically make a new Ajax request to get the current output of the long-running set_vars.sh process. As a basic example: When you first start the process, you generate a random identifier and pass it to the process as well the the client. The process runs in the background and appends its output to a file named something like <identifier>.txt. Each Ajax request reads from <identifier>.txt, starting at the last offset of the previous request. So the first request starts at offset 0 and gets, say, 38 bytes of output. The next request starts at 38 etc. When the process is done, the server tells the client to stop making requests. There are certainly more sophisticated solutions, but this should be the easiest one.

I don't think you've understood Ajax yet. Please give yourself at least a day or two to learn the basics. And then try to actually conceptualize the code before you write it. I mean, sure, we could do this the trial-and-error way. But then we'll spend at least a week on bugfixes, which IMHO sucks.

Not sure if I understand you correctly. Are you saying that jQuery is unnecessary, bloated and buggy? Then I have to disagree. jQuery is an excellent framework which does make life a lot easier, because you don't have to write tons of low-level boilerplate code to get things done. It's not huge at all. The compressed file of jQuery 2 is just 80 kB, which is probably less than the website logo. I don't remember encountering a single bug in jQuery, but I do remember a lot of bugs in plain JavaScript code (especially browser incompabilities). Personally, I've andoned plain JavaScript entirely (even for small project), and I certainly don't want to go back to the days where I had to write 100 lines of code only to make a friggin' Ajax request.

ImageMagick Or, if you're using some shared host where you cannot install anything, there's the GD extension.

This whole approach is just weird. You should look into Ajax and set up a proper PHP API to be accessed by JavaScript instead of messing with spaghetti code and ob_flush().

So any visitor of the site can reset anybody's password, and then you send the plaintext password accross the globe so that it can rot in some inbox? Your code is also wide open to SQL injection attacks. Never heard of Bobby Tables? To be honest: Right now, your code makes the site less secure than it would be without any log-in system. So either you get rid of it, or you need to learn basics of security and start from scratch. I know, this sucks. But watching some script kiddie take over the entire server sucks even more. I'm sure your friend agrees.

The hosts file.

thara, you're missing the point. I explicitly told you that fixing the two example defects does not fix your code. I even put a “disclaimer” before my reply, but you just ignore it and do the exact opposite. As I already said multiple times, critical code cannot be written in a trial-and-error fashion and requires a period of learning and preparation. But you, again, ignore all advice and continue your trial-and-error loop. An authentication system is not a friggin' HTML layout where you can just keep moving elements around and pressing F5 until things look OK. Sorry, I can't help you. Maybe somebody else is willing to assemble the 10,000th half-assed PHP log-in code. I'm not.

Instead of actual single quotes, you have some kind of fancy quotes: ‘ should be ' So you'll need to fix your editor. You also need to turn the error messages back on so that PHP will tell you what's wrong: error_reporting display_errors (not to be used in production!) Last but not least, the mysql_* functions are hopelessly outdated and will be removed in PHP 7 (which is released in a few days). Nowadays, we use PDO.

Yeah, well, that's not really a good idea. Web scraping is OK for one-off tasks. But you wouldn't build an entire platform around a very fragile and very unofficial hack. You may actually get in trouble with the shop owners, because not everybody is OK with bots posting data. And even if you're allowed to do it, you get zero stability. The forms will probably change all the time, and that means your tools will break all the time and require manual updates. Sounds like a nightmare. So before you jump to the technical implementation, you should clarify some conceptual questions. Are you even allowed to do this? Is everybody willing to accept the problems of this approach? Is there really no better way like a basic API? etc. In any case, this is way beyond the capabilities of a help forum. You'll need a lot more than a beginner's tutorial for cURL.

There are perfectly legitimate use cases for automated form submission. Sometimes a website simply doesn't have an official API. But, yeah, the problem description needs to be a lot more specific. sasori, why don't you give it a shot? The Internet is already full of code snippets, so that shouldn't be the problem. If you run into an issue, post your code and tell us what exactly you don't understand.

So the target website has a form, and instead of manually filling out that form, you want to send the data automatically? Yes, this can theoretically be done with cURL. If this form is only accessible to authenticated users, you'll have a hard time automating the process, because you need to maintain a session and probably even scrape the anti-CSRF token from the form before you're allowed to do anything. If the form is public, it's a bit easier. Either way, your program may break at any time, because the website owner might change the input parameters. What exactly are you trying to achieve?

The point is: This is a help forum, not a place to upload your code. If you want to help somebody, make sure the thread is still active (this one clearly isn't), and then give specific advice. The user should learn how to solve the problem, not just copy-and-paste somebody else's solution. Regarding the problems of your own code: First of all, you have no security whatsoever. You stuff the user input right into your queries and the HTML markup, leaving your application wide open to SQL injection attacks and cross-site scripting. The mysql_* functions and HTML elements like <font> are also hopelessly outdated and have been replaced more than a decade ago. Nowadays, we access our database with something like PDO and style our pages with CSS. So again: Please don't just post your code, especially if you're a beginner yourself.

Yes, but please note that the two defects are just examples. I'm not saying that your code will be OK if only you add two new bugfixes. There may be plenty of other problems which we simply haven't seen yet. With that being said: When you use filter_input() with the FILTER_SANITZE_STRING flag, you damage the user input. The function will scan the string for anything that looks like HTML and remove it. This is nonsensical (the password has nothing to do with HTML), ill-conceived (by the PHP core developers) and downright harmful, because removing characters from the password will weaken it. In the worst case, you end up with no password at all: <?php // before: an excellent password $password = '<"(]AxQZ/~Sc@4ImnaXs'; // mangle it $password = filter_var($password, FILTER_SANITIZE_STRING); // after: an *empty* password var_dump($password); It's generally a very bad idea to silently change user input. You can validate and reject the input, but never turn it into something different. Using SELECT to check if the username already exists doesn't work either, because it creates a time-of-check-to-time-of-use defect: If two clients simultaneously request the same unused name, they're both allowed to have it, because at this time, the name indeed doesn't exist in your database. However, the actual insertion happens later, and at that time, the condition is no longer true, because one of the users will already have inserted the name when the second user executes the INSERT query. In the worst case (there's no UNIQUE constraint attached to the username column), you now have a duplicate name -- despite your check. The only way to prevent this situation from happening is to encapsulate the check and the insertion in a single atomic operation. This must be done by the database system itself: Set up a UNIQUE constraint on the username column, run your INSERT queries with no prior checks and then catch all constraint violations. What's nice about this is that it also makes the code much shorter and a bit more efficient, because you only need a single query. See this example implementation. Like I said: Implementing an authentication system is very difficult, because defects like this cannot be found with standard tests. There's no PHP error message to tell you that your username check will fail in certain scenarios. You have to know it in advance.

Besides the severe problems already pointed out by QuickOldCar, your $foo = $_POST['foo'] stuff is executed in any case, because it's outside of the if ($_POST) check. Using if (!count($error)) to check for the presence of errors also looks wrong to me. Shouldn't that be if (count($error))? Or better yet: Use a less weird form like if (count($error) > 0).

First off: If the images can lead to cyber-bullying, they don't belong on a webserver at all. No matter how many PHP scripts you put in front of them, that doesn't change the fact that they can eventually be accessed and shared via a standard URL. So don't put too much expectations into your access script (the same is true for your hotlinking check, by the way). At best, you can try to make the images a bit less public. Set up a secure random number generator. For example, use bin2hex(openssl_random_pseudo_bytes(16)) to generate random tokens. Create a table which maps tokens to images and stores additional information like the expiry date. Hand out share links to the image owner. For example: https://images.yoursite.com/token=d4261fb9af53989d2c8d55caa4bd812c In your access script, look up the token, check the expiry date, and if everything is OK, display the image (if performance is a concern, use the Sendfile mechanism rather than loading the file into PHP). // I'll move your topic to the PHP section, because this doesn't really have anything to do with Apache.