requinix

openssl_x509_parse looks relevant. What have you tried with that?

I don't know much about them, but Queues could potentially be useful for this. The standard solution is to have something running in the background, as in via a cronjob, that periodically looks for tasks and executes them until it runs out. The API server responds to a request with some sort of task identifier that can be polled later, and only queues up the job to be run. When the background process runs it eventually gets around to that job, it updates the status (which could be returned by a poll) and then does whatever it needs to do.

No offense but this is a very basic math question. https://www.google.com/search?q=how+to+convert+numbers+between+different+units

And what, may I ask, do you think "complete cyber security mitigation" is? If you are good with Python and Java then use Python and Java. Why PHP?

Read the documentation for get_current_user() and tell me what it says.

$_SERVER["DOCUMENT_ROOT"] will be the path to your public_html.

Just make sure not to put ginerjm's code onto a real server running on the internet.

Looks like your problem is that you're using regular expressions for parsing HTML instead of PHP's other features. https://3v4l.org/6mIfq

What's outdated is not the include() function itself but how you use files and write the code inside them. But first things first: see if you can track down the conflicting $serial variable and change it to be something else.

You're probably using the $serial variable for something in another file. If you use this outdated pattern of including files then you have to make sure you don't accidentally reuse variables.

Separately, XHTML has been dead for years. Longer than it was alive, I think. Learn and use HTML 5 instead.

No clue.

Have you investigated whether those services provide push messages or notifications? So that you don't have to poll them yourself. Because if you have to poll them yourself then your data will always be potentially out of date.

If you think my explanation was detailed then you should check gizmola's 😁

The Content-Length in the request header (if there even is one) does not describe the file. It describes the entire request. Take a look at how multipart/form-data requests are structured and that might help explain what's going on. https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/POST Could very well be. But these things are also frequently dependent upon the application itself. Maybe what you need is not so much a library but a curated database you can read. Assuming you validated that the provided type was correct, because if not then you shouldn't be storing it at all, then you would use it instead of whatever type you tried to guess it was. Sure. Why would it matter if they were different?

It can't be: the size is not just the size of the file but the amount of content that the browser sent to the server. If this did not match what the request actually had then there would have been problems. That's the big one. MIME type detection is naive and optimistic: it assumes that if the file has a few bytes in a certain location then the entire file is that one type. It won't be able to detect files with mixed content (think PHP code buried in the middle of some HTML) or files using containers (OpenDocument files are ZIP archives) or many types of text file formats. It can accurately detect audio and video data as well as "unique" binary formats. That's where you have to enter with some specific knowledge to make decisions. The detected types are correct, they're just not what you expected or wanted. Windows particularly tends to identify files by extension, then equate those extensions with MIME types according to whatever software is installed. For example, having Office/Excel will tell the system that .csv files are vnd-ms.excel because... well, because that's what it's been doing for a very long time, but point is that a Windows browser will happily report vnd.ms-excel because that's what it knows the file as. That's especially useful for text files. Linux too will frequently deem a file a certain type according to the extension and only use MIME detection as a fallback. And I agree with that. It's a huge pain to try to deduce MIME type or the correct file extension just from the contents. So don't do that. Instead, in the general case, validate that the MIME type you detect is consistent with the extension - and optionally with the reported MIME type. (That's the general case. For more specific cases, like you only want to support images, sometimes it can be done reliably with only MIME types.) And above all else, if you want to store arbitrary files, install a virus scanner or two. Mostly disagree. While you should assume the client is malicious, in the real world that's very often not the case, and throwing away data because it might be incorrect is hurting youself. But how do you know it does not match? It's easy to pick examples like images, but what about HTML with some PHP code buried in the middle? You'll receive a .php extension but detection will say it's .htm/html.

If you want advice about how to design this application then we're going to need a LOT more detail than what you've given so far. Especially about how users "own" APIs.

Process them in batches through cronjobs?

If you're looking for "tips" and "tricks" then what you mean is you want shortcuts so that you don't have to understand how stuff works. If you don't like thinking about it then don't think about it: do exactly what guides and blogs and documentation say to do and don't stray from their advice.

The "Apache" in "Apache log4j" means the umbrella project, not the web server.

Given that $types has only one entry in it, yes: using key() and current() is a good solution in practice. It wouldn't work if something was iterating over $types using next(), but that is very likely not happening.

Is authentication supposed by handled by a client certificate or by a standard username and password? That error message suggests the connection is fine and the credentials are wrong - after all, the client must be able to connect to the server if it's able to report to you information like "the credentials are wrong".

There's a syntax error in your query. Take a look to see if you can spot it, otherwise use mysqli::$error to see what the error message can tell you.

If the arrays are crafted in a very specific way, ie. with the fields set in the order that they should be sorted on. A custom sort is a little (still a one-liner) more complicated but won't suddenly break if the arrays are built differently.

...no? Or did you change how the form works? Because everything so far has been with POST.