requinix

PHP's time() function returns a Unix timestamp. It is the same value for everyone. You have to know something about where your user lives. With only PHP you can use geolocation on their IP address to get a good approximation. With Javascript you can get their "timezone" (UTC offset) with the Date object, which does not tell you their location.

It won't print out anything because the code is invalid. We can't help you troubleshoot your code if you don't provide us with your real code.

Apparently from the EXIF information that's embedded in the image. When you take a picture with most intelligent cameras now, they include metadata in the image about the orientation of the camera. Since the photo is always upright with respect to the camera, one can use the metadata to rotate the image so that it's upright with respect to the photographer. Unfortunately the camera (software) manufacturers didn't stop to consider that maybe the camera should automatically flip the image and then use EXIF to give the "original" orientation...

Side comment: the image orientation should be fixed right when it's uploaded, not when it's being displayed to the user.

1. What is the URL in your browser's address bar? 2. What do you see when you View Source the page?

I can't tell what code is in what file. Try this with a post: Put the filename on a line, hit the Code <> button and put the file's code in there, and repeat for the other files. That way everything is clean and separate and has syntax highlighting and doesn't force me to scroll so much.

If you don't see it in the source then you added the code to the wrong template. Or you accidentally put it inside some block that's only outputted for logged-in users. Either way, needs to go somewhere else.

For the record, if you're dealing with mobile devices then you can get GPS information - if the user allows you to do so. Non-mobile devices will give you information according to the IP address (user still has to approve), which will be more or less the same as the geolocation version. Basically, geolocation is only as good as a country and state. City is hit or miss.

Is the ad code present in the page source?

Yeah, something more needs to change here. The form only supports one entry at a time. To support more than one, you'll have to (a) store each entry somewhere, best choice being a database, and then have the user hit some sort of Finish button so they can view the results, or (b) alter the form so that the user can enter more than one at a time. The second option is probably better: the user does all the work on one page, and when they submit you can show the results immediately. What do you want to do?

User doesn't care. They don't look at URLs when they're just browsing around, and if they want to share the page they'll either use a share button or copy/paste what's up there. In fact that copying and pasting is a huge reason why ideas like putting session IDs into the URL (PHP's session.use_cookies/use_only_cookies) are strongly discouraged. That said, try to keep it simple. example.com/product.php?id=123 (or /products/123) is fine. Attempting to obfuscate it because you're scared, like example.com/product.php?product_id=uw433hyg5kishev6nyliser6nbyioq2gv49n68of325ob8nq534tb8, is not fine. People don't like things they can't understand: "123" is a number and people are okay with numbers, "B00005N5PF" is some sort of cryptic ID but it's okay too because it's short and easy to understand, but "uw433hyg5kishev6nyliser6nbyioq2gv49n68of325ob8nq534tb8" is a code and codes are for hackers. CoDeS aRe FoR hAcKeRs Probably, yeah. Lots of stuff on the internet already works like that. People are used to it.

Is that what you want to do? Sounds right.

The PHP you showed and that WebForms-based code are completely different... How about this: what is the HTML form you need to support, and how are you going to present the results to the user?

The code you posted is full of syntax errors that would prevent PHP from executing it at all.

Well, I do see a number of things that are incorrect, and some things that should be done differently, but so far nothing that would prevent it from working outright. If you don't see any errors then it means you don't have PHP set up to report them correctly - or at all. Make sure you have error_reporting = -1 log_errors = on in your php.ini. Then look in your error log (according to the error_log setting, or else your web server's log) for messages. There will be some, so if you don't see any then it's not set up right.

Please post your actual code instead of... whatever that is.

What words in there do you not understand?

You've gotten feedback. Lots of it. Including feedback when you asked me for help over PM. I still say the hash is unnecessary, but if you want to use it then go ahead and use it in order to identify which video your script should be displaying. That's a completely separate issue from whether you use X-Sendfile or not. Neither of those will "scramble" the URL so it cannot be copied, but as long as your PHP script checks then it's perfectly capable of ensuring that only logged-in users can see the video (which has nothing to do with whether you use a hash or not).

Apples and oranges. If you at all understood what each one did then you should be able to answer your own question by virtue of the fact that only one of them is actually relevant to your question. As for an answer to that question, read this thread.

Apples and oranges. X-Sendfile is a way to have your web server send a file to the client. Apples. The hash is a way to identify which video to use for a particular user. Oranges.

🍎 🍎 🍎 🍊 🍊 🍊

1. REQUEST_URI is the whole thing. Path and query string. Test the REQUEST_FILENAME instead. 2. As such it's thoroughly untrustworthy when it comes to you thinking it's a filename. Don't. 3. Super unsafe validate.php would allow people to download any file from your website. Video. Image. PHP script.

An example? Don't have one. But they're straightforward: <?php if the user is not logged in { http_response_code(403); exit; } if the requested video does not exist { http_response_code(404); exit; } if the user does not have access to the video { http_response_code(403); exit; } $file = the path to the video file on the server if somehow the file does not exist { http_response_code(404); exit; } header("Content-Type: the mime type of the video which you should already know"); header("Content-Length: " . filesize($file)); readfile($file); Beyond that you should try to support caching and request ranges, but this works at a minimum.

Sure: don't make the video files publicly-accessible, and instead route them through a PHP script.

The browser and the user are indistinguishable. There is no way to hide the video from the user but still allow the browser to get it.