requinix

/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 script. And there are non-security benefits to that, like making it easier to count views, and full customization of the URL (with rewriting). You might as well consider whether you want to do that, but if you don't now and change your mind then you can use URL rewriting in the future to make it happen pretty easily. As for the user creating folders and specifying exact file names? No. You need to retain 100% control over exactly what each file is named and where it is placed on your server. You can incorporate the original name into the name you use, if you want, and for an image hosting thing that would probably be a good idea, but ultimately your code decides what to do. But you know, if you want to stop thinking about this, just go with the private thing. It's not wrong to do it. You have to worry about MIME types and file caching and partial responses, but those are solved problems.

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 user agent and/or IP address - though both of those can vary legitimately for a user. Mostly just the user ID. You can include other information, like the email, but if you do then you have to worry about what happens when the email address changes by a session on another device - say, they change their email on their desktop and later continue browsing on their phone. So it may be counter-intuitive but storing less data is good. Hackers cannot inject session information unless they have direct access to your server, in which case you're royally screwed so it doesn't matter. If someone is capable of reading files on your server then encryption or a .htaccess won't do anything. No private files should exist under your website's "public" directory (eg, public_html) at all. Configuration files, source code, and other things that aren't supposed to be directly sent to the user's browser need to be outside of that directory. For example, a good project structure would be /path/to/your/site/ - config/ - public/ - index.php - CSS files - JS files - images - src/ - your source code - uploads/ - uploaded files, if you do this - vendor/ - Composer files Your site's DocumentRoot would be public/.

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.

What about the other settings?

Mobile apps don't care what technology you have running on your server. You can definitely use PHP to send notifications.

Then this isn't a datatables problem. It's a session problem. Increasing the session duration is the answer, but there are multiple settings to consider. What does phpinfo() say your session.* values are?