requinix

You mean are most questions we get here about Javascript? No, it's mostly PHP, but it's mostly PHP in a web context. As in PHP is running on a website and people are visiting it in their browser. Which means Javascript is an option. But sometimes there are non-web PHP questions. I don't know which one of those this thread is yet... If you want to run something every X minutes then the standard answer is to use cron: every *nix server has it, it runs in the "background", meaning it's not driven by or reliant upon users taking specific actions (such as "keeping the browser op

What are these two pieces of code that have to run at the same time? Do they have output? Where is the output supposed to go? Is this something that would be better served by running two concurrent AJAX requests on the client side?

You're going to have to explain that, because 99.9% of the time the correct solution is include/require.

/vojvodjanski.html -> /index.php?c=vojvodjanski /vojvodjanski/drustvo.html -> /index.php?c=vojvodjanski&kategorija=drustvo /hu/vojvodjanski.html -> ???

What index.php URL are the versions with /hu/ supposed to rewrite to?

A better explanation, but that isn't the problem. As I see it, you're trying to walk the line between security and no security, and you keep falling over onto one side or the other. There's only one thing I can think of: a subdomain. Your sensitive cookies are restricted to the main domain, user scripts run out of the subdomain, and the main domain does CORS as needed.

My point is that it's only possible to validate and protect oneself against things that are known. Someday, someone will come up with a new attack and wasn't being protected against because it wasn't known about. Do you let strangers come into your home and use your toilet? Before your next post where you shotgun another dozen questions at me, try to find the answers yourself. I only have so much time in the day.

Validated it fully as far as you know. Unless you consider malicious effects on the client, but dealing with those is a hassle. Because the user should not have control over how things are named on your server, and because directories are irrelevant. If you want to make it look like there are directories then do that on the frontend - the actual URLs don't matter. Maybe.

Are you looking for help doing this yourself or are you looking to hire someone to do it for you?

Mostly. Let people upload images to a public location as long as access is supposed to be unrestricted and you do a good job verifying that the files are indeed images. If you wanted to allow all sorts of file types then this conversation would be going a different way and you'd need to consider making them private after all. Some people will say you should do it anyways. Me, not so much, because it's easy to verify that a file is an image and to ensure that it is only ever considered to be an image. The alternative is to not do that - to make them private and accessible through a scr

But you want people to see the image. It's supposed to be easily accessible. That said, people should not be able to dictate filenames on your server, so generating your own name for them is still a good thing. It doesn't really matter where the images are. Consider the avatars on this forum: mine is /uploads/monthly_2021_02/catra.thumb.png.4c523d979ea05f55c35f4277018effe8.png. The only thing that shows is the upload date (nobody cares) and original filename (arguably useful information). It's fine.

What? Scrubbing what? Change what for security? What's insecure, and what are you saying about "served" somehow not using <img> tags?

I ask because various resources I can find all say that Origin: null means the AJAX request is coming from a file:// location.

You have a table for users, right? Add another table that has the user ID and a unique token. That token gets generated when someone uses the "remember me" option and gets stored in a cookie; it should have an expiration, both in the cookie and the database table, of however long you want it to last. When the user visits the site and they're logged out, you can use that cookie to look up the user (as long as the token hasn't expired yet, of course). You should also do some other checks to make sure somebody didn't intercept that cookie and start using it themselves, such as by checking the u

Clearly you have something on the server generating this file for you. Perhaps cPanel? Is there some tool you should be using to modify this file instead of doing it yourself manually?