Acmlm's Board - I2 Archive - Programming - Time() fails in PHP
| User | Post |
HyperLamer
Posts: 4819/8210 |
Yeah, I need to learn about databases at some point.  Hosting on this computer is hardly an option. It's cable, 15GB a month (and I generally use it all thanks to BitTorrent)... wouldn't handle much traffic, and isn't all that stable when there's a lot of traffic. (I'll betcha they disconnect me intentionally just in case I am running a server.  ) Not to mention this computer is slow as hell without that overhead, and the other one (which at 233Mhz and 32MB RAM is probably not nearly powerful enough) isn't working at the moment. |
neotransotaku
Posts: 3132/4016 |
well, a 100% solution to problems of other hosts is to do hosting on your own computer...have you ever considered that? but if you want traffic, your connection isn't probably sufficient then you have to make due with what you have.
as for securing data, you could try using a database if your service provider has one. |
HyperLamer
Posts: 4811/8210 |
Ah, I should be good then. I'm pretty sure other users can't access my account, and the files aren't really super-important. I just wanted to make sure all the really obvious holes are plugged. |
Ramsus
Posts: 74/162 |
You can't access files for writing via HTTP, so I wouldn't worry about "any random person." It only matters if you're on a server where other people have accounts on the same machine and can access your account via the filesystem (or know the path to the file with o+w permissions).
The permissions are necessary for CGI and PHP applications run by the webserver to access and write to files, because the webserver runs as its own user (i.e. www, httpd, or apache). A more secure setup would run CGI apps as the account's user using suExec, but I'm not sure if PHP as a module is able to be run in such a manner (one of the reasons PHP can be safer when run with CGI).
One way hosts can prevent problems is to block FTP and shell access to other accounts on the server (see if you can FTP to locations outside of your account. If not, it should be safe in this respect).
The other problem is PHP scripts on other accounts still have access to files on your account that are o+rw. This means an insecure script can give anyone access to your files. Setting basedir restrictions prevents PHP scripts from accessing files outside of a user's account though. If your hosting service doesn't have this setup, then you might want to switch.
Finally, if your hosting service does provide CGI, but doesn't run CGI processes as users via suExec, then I'd also suggest finding a new hosting service. Otherwise, there's nothing between any CGI application on the server and your writable files.
Why does all of this matter? Because without these simple precautions, any 10 year old can write a few lines of PHP, Perl, Python, etc. that can compromise the entire server and every site on it. So why risk the unnecessary downtime and loss of productivity?
Also, if you have to keep files in your DocumentRoot that you don't want people to see, put them in their own directory and set up an .htaccess config file that blocks all access. Your PHP scripts can then read the files, but users browsing the site won't be able to download them. |
HyperLamer
Posts: 4796/8210 |
Hm, no, that's giving me close to $old_time.  (Plus you forgot a semicolon after print_r(). )
Another problem... I managed to get writing to files to work, but to do so, I have to set the 'write' attribute for Public on the file. Doesn't that mean any random person can write to it? |
strager
Posts: 3/3 |
$cur_time = getdate();
$old_time = getdate(552899100);
$new_time = getdate($cur_time[0] - $old_time[0]);
/* DEBUG -- Should print an array */
print_r($new_time)
echo($new_time[0]);
Maybe that'll work, even though it looks like an insane duck. |
HyperLamer
Posts: 4703/8210 |
echo time() or echo $time returns the current time stamp. The result of any math operations I try to do on either of them doesn't want to come out right though. Either it acts as if $time/time() is zero, or it returns the past date itself (or close to it). 
Also, I have no control over the server's configuration. 
*thwaps board for not loading and doubling tripling my post* |
kode54
Posts: 4/7 |
Also works here, using the official win32 build of v5.0.4. What do you get when you echo time()? |
sloat
Posts: 50/85 |
it's either the system or php itself. all that php's time function does is call the c stdlib time function, time(NULL).
If the system's time is screwed up, then it's gonna screw up the time function. I don't really know what the problem could be with the system time though.
The other possibility is that whatever version of php you're using wasn't built properly. I'd say this is more of a consideration for win32 builds, but I wouldn't rule it out even if you're using *nix. Download a newer version and try again.
I can't really imagine what else it could be other than those two things. Your code worked just fine for me, using 4.3.11. |
strager
Posts: 2/3 |
Maybe:
/* Replace hour, minute, second, etc. with the old time (552899100). */
$past_time = mktime(hour, minute, second, month, day, year);
echo(date("y n j G i s ", (time() - $past_time));
Off the top of my head.. |
windwaker
Posts: 1620/1797 |
Is that the only code in the file? |
HyperLamer
Posts: 4679/8210 |
I dunno why but it seems to randomly return 0. I'm trying to find the difference between the current time and a date in the past, by subtracting the timestamps, but all I end up with is either the current date or the one I'm comparing it to. The code is simple enough:
$time = time();
$FUCKINHELL = $time - 552899100;
echo date("y n j G i s ",$FUCKINHELL);
If I print $time - 552899100 (or the best-named-variable ever ) I get -552899100 meaning $time = 0, but if I print just $time in the same piece of code I get the current timestamp. WTF. |
|
