requinix

When you log in as a user and then ask the system who you are, it will tell you that you are the user you logged in as. I'm not talking about shell access. I'm talking about PHP when it runs on your website. You have root/sudo access on a shared hosting server? Are you sure it's a shared hosting server? As in there are multiple people with access to the same server your site is on? PHP the application. If your setup uses mod_php then PHP runs as whatever user Apache runs as. If your setup uses php-fpm then PHP runs as whatever user php-fpm is set to run as. That's... not the right thing to do. If you set up the server yourself then you are not, in fact, on a shared hosting server, and therefore most of what I said was a waste of your and my time. And they're right in this situation. And by "right" I mean "wrong". There's basically no reason to put yourself in the www-data group, like, ever. Okay, now I'm confused. Are you running your website on a shared hosting server or not? I don't care about what you're doing locally or on a test server or whatever. I mean, the place where your website is running, is it "shared hosting"? The first guy is wrong. The second guy is mostly right because "you can't even write files to your own server" is partly what you actually want to be the case. Like I said in my first reply, it depends. Primarily on dedicated vs. shared hosting. Just like how the question "how do I put my car in reverse?" sounds really simple but actually has multiple different-but-similar answers.

One is Javascript, one is not. Does what you have now work? Is there anything that says it's obsolete or deprecated? If not then keep using it.

This is a link to the page. The link does not matter once you arrive on that page. If you want to do something with that page then the link to the page is not where you should be focusing your efforts. If the scraping is all done in PHP and there is no output of any kind (or you can remove all of the output already there) then all you have to do is use a header() redirect at the end of the script.

For both questions it depends on the server setup. Even with shared hosting there are multiple approaches. The questions you need answers to are: 1. What user is PHP running as? 2. What group is PHP running as? 3. Do you have a personal "billybob" group too? (Probably.) 4. What other groups do your user account belong to? On shared hosting, it's somewhat common for PHP to run under your own user account. It has exactly the same access to files and directories as you do. It sounds like that is the setup you have. If that's the case then there isn't much point messing around with permissions: you and PHP are the same user so it doesn't matter what group you assign. In fact, it's quite possible that by changing group ownership to www-data you're creating a problem, because if your account is also in the www-data group then that means other users on the server are probably also in the www-data group, and changing group ownership away from your own personal group you've decreased security. But that could easily not be true - I think it would be weird and unlikely that you are a member of www-data, but if you aren't then I don't know how you changed group ownership to it...

What's happening behind the scenes is a matter of 32-bit versus 64-bit integers. You know how everything is 64-bit now, right? That's kinda true. Signed (=capable of representing positive and negative values) 32-bit integers are limited to +/- 2.1 billion. If each of those is 1 second and you start counting from January 1970 then that stops sometime in January 2038. A lot of software is still 32-bit, but less and less each year. Signed 64-bit integers are limited to... well, a very large number in the unfathomably-distant future - which is to say, as far as timestamps are concerned, it's effectively unlimited. Unless you want to try to count sub-second intervals, in which case it's slightly less than but still more or less unlimited. For a simpler example, consider Y2K. If you represent years as just 00-99 then December 1999 ends with you starting January 1900. The best solution to that is to use more digits: four digits means you can tell the difference between 1900 and 2000, just like how with 64-bit numbers you could tell the difference between Jan 1st 1970 (0) and Feb 7th 2106 (2^32). Regarding PHP, it's been 64-bit for a very long time, except on Windows when it's only been available since PHP 7.0 (which most people would also count as "a very long time"). But Y2K38 is still a thing.

PHP won't try to guess your timezone. Tell it explicitly what you want with date.timezone. Like realistically, how often are you moving servers?

No. Using eval is a really bad idea. There are always better solutions to problems than using eval. $num is the only unknown part, right? Look at this: $gm = array( 9 => array( "hodds" => $games[53]["BP"], "aodds" => $games[52]["BP"] ) ); echo $gm[$num]["hodds"]; Really easy.

If you want to submit the form and redirect then you cannot do it with any Javascript or other alterations to the button itself. Has to be PHP. What is the code that handles the form submission?

Have you looked at the HTML source of the page? To confirm that the links really are not being outputted, as opposed to some CSS issue that's hiding them from you?

What?

Almost: 4.19 * first 75 units (314.25) + 5.72 * next 92 units (526.24) + 30 flat charge = 870.49, +5% VAT = 914.01

Did you mark your own post as being "the solution" because you figured out the answer yourself? Or are you still having problems?

Most "hacks" are people gaining access to a database by way of SQL injection. Encryption would help because they can't get the encryption key - just the data. Of course the problem with encryption is that if you lose your key then you lose everything. Irrevocably. Plus the obvious drawbacks of having to encrypt and decrypt stuff all the time. Shared hosting is itself a risk, too. Can you move off it? Besides the dedicated environment being more secure, you can also mitigate SQL injection attacks by moving the database off to another server - one not exposed to the internet - and on this same server you also put a simple webservice that gets and stores customer data. Essentially, you make API calls to yourself when you need that data.

No. You can't see the forest for the trees. This is a really, really basic and fundamental question about what files are and what file_get_contents does. The kind of thing that I would expect you to know the answer to, if not for the fact that you're in up to your neck in something you don't understand.

With ^([^/]*)$ then /vojvodjanski.html -> index.php?c=vokvodjanski.html 1. Make the .html optional so that /vojvodjanski.html will continue to work and you do not create 404 errors for old URLs that are still being used. 2. Make the last [^/]* -> [^/]*? because * will match "everything" but *? will match "until". RewriteRule ^([^/]*?)(\.html)?$ /index.php?c=$1 [L] 3. You must change the URLs on your site to not use .html. Because mod_rewrite will not change your website for you. <a href="/vojvodjanski">

RewriteRule ^(hu)/([^/]*)\.html$ /index.php?lg=$1&c=$2 [L] This URL is very similar to the /vojvodjanski/drustvo.html because they are both "/" + word #1 + "/" + word #2 + ".html". If you want word #1 "hu" to be special then you must put this RewriteRule before the [^/]+/[^/]+.html RewriteRule. If you want another language, like sk, then RewriteRule ^(hu|sk)/([^/]*)\.html$ /index.php?lg=$1&c=$2 [L]

I don't know how any of that would help - at least not in an automated way. If you want to remove "hidden scripting" then use an image processing library that can deal with the image and strip out everything else that doesn't matter. However that doesn't eliminate the possibility of someone going through a whole lot of effort to create a plain image whose compressed data contains a malicious string. If that's even possible to do. You cannot protect yourself against everything. You can protect yourself against things that actually matter.

Oh dear. A raw image from a camera is where it records, with its electronic circuitry, the "colors" of each "pixel" that it can measure. It records that in a file in the very most basic way that "pixel X,Y is color Z" can go. Raw image files are large because there's a lot of data. To deal with the file size, images are compressed. If I write "computer computer computer" that takes 26 characters, but if you and I agree on another representation of words, I could compress the message to something like "3x computer" and 11 characters. Lossless PNG images work the same way. I could compress it even further as "3x cmptr" (8 characters) by stripping out the vowels, thus losing some information but still leaving enough that you know what I'm trying to say; lossy JPEG images do that. That takes care of the image itself, however images have more information than that: GPS coordinates where it was taken, camera model information, etc. That has to be represented in a way that doesn't conflict with the image data. The easiest way to do that is to say, inside the file, "The next piece of information is the GPS coordinates: (...). The next piece of information is the camera model's name: (...). The next piece of information is the compressed image data: (...)." PNG and JPEG and such images dictate compression but they also dictate how those blocks of information are arranged, and software capable of reading them will know how to read each block - or perhaps how to skip each block it doesn't care about until it finds the one(s) it wants. The information in each block can vary: the GPS coordinates block may have two 32-bit floating point values for the latitude and longitude, the camera model name may be a string value, and obviously the image data is image data. Consider one of the simplest attack vectors: PHP code inside a string-type data block. I could take a real image, add a "camera model name" block, and specify as the name the string "<?php phpinfo(); ?>". That's perfectly valid to do. I could then take that image, rename it from bad.png to bad.php, and try to upload it. Unsafe image uploading code will attempt to read data about the image, discover that the file is a very legitimate PNG, and upload it to a location like /uploads/requinix/bad.php. See how it kept the same file name and extension? I could then go to the website, go to /uploads/requinix/bad.php where the site thinks is going to be an image, but the .php extension will be run as PHP code and I'll get phpinfo() output. You can protect yourself against those attacks by following best practices about file uploads - most significant being determining the appropriate file extension on your own instead of trusting the uploaded file's name to be correct. More complicated are attacks that target specific image parsing code. Not your website itself, but the software that knew how to read PNG images directly. I'm not going to go too deep into this because it's complicated. Remember the camera model string? There's one question about how it works: where does the value of the string end? The two typical answers are that the length of the string is included (so "camera model block" + string length + string) or that the string is terminated by a special character (like NUL \0). So what happens if you don't obey that rule? I might take that bad.png I created before, load it into a special editor, and break the string (by altering the string length value or by removing the \0). With appropriate adjustments I might be able to trick an image parser into doing things it isn't supposed to do. You cannot protect yourself against those attacks, practically speaking.

If you're looking to hire someone to do this work for you, the Job Offerings forum would be a more appropriate place. If you want help doing this yourself then you can start by explaining how you tried to fix the code and what happened when you did.

Are you sure the user that the web server is running as has the permission to create tasks under the SYSTEM account? See if you can create one without any associated user information.

And your question is...?

A few ways of tackling the problem. The one that probably makes most sense for how you've set this up so far would be the simplest one: add a column to your "mad" table for the final phrase. If you don't have one already, there should also be an AUTO_INCREMENT ID in that table so you can easily refer to specific rows - this column is dealt with for you so you don't need to come up with values or put it into your INSERT queries. Then you'll need to get that phrase. Right now you just output it, so change that process so (1) you store the phrase in a string variable and then (2) you echo that. Depending on what values you pick for your madlib, you may or may not discover that you can't use $name and $adjective and such after you've escaped them. Try it: pick a name like "O'Malley" or a noun like "my father's shoe" and find out what happens. See the backslash in front of the quotes? $name and such as fine for using in a SQL query but that's because their values have been altered, and that will interfere with you trying to put it into a sentence. To fix that you should forget about mysqli_real_escape_string and instead switch to prepared statements. What you do with your $sql now is combining SQL syntax (parts like the INSERT and the list of column names) with data (the parts of speech) and this has the potential to confuse MySQL if something in the data isn't quite right. It's why you have to use mysqli_real_escape_string - but then you have the backslashes. There are simple ways to resolve that, but the best way is a prepared statement: instead of combining syntax and data, it keeps them separate and tells MySQL "here's the query and here are places where you need to use a piece of data". No combining them means no confusion. Prepared statements are easy: look here for a reference that tells you how to use ->prepare and ->bind_param and ->execute. With all that in place, you should have: 1. A string variable for the phrase that has all the data inserted into it. Make sure it looks right when your words have apostrophes. 2. A "mad" table that has columns for an ID, name, adjective, verb, noun, and the final phrase. 3. An INSERT query that mentions the phrase column (but not ID) and uses question marks for where the different pieces of data go. 4. Code that ->prepare()s the query string you had, ->bind_param()s the different variables (the data coming from $_POST directly is fine, and the string phrase), and ->execute()s. That's enough work to start with. When that is in place, look in your database to see that it's inserting everything correctly. Then post your code, we'll look over it, maybe have a suggestion or two, and then move on to the next part: the random link to a previous story (this will be easy), and/or the random story from previous values (this will be more complicated because we should do some more changes to your database to help with it).

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 open so something can do AJAX requests"), and you can still do just about anything you want with PHP. For the 30 minutes one, you make a script that runs whatever database queries it needs. I don't know what it's supposed to do if the value changes? Then you tell the server (exact steps vary) that you want to run some command-line program (ie, PHP with the path to your script) every 30 minutes. For the 10 minutes one, you make a script that runs whatever database queries it needs. Then you tell the server you want to run a second program (also PHP) every 10 minutes.

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.