|
Treytor posted:Okay, now how would I display inline the amount of time remaining per IP? 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...
|
# ¿ Mar 25, 2008 08:23 |
|
|
# ¿ Apr 29, 2024 17:45 |
|
admiraldennis posted:Well then apparently your mind doesn't follow simple PEMDAS (and it really, really should if you're working with programming languages). 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 |
# ¿ Mar 25, 2008 09:14 |
|
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.)
|
# ¿ Aug 26, 2008 19:06 |
|
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"); ?>
|
# ¿ Sep 8, 2008 21:57 |
|
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.
|
# ¿ Oct 18, 2008 21:41 |
|
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.
|
# ¿ Oct 25, 2008 23:34 |
|
royallthefourth posted:That sounds like a great prank, but I'm sure someone's done it in a real application. 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.
|
# ¿ Nov 15, 2008 01:01 |
|
Probably this: http://us2.php.net/array_unique
|
# ¿ Feb 8, 2009 11:09 |
|
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"); ?> code:
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:
cka fucked around with this message at 02:08 on May 29, 2009 |
# ¿ May 28, 2009 22:28 |
|
Is this enabled in your php.ini file?code:
|
# ¿ Oct 7, 2009 00:18 |
|
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.
|
# ¿ Jan 27, 2010 01:57 |
|
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 } }
|
# ¿ Feb 20, 2010 14:48 |
|
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.)
|
# ¿ Mar 21, 2010 04:42 |
|
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&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>"; ?> 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.
|
# ¿ May 3, 2010 18:17 |
|
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 Thanks for the assistance though.
|
# ¿ May 3, 2010 23:49 |
|
Why regex? sprintf('%.2f', $value) should do exactly what you need it to do for this...code:
|
# ¿ Nov 3, 2010 00:13 |
|
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))); } ?> edit: lol newline'd the mysql_real_escape_string part cause of table breakin'
|
# ¿ Dec 1, 2010 23:42 |
|
|
# ¿ Apr 29, 2024 17:45 |
|
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.
|
# ¿ Jun 3, 2011 20:23 |