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?

I'll ask once again because I'm pretty sure the correct answer is not what you've been saying: Is the Javascript code running from a document context of www.webucate.me or something else? Are you perhaps running it as a local file?

iframe or not, if your code is running on the same domain you're trying to send a request to then you don't "need" CORS, and the default behavior of browsers and servers should be fine... The same request and response you posted. That's the OPTIONS and, presumably, its reply, right? Because they say that the allowed origin is the exact same thing that the error message is complaining is not present. What are the headers from a failed AJAX request and response?

Now I'm lost because I thought this was a CORS question. The Javascript code that is running and sending AJAX requests. Is it doing so from a document context of www.webucate.me or some other domain?

You can't set the Origin, that's protected, so if it's sending "null" then that probably means you're not running from a suitable location. That aside, the cookie is SameSite=Strict, so if you're not running from www.webucate.me then you can't use it.

If you don't need to access the cookie in code and only care that it gets sent through the AJAX request, then yes: withCredentials would do it. Should be pretty easy to figure out whether that solves your problem. Without error messages or a set of failing request and response headers, there's not much else to do but guess at what's wrong...

The whole point of an HttpOnly-flagged cookie is that you cannot read or write to it in code. It's right there in the name.

Unless someone here has specific knowledge about the sort of thing you're trying to do, we're not going to be able to tell you what's wrong unless you can describe what you're seeing. First thing to do is get more information. If you can't tell whether you can connect or not, that sounds like a good place to start. Maybe try some other, simpler cPanel operation to prove that the code is valid? Also see if you can get any logging or error messages that could indicate what's going wrong.

One of those two will work and the other will not. What will happen is, if you do the correct method then it will work, and if you do the incorrect method then it will not work.

As both error messages clearly state, you cannot change session settings after you've already started the session. It should logically follow that if you want to change settings then you have to do it before the session is started.

Forget everything you know about IIS and C#.NET applications, forget all those common practices about shared memory on the server, and start learning PHP from the very beginning. Because trying to apply your C#.NET experience to PHP will cause you lots of problems. The answer you're looking for is probably sessions.