requinix

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.

Posts edited. I don't see anything that says MATCH arguments cannot be sent through a prepared statement. What is the full code you have now regarding that query?

Use two TBODYs, the first with edited rows and the second without. When one of the rows in the second gets edited, move it to the end of the first.

Reminder that when core.autocrlf controls when Git converts line endings: - true = CRLFs in your working directory, LFs in the repository - input = whichever in your working directory, LFs in the repository - false = no conversions For the project you were contributing towards, if they asked for core.autocrlf=true then they want LFs in their code. That means you need either the "true" or "input" settings, depending whether you care about having CRLFs in your working directory. That's only ever useful if you want to open or edit a file in a dumb editor - which used to be Notepad, but since the October update that's finally no longer the case. So I would use core.autocrlf=input - LFs normally but with graceful handling of CRLFs. If you're the only developer then it doesn't really matter, but most people use LFs.

You have to scroll down to the Strict Typing section to see that PHP will coerce by default. So the "int" hint does what you want.

mb_check_encoding is fine to use if you want to verify you're receiving valid string data. If your "binding" does that already then you don't need to add it.

Can you be more specific about this "not being read" or "read twice"? What had you changed when this started happening?

Here. This looks like a reasonable example I just happened to find lying around somewhere. server { listen 80; root /var/www/votes/public; index index.php index.html index.htm index.nginx-debian.html; server_name rather-long-name-demo.demo-apps.tk; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php7.2-fpm.sock; } location ~ /\.ht { deny all; } access_log /var/www/votes/storage/logs; # server_names_hash_bucket_size 64; }

Don't edit the default file. Revert it to the original, disable it from sites-enabled, then create a new file in sites-available. The file only needs one server block, or two if you want http+https support. No http block, that's nginx configuration and would belong somewhere else if you needed one at all.