Re: [PHP] Best practice question regarding set_include_path()
On Thu, May 10, 2012 at 1:50 PM, admin wrote: > > > -Original Message- > From: Al [mailto:n...@ridersite.org] > Sent: Thursday, May 10, 2012 11:44 AM > To: php-general@lists.php.net > Subject: [PHP] Best practice question regarding set_include_path() > > For my applications, I've been using includes and other file addressing by > using the doc root as the base dir. e.g. > require_once $_SERVER['DOCUMENT_ROOT'] . > '/miniRegDB/includes/miniRegDBconfig.php'; > > Recently, I ran into a problem with a new installation on a shared host > where the doc root was assigned in an unusual manner. I rather not require > setting a custom base dir [instead of $_SERVER['DOCUMENT_ROOT']'] for my > applications. > > So, I was wondering if it would be good practice to use the > set_include_path() and add the base dir for my applications. I've used this > for dealing with Pear function files on shared servers and had no problems. > > Need some guidance regarding this subject. > > Thanks > > -- > > I use define to set the application path > define('BASE_PATH','C:\\inetpub\\vhosts\\yourwebsite.com\\httpdocs\\'); > > Example: > require_once (BASE_PATH. '/miniRegDB/includes/miniRegDBconfig.php'); > > > works great for JQuery paths > > > $(document).ready(function() { > $('#dareport').html(' />'); > }); > > > To me it is much better than set_include_path() but works in the same > premise > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > I tend to use a slightly more portable version: define('APP_ROOT',dirname(__FILE__)); in a configuration file. (If the configuration file happens to be at a different depth than the main application file(s), I stack on more dirname's to get back to the application root.) Similarly, I usually need an application URL path. This can be trickier, depending on how you structure your application. This generally works for the applications I develop: define('APP_URL_BASE','http://'.$_SERVER['HOST_NAME'].dirname($_SERVER['SCRIPT_NAME'])); -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Best practice question regarding set_include_path()
-Original Message- From: Al [mailto:n...@ridersite.org] Sent: Thursday, May 10, 2012 11:44 AM To: php-general@lists.php.net Subject: [PHP] Best practice question regarding set_include_path() For my applications, I've been using includes and other file addressing by using the doc root as the base dir. e.g. require_once $_SERVER['DOCUMENT_ROOT'] . '/miniRegDB/includes/miniRegDBconfig.php'; Recently, I ran into a problem with a new installation on a shared host where the doc root was assigned in an unusual manner. I rather not require setting a custom base dir [instead of $_SERVER['DOCUMENT_ROOT']'] for my applications. So, I was wondering if it would be good practice to use the set_include_path() and add the base dir for my applications. I've used this for dealing with Pear function files on shared servers and had no problems. Need some guidance regarding this subject. Thanks -- I use define to set the application path define('BASE_PATH','C:\\inetpub\\vhosts\\yourwebsite.com\\httpdocs\\'); Example: require_once (BASE_PATH. '/miniRegDB/includes/miniRegDBconfig.php'); works great for JQuery paths $(document).ready(function() { $('#dareport').html(''); }); To me it is much better than set_include_path() but works in the same premise -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] best practice question..
Guy Bowden wrote: > On this note - what is considered "best practice" in a - sent to friend > type thing. > > i.e. User inputs their name + message + email + friends email into a > html/flash form > > friend gets a link to read the message. > > currently I do this: > > 1 collect form input > 2 create hash using the md5/uniqid method : $hash = md5(uniqid($key)); > 3 input data to database table using the hash as the primary key value > 4 send email to friend with link containing the hash > 5 user clicks on link > 6 hash read in from the $_GET object > 7 hash used to select message details from DB and displayed to the user > > There's never a security issue here - i.e. i don't mind how many times / > who reads the message, but just want to make it hard to just guess keys > to read other messages (otherwise it would just be the db id) > > This method works for me, but is it the *right* way? I would also: Track the sender IP address, and only allow N sends per time period T. Track the recipient email, and only allow M "To:"s per time period U. The point being to stop spammers from using your system to spam the world, or target specific victims. Is $key the ID in the database? You may want to consider adding in "more" randomness with mt_rand() as the manual suggests on the uniqid page -- You can still keep $key as part of the hash by doing: md5(uniqid("$key|" . mt_rand(), true)) Certainly sending the md5/uniquid as the only thing exposed is about as good as you can get for making sure that the other email URLs are guessable -- You do run the risk that sooner or later your md5/uniquid hash will "collide" with two emails on the same value. Easy enough to check the db and generate another hash if they do collide, so I'd add that in if you don't have it. Add a line after your md5(...) call and set $hash = '42' for testing purpose, then comment it out to go back to reality. You could look into the larger bits and longer hashes that would be "better" but I really don't think that's necessary, imho. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] best practice question..
Hello Guy, Thursday, December 9, 2004, 12:34:03 PM, you wrote: GB> There's never a security issue here - i.e. i don't mind how many times / GB> who reads the message, but just want to make it hard to just guess keys GB> to read other messages (otherwise it would just be the db id) GB> This method works for me, but is it the *right* way? There's no right or wrong way to do this - if it works for you, then it works :) The only thing I would strongly suggest is a check somewhere - if the recipient has been sent an email already (perhaps within the last 30 days?) then you don't send them another one. That way you're not open to being a spam bot. Best regards, Richard Davey -- http://www.launchcode.co.uk - PHP Development Services "I am not young enough to know everything." - Oscar Wilde -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Best practice question
> -Original Message- > From: Jon Haworth [mailto:[EMAIL PROTECTED]] > Sent: 19 September 2002 18:18 > > What are peoples' thoughts on "one should always return a value from a > function, even if it's always going to be true"? Unprintable!! There's no point in returning a value if there's no sensible value to return. Confusion can arise because PHP uses "function" for what, in some other languages, are distinguished into "functions" (which must return a value) and "subroutines" (which cannot). Anyone insisting that a function must return a result have probably been exposed only (or primarily) to such languages ;-Z !! Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning & Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Best practice question
Hi Adam, > > What are peoples' thoughts on "one should always return > > a value from a function, even if it's always going to be > > true"? > > > I'd say skip it if you know your never returning anything > different. Yeah, that's what I was leaning towards :-) What prompted the question was a constructor like this: class foo { var $timestamp; function foo () { $this->timestamp = mktime(); } } I just can't see any reason to return anything from it, unless someone wants to tell me otherwise... Cheers Jon -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Best practice question
One extra variable to be declared to catch the true (if you do try and catch it) and one extra line (the return line in the function), I'd say skip it if you know your never returning anything different. Adam Voigt [EMAIL PROTECTED] On Thu, 2002-09-19 at 13:17, Jon Haworth wrote: > Hi list, > > What are peoples' thoughts on "one should always return a value from a > function, even if it's always going to be true"? > > Cheers > Jon > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php