Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
cka
May 3, 2004

Treytor posted:

Okay, now how would I display inline the amount of time remaining per IP?

For example, taking the ip log recorded from above and in a new page I would have:

code:
<b> You have *PHP here to show time remaining for this IP* minutes left until you can try again</b>

The simplest way would be to record both the current time and the time + 3600 seconds in your log file, and change banned.html to banned.php (and/or just incorporate your banned notice in that php script itself... subtract 1-hour-in-the-future time from current time, divide by 60 and ceil() the result to have your remaining minutes.) Another simple way would be to record the time information in the users' cookies via setcookie() and bang out some javascript that does it client-side, although that can be pretty easily side stepped.

I gotta say though, using a SQL database (even if your table is of poor design, though it probably wouldn't effect it speed-wise for something like this) really would be leagues better than this file i/o and array madness you've got going here.

Also, I'm not too sure if it would matter or if it's just the OCD freak in me, but your math could use a quick fix here:

if ($now < ($subdata[1]+3600*$timeout) && $ip == $subdata[0])

should be

if ($now < ($subdata[1]+(3600*$timeout)) && ($ip == $subdata[0]))

in my mind, the first equation would be a loving huge number if your timeout was 2 hours because it would basically multiply the time + 1 hour by two...

Adbot
ADBOT LOVES YOU

cka
May 3, 2004

admiraldennis posted:

Well then apparently your mind doesn't follow simple PEMDAS (and it really, really should if you're working with programming languages).

I like the first version much better personally; it's not cluttered with extraneous parentheses.

Just my OCD then, no harm no foul. Also, just FYI, I actually was following BEDMAS (same thing as PEMDAS, evidently) with those extraneous brackets around the 3600 * $timeout.

edit: well then

cka fucked around with this message at 09:20 on Mar 25, 2008

cka
May 3, 2004
You'd have to rig up an Ajax request to process the form without reloading the page, but that ain't hard at all (especially if you're using something like jQuery in your project.)

cka
May 3, 2004
That should work fine, just make your php script dump out a image or something (1x1 transparent gif would suffice) so you can avoid stuff like the red X on IE:

php:
<?php
/* stats script doing stuff here 
   ...
*/
header("Content-type: image/gif");
echo file_get_contents("/path/to/transparent.gif");
?>

The only thing you gotta be wary of is whitespace in your file (particularily after the closing php tag), as that may screw the script up and make it give off the "headers already sent" warning.

cka
May 3, 2004
Yup, I got a site running on Kohana 2.1 (that I have to probably upgrade to 2.2 soon) and a cms for said site in the works. It's a pretty sweet lil' framework.

cka
May 3, 2004

Strong Sauce posted:

Have you used CodeIgniter before? Do you feel that there are that many advantages to Kohana's strict PHP5 framework vs CodeIgniter's which supports both PHP4 and 5? How often is Kohana updated? I always wanted to transfer over to Kohana but was always worried about the project being abandoned.

Nah, I haven't really used CI. I read up on a few frameworks and decided on Kohana cause it was strictly written for PHP5, which is fine since that's what we're running on our server (and it seemed like the easiest to get my project off the ground with.) For the most part, Kohana is really easy to work with, and while the documentation isn't as stellar as I'd like it to be it does the job (as does their forum.) What I like about it so far, and I'm not sure if CI has this functionality too, is that I can override core functionality easily with my own libraries. I have my own default controller class that handles session stuff and authorization with users in a vBulletin database in the CMS I talked about.

The big problem with it right now is that it's still in a wild state of development -- they changed a bunch of the core functionality between 2.1 and 2.2, and nothing really feels concrete in it still since there seems to be even more core changes in the 2.3 svn version. My site uses some on-the-fly routing with the _default() class function, which is one of those major changes they made in 2.2. That's partially why I've stuck with 2.1 so far (the other reasons being I've been busy with my other, real job and extreme laziness/procrastination in my spare time.) Plus, if it ain't broke...

I don't think you have to worry about it being abandoned, but if you did want to switch over I'd follow their update trac/changelogs for awhile to make sure they aren't drastically changing how core functionality works.

cka
May 3, 2004

royallthefourth posted:

That sounds like a great prank, but I'm sure someone's done it in a real application. :psyduck:

vBulletin does that for its templating system (and I think the hook system in the 3.5+ releases.) At the very least, it's convenient.

cka
May 3, 2004
Probably this: http://us2.php.net/array_unique

cka
May 3, 2004
You can always use func_get_args() in your function to sort of emulate named parameters/overloading functions... it'll take a bit more code to make the values match up to whatever you want the arguments to be, obviously, but it's somewhat doable. Probably not worth the time or code though.

php:
<?
function f()
{
  $args = func_get_args();
  print_r($args);
}

echo f(1, "test", "args");
echo f("test", "args");
?>
outputs:
code:
$ php ./af.php
Array
(
    [0] => 1
    [1] => test
    [2] => args
)
Array
(
    [0] => test
    [1] => args
)
edit: a slight modification makes named variables possible!

php:
<?
function f()
{
  $named=array();
  $args = func_get_args();
  foreach($args as $key => $val)
  {
    if (ereg("=", $val)) {
      $_tmp = split("=", $val);
      $named[$_tmp[0]] = $_tmp[1];
    }
  }
  print_r($named);
}
echo f("name=Dave", "message=Foo");
echo f("name=Steve", "message=Check this out!", "status=Checking...");
?>
code:
$ php ./af.php
Array
(
    [name] => Dave
    [message] => Foo
)
Array
(
    [name] => Steve
    [message] => Check this out!
    [status] => Checking...
)
Still probably not worth your time to do it this way, though

cka fucked around with this message at 02:08 on May 29, 2009

cka
May 3, 2004
Is this enabled in your php.ini file?

code:
; This directive tells PHP whether to declare the argv&argc variables (that
; would contain the GET information).  If you don't use these variables, you
; should turn it off for increased performance.
register_argc_argv = On
I tested your argv thing on a server here and it works just fine, so this is probably your issue if the $argv array isn't being set on a cli script...

cka
May 3, 2004
Either disable the submit button on form submission (the simple way), or add in a unique indexed column to your database to prevent duplicate data from being posted (the other simple way.) On your form, have PHP generate a hidden input field with uniqid() as the value, and use that data as your unique key. Then, if someone double-submits, the data should only be added once (the query on the second insert would fail because of the unique key data submitted.) You can also probably work it into your app as a CSRF token if it's a publicly available script, which would also help secure it up a bit.

cka
May 3, 2004
Kohanas 2 and 3 are in theory identical (as good as PHP frameworks can get), and apparently perform the same, the deciding factor probably boils down to whichever style you like programming in -- HMVC (3) or regular MVC (2). 2 has a leg up in that it already has familiarity, a stable codebase and a poo poo-ton of docs, but 3 has new enhanced features like $this->request to handle the request flow, a 150% better/more powerful routing system, easy sub-request controller calls in controller methods to make code more portable, FAR better ORM plugins, etc. 3 kind of sucks in that they stripped out a ton of the random functionality from 2 and modularized it, but I can understand where they're coming from there.

If you're looking for opinions, I'd say stick with 2 until 3 matures some more and gets some half-way decent documentation out (as nice as the wiki on kerkness.ca and cheat-sheet sites are, they're still no real replacement for developer-written, example-based documentation.) The only lovely part is that you'd have to rewrite your sites almost from the ground up when you did upgrade to Kohana 3; something I truly don't wanna do but probably have to do at some point...

Quick & dirty examples of Kohana controllers to show differences:

php:
<?php
// classes/controller/kohana3.php
class Controller_Kohana3 extends Controller 
{
  public function before() 
  {
    // Kohana 3's version of controller::__construct()
    // good for setting up controller specific variables and initializing
    // database connections if required
    parent::before();
  }

  public function action_index() 
  {
    // $this->request is the lifeblood of your Kohana 3 app, as it 
    // handles all of the information you want to display through the request flow
    $this->request->response "honk";
  }
  public function after() 
  {
    // post-request code runs here, this functionality is handled by 
    // binding an event trigger in kohana 2
    parent::after();
  }

}

// controller/kohana2.php
class Kohana2_Controller extends Controller 
{
  public function __construct() 
  {
    // constructor to set any controller-wide variables or do any controller-wide code
    parent::__construct();
    // bind a post-controller event to mimic kohana 3's controller::after() behaviour
    Event::add('system.post_controller', array($this'__postrequest'));
  }
  public function index() 
  {
    // since there's no $this->request to handle the request flow, 
    // Kohana 2 outputs controller method data directly
    echo "honk";
  }

  public function __postrequest() 
  {
    // this functionality is not native to Kohana 2, 
    // but we can bind it with the event trigger functionality
    // great for doing stuff like GC, session updating, or statistics tracking
  }
}

cka
May 3, 2004
Thirding the Kohana 2 recommend. I'm working on something right now in v3, and my main source of documentation and reference is Google/kerkness.ca wiki/kohana forum posts. Kohana 2 will definitely do what you need it to, and there's enough docs to help you get to the finish.

And for the record, the routing engine in 3 really is completely different than in 2, but also seems more powerful (mostly because you can do neat poo poo like on-the-fly scaffolding triggers in modules/subdirectory controller requests to hide their true paths and such.)

cka
May 3, 2004
Is this common PHP behaviour or just some wacky configurations by the hosting company: I'm writing a script right now that should handle specific script-created directory removal, but specifying any sort of path value in a variable adds in data that I don't want and fucks up the directory checking/manipulation functions, eg:

php:
<?
// for the sake of reference, I'm passing script.php?mode=del&amp;dir=1234-20100503
$rm_dir = preg_replace("#^[a-zA-Z0-9\-]#", "", $_GET['dir']); // quick & dirty injection protection
$my_path_check = "/home/*******/images/{$rm_dir}/";
echo "<xmp>";
echo var_dump(is_dir($my_path_check));
echo $my_path_check;
echo "</xmp>";
?>
echoes out

bool(false)
/home/********/images/1234-20100503/.htaccess/

Now because PHP (or whatever modifications were done to the php installation) adds in that .htaccess bit, I can't reliably check if that 1234-20100503 directory is legit or not so I can't get the script to do what I want it to do. I don't work with directory manipulation much, but whenever I did I don't think I ever ran into this problem so I'm thinking it's just a hinky setting or patch on the host machine. Is there a better way of quickly checking directory existence that won't be impeded with random poo poo getting added into my code?

FWIW, before I had it set to remove single files and that worked fine, but I have to make the jump to directories because I need to delete collections of files.

cka
May 3, 2004
Ugh yeah, I always get tripped up on that quick regex character strip (but that's neither here nor there).

Also as far as my problem goes, I think I've figured out what it was. I'm just a big dummy on Monday mornings. Referencing pre-existing php files in the application I'm adding to gave me the impression that all the get/post vars got processed out of the $_GET/$_POST arrays and sanitized/globalized but apparently that wasn't the case. Instead of using $_GET['dir'] (and previously $_GET['file']) like I should have done as per the pseudo-code posted, I was referencing $dir and $file, both of which inexplicably kept showing up as ".htaccess" strings. I've since fixed my code and all is well with my directory check/delete function and I feel like a giant idiot.

Mondays :rolleyes: Thanks for the assistance though.

cka
May 3, 2004
Why regex? sprintf('%.2f', $value) should do exactly what you need it to do for this...

code:
# php ./honk.php
string(4) "1.00"
string(4) "1.20"
string(4) "1.23"
string(4) "1.23"
string(4) "0.23"
string(4) "0.23"
string(4) "0.20"
string(4) "0.00"
string(4) "0.00"

# cat honk.php
<?php
function test_regex($input)
{
  return sprintf("%.2f", $input);
}
var_dump(test_regex('1'));
var_dump(test_regex('1.2'));
var_dump(test_regex('1.23'));
var_dump(test_regex('1.234'));
var_dump(test_regex('.234'));
var_dump(test_regex('.23'));
var_dump(test_regex('.2'));
var_dump(test_regex('.'));
var_dump(test_regex('arglebargle'));
From that you can do whatever with the values that return 0.00, or test them in the function to make sure they're not alphabetic strings or whatever.

cka
May 3, 2004
Is "filter_var" good enough for input sanitizing? Some brazilian fucknut was trying to get into works' online store with injection exploits about a hour ago, and for whatever reason the software we use didn't seem to protect against passing quotes in the search field. I've since kind of gone overboard setting up input filtering on the search engine. This is my stop-gap solution right now:

php:
<?
$data['substring'] = str_replace("\0", "", $data['substring']);

if (function_exists('filter_var')) 
{
  $data['substring'] = filter_var($data['substring'], FILTER_SANITIZE_SPECIAL_CHARS);
} 
else 
{
  $data["substring"] = 
    mysql_real_escape_string(trim(htmlentities($data["substring"], ENT_QUOTES)));
}
?>
I can pass in quotes without it triggering SQL errors now, so that's good, but it would be nice to know if there was another simple way to do it. Why this software didn't filter input before I don't know...

edit: lol newline'd the mysql_real_escape_string part cause of table breakin'

Adbot
ADBOT LOVES YOU

cka
May 3, 2004
Anybody got any tricks for dealing with php uploads? I'm in the middle of rewriting a site/cms, and I'd really prefer not to have to deal with 777 directory permissions. This particular upload form isn't public and has some upload validation going on, but the more layers of security I can wrap it in, the better. I actually came up with a half-cocked idea for this issue last night (saving uploads to a temp dir outside the web root, then having a crontabbed script run every 5 or 10 minutes to move files to their intended directories [paths embedded in the filename] which should sidestep the directory owner/writing permission problems that will crop up when using a php script via http), but if anybody has any other ideas I'm all ears.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply