Jacques1

I don't know what you mean by that.

I disagree. The solution to XSS attacks is escaping, not switching to some other parameter which you hope is safe. In this specific case, you can actually omit the action attribute altogether. The default action is always the current resource, so there isn't any need for an explicit URL. Another problem is that the physical script name (as provided by $_SERVER['SCRIPT_NAME']) isn't guaranteed to match the public URL under which the site is accessible. As soon as you implement URL rewriting, physical names become meaningless and will likely break the frontend. So just leave out the action: <form method="post"> ... </form>

You need to combine the number extraction with validation. Users make mistakes. And some users even purposely break the applications of unsuspecting programmers. <?php /* * I don't know the exact pattern, so I'm guessing it's always 4 digits followed by an underscore, another 4 digits and * the extension. Change if necessary. */ const FILENAME_PATTERN = '/\\A(?<serial>\\d{4})_\\d{4}\\.txt\\z/i'; $filename = '0521_2145.txt'; // test $filename_parts = null; if (preg_match(FILENAME_PATTERN, $filename, $filename_parts)) { $serial_number = $filename_parts['serial']; echo 'The serial number is '.htmlspecialchars($serial_number, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8'); } else { echo 'Invalid filename!'; }

Please, stop. What this command does is add a key to your packet manager. That is, the key would be authorized to sign arbitrary packets. You absolutely definitely don't want this, because it undermines the security of your system. The fact that you need sudo (i. e. admin privileges) to simply import a key should have set off all your alarm bells. Please think before you run any commands. I'm frankly baffled by how much trouble you have with kGPG. I'm a first-time user, and I had no problems whatsoever generating new keys, importing other keys etc. So either there's something seriously wrong with your system. Or it's simply not the right tool for you. I suggest the following: Switch to a different system (either a physical machine or a virtual one). Install kGPG from scratch and again try to import keys. If there are still problems, forget about kGPG and use GPG from the command line. It may not be the most comfortable interface, but at least it won't screw up your system.

If you have to search by HTML entities (like đ), there's something seriously wrong with your application or your data. Does the database itself contain those entities? Then you need to repair your data first. Make a backup and write a short script which reads the encoded text, decodes it and writes it back. And, yeah, do use PDO. The 90s are over.

No. The first two columns are clearly tabular data, and it makes sense to integrate the input fields into the table. The point we're trying to make is that using tables without any tabular data for the sole purpose of aligning the content is an anti-pattern. You can see that in the OP's code.

Blindly adding a new connection for every URL is counter-productive. Find the sweet spot for the number of simultaneous connections and process the URLs groupwise (e. g. 10 at a time). You also need a concept for handling duplicate filenames. Right now, you just throw everything into one folder. You either have to create subdirectories or make the filenames unique. By the way, the PHP path functions are for paths. You have to apply them to the path of the URL, not the entire URL. Last but not least, you should fix your terminology. Right now, you can't seem to decide whether those are “uploads” or “downloads”. They're downloads. You fetch data from remote servers (uploading means sending data).

Of course. Those famous numbered kids. Now it all makes sense.

Your example isn't data. A form isn't data. I'm not sure why this is so hard to understand, but tabular data looks like this: username | registration date | number of posts ----------+-------------------+----------------- foo | 2016-01-16 | 383 bar | 2016-06-05 | 41 baz | 2016-03-21 | 163 Those are records holding information and sharing a common structure. That's what you use tables for. You do not use tables to align your form inputs.

... and I just realized this is a live site for a company.

Erase the code from your disk, forget what you think you know about PHP, start from scratch The Codeacademy PHP course (learning the basics of PHP) Exploits of a Mom (why security matters) (The only proper) PDO tutorial (how to communicate with a MySQL database in the 21st century) The PHP manual (lots of useful information and warnings)

Guys, it's 2016. The last time table layouts made sense was before HTML 4 somewhere in the mid-90s. In those 20 years, a lot has changed: HTML is now a semantic language, which means its sole purpose is to describe the logical structure of a document. It has nothing to do with stylistic information. That's what CSS is for. CSS offers all the layouts you want; yes, you can even emulate your beloved table layout (display: table). HTML tables are for tabular data. They do not exist for any stylistic purposes. When you're using tables to align text or inject newlines, that's plain wrong.

His database is full of numbered columns as well, and we've pointed that out many times in the last months – obviously without him making any progress whatsoever. I'm afraid it's one of those cases where you just have to wait for the person to get replaced and the application to be thrown away.

Yeah, well, that's not really how making technical decisions works. If this is an actual project, I strongly recommend you pick the simplest and most robust solution, that is, you either reset the numbering completely or skip to the last manually entered number.

This is simply too vague. What do you know about Ajax? Are you using plain JavaScript (which I don't recommend) or a framework like jQuery? Are you able to make a request and process the response with a callback function?

Why is it so important for you to fill the gaps between the manually entered numbers? It would be far easier to just start after the last manual number (maybe even add a safety margin) and use plain old auto-incremented numbers without any skipping magic.

What you describe doesn't make much sense. KGpg is a GUI for GPG. It shouldn't open any terminals, because the whole point is to avoid direct interaction with the GPG command line interface. I've just tried it, and the key is indeed generated without any console commands. Note that this takes a pretty long time, especially when dealing with large keys. So don't shut down the program while key generation is still in progress. Also double-check the KGpg settings, especially the paths to the GPG binary, the GPG home location etc.

There are plenty of other serious problems: You can't just rely on $_FILES['file']['type'], because this information is provided by the user and can be set to absolutely anything they want. In other words, I could upload arbitrary malware as long as I tell you it's an image. You cannot move the file to an arbitrary user-chosen location either, because this will overwrite existing files. In other words, I could screw up your entire upload directory (and maybe more?) simply by uploading garbage with common filenames. Where do you even copy the files to? I see no mention of a specific destination path anywhere. There's no error checking of any kind. I know, this is “just a school project” yada yada yada, but c'mon, you cannot be that naive. Has it never occured to you that code should be able to deal with both errors and malicious behavior?

Just remove the modifer. The replacement operation itself looks strange, but that's another story.

When in doubt, check the manual. Not only does it explain exactly what the modifier does; it also provides alternatives. In your case, the modifier does absolutely nothing. Either it's a leftover from earlier code versions, or the person writing the code was seriously confused.

Besides the database issues, you definitely need to work on your code. The script is riddled with security vulnerabilities, endless repetitions, obsolete HTML fragments (font is deprecated since 1997!) that don't belong there anyway, cryptic variables and arcane formatting. This is a simple task, so the code should be very short and easy to understand. RIght now, it's neither. It's generally a good idea to plan the script before typing, maybe on a piece of paper. This lets you see the bigger picture and come up with smarter solutions. For example, when you have many similar actions, you use loops rather than writing down the same code over and over again.

It should also be obvious from the UI. For example, Engimail explicitly asks if you want to export the secret keys as well (in which case you additionally have to provide the passphrase). In any case, you should check the file content before sending it. Never share anything other than -----BEGIN PGP PUBLIC KEY BLOCK----- ... -----END PGP PUBLIC KEY BLOCK-----

String interpolation in PHP is piss-poor, so either stop using it for anything other than plain variables, or get ready to dive into the parser.

I don't know how you've organized your pages, but you should. If there's a separate script for every page, you can hard-code the $page variable. If there's a single script which receives the target page through a URL parameter, you fill $page with that parameter. Like I said, it depends on how you've organized your application -- there are countless variations.

I'm still not sure if you've actually understood the PHP workflow. When you're running your PHP script, you know what page you're on -- otherwise you wouldn't be able to assign an ID to the body element. So just like you assign the ID based on the page, you can generate a class attribute based on the page: <?php $page = ...; // However this is determined ?> ... <body id="<?= html_escape($page) ?>"> <ul> <li class="<?= ($page == 'home' ? 'active' : '') ?>">Home</li> </ul> </body>