php-general Digest 27 Dec 2008 07:54:15 -0000 Issue 5867
Topics (messages 285073 through 285088):
Re: PHP (under httpd) reading a file outside DocumentRoot?
285073 by: Nathan Rixham
285074 by: Nathan Rixham
Online Members
285075 by: Stephen Alistoun
285084 by: Michael Kubler
Decorator with public methods
285076 by: Larry Garfield
285080 by: Nathan Nobbe
285086 by: Larry Garfield
Using MDB2 outside the PEAR framework?
285077 by: Murray
285078 by: Murray
285079 by: Mattias Thorslund
285081 by: Murray
Do defined variables exist at application scope, or session scope?
285082 by: Murray
285085 by: Larry Garfield
285088 by: Murray
uri/url help
285083 by: Kenton P. Kammer
285087 by: Robert Cummings
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
Jeff Weinberger wrote:
I don't know if this is an Apache (httpd) or a PHP issue (I suspect PHP,
but I may be doing something wrong with mod_suexec), so I hope this is
the right place to ask. I certainly appreciate any help anyone can offer!
I am trying to get a PHP script to read a file that's outside the
DocumentRoot of a VirtualHost, in fact well outside the parent directory
of all of my virtual hosts.
I have successfully managed to get Apache httpd to run the script as the
correct user and group (matching the target file's ownership) using
SuexecUserGroup. I tested this by having the script create/write a test
file, which had owner and group set correctly.
However, when I run the script, at the file("/path/to/target/file")
command, PHP tells me it can't open the file - permission is denied.
In php.ini safe_mode is off and open_basedir is not set.
I am not sure where else to look for a solution - any help is very much
appreciated!
FYI: PHP 5.2.6, Apache httpd 2.2.11, mod_ssl/2.2.11, OpenSSL/0.9.7l on
Mac OS/X 10.5.5. I'm reaching the script over an SSL (https) connection
if that matters).
Thanks!
do what it takes to make it work (ie chmod 777 or similar) then put
things back to how they presently are one by one to find the cause of
the error. :)
--- End Message ---
--- Begin Message ---
Jeff Weinberger wrote:
I don't know if this is an Apache (httpd) or a PHP issue (I suspect PHP,
but I may be doing something wrong with mod_suexec), so I hope this is
the right place to ask. I certainly appreciate any help anyone can offer!
I am trying to get a PHP script to read a file that's outside the
DocumentRoot of a VirtualHost, in fact well outside the parent directory
of all of my virtual hosts.
I have successfully managed to get Apache httpd to run the script as the
correct user and group (matching the target file's ownership) using
SuexecUserGroup. I tested this by having the script create/write a test
file, which had owner and group set correctly.
However, when I run the script, at the file("/path/to/target/file")
command, PHP tells me it can't open the file - permission is denied.
In php.ini safe_mode is off and open_basedir is not set.
I am not sure where else to look for a solution - any help is very much
appreciated!
FYI: PHP 5.2.6, Apache httpd 2.2.11, mod_ssl/2.2.11, OpenSSL/0.9.7l on
Mac OS/X 10.5.5. I'm reaching the script over an SSL (https) connection
if that matters).
Thanks!
do what it takes to make it work (ie chmod 777 or similar) then put
things back to how they presently are one by one to find the cause of
the error. :)
--- End Message ---
--- Begin Message ---
Hi all,
What is the best way to pick up all the members online on a website?
Regards,
Stephen
--
View this message in context:
http://www.nabble.com/Online-Members-tp21180855p21180855.html
Sent from the PHP - General mailing list archive at Nabble.com.
--- End Message ---
--- Begin Message ---
Some people will be happy with just a corny 1 liner, other's you'll need
to invite to dinner, and promise a romantic evening, and show how
masculine/feminine you are.
But I doubt you'll be able to get that many dates, unless it's a single
site most will probably already be in a relationship, or are simply not
interested.
Seriously though, I'm not quite sure what you mean by picking up all the
members online.
If you mean working out how many people are currently online, then you
can tail the log files, if you have HTTP auth, and manually work it out,
or the easier way (that likely keep a track of the last activity from a
user, and assume they are online if they have had any activity within
the last 30mins, assuming they haven't logged out.
Hope that helps a little, unless I've completely mis-interpreted the
question.
Michael Kubler
*G*rey *P*hoenix *P*roductions <http://www.greyphoenix.biz>
Stephen Alistoun wrote:
Hi all,
What is the best way to pick up all the members online on a website?
Regards,
Stephen
--- End Message ---
--- Begin Message ---
Excuse me a moment while I delve into complex OO. :-)
I have an object to which I want to add behavior (methods). I cannot use
inheritance here because the object is already of a type or subtype (vis, I am
already using inheritance for something else), and because I want to be able
to add multiple types of behavior at runtime. The normal OO response to this
situation is the Decorator pattern.
--------------------
interface F {
function doStuff();
}
class Foo {
function doStuff() { ... }
}
class Decorator implements F {
protected $foo;
function __construct(Foo $foo) {
$this->foo = $foo;
}
function doStuff() {
$this->foo->doStuff();
}
}
class Bar extends Decorator {
function doThings() { ... }
}
$f = new Foo();
$b = new Bar($f);
$b->doStuff();
$b->doThings();
--------------------
OK, great, that's wonderful. You can also nest such decorators indefinitely,
provided that they only override methods from Foo and change its behavior,
then pass on up the chain. Neat. What you cannot do, however, is nest
decorators that have public methods. That is:
--------------------
class Baz extends Decorator {
function doOtherThings();
}
$f = new Baz(new Bar(new Foo));
$f->doOtherThings(); // Works.
$f->doStuff(); // Works.
$f->doThings(); // Fail.
--------------------
Now, PHP does have a loophole around this problem in the form of __call().
Specifically, instead of Decorator wrapping each method of F/Foo directly it
implements __call():
--------------------
class Decorator {
protected $foo;
function __construct(Foo $foo) {
$this->foo = $foo;
}
function __call($method, $args) {
return call_user_func_array(array($this->foo, $method), $args);
}
}
--------------------
That should work and allow the code snippet above to run, but it has two
significant problems:
1) Because Decorator does not directly implement F, you cannot use type
hinting.
2) __call() and call_user_func_array() are both fairly slow operations, and
stacking them then becomes a nightmare for performance.
#1 can largely be solved by both directly implementing F *and* implementing
__call(), but we're still left with the performance problems of #2. While for
some uses cases that is OK, it can add up to unpleasant microseconds lost.
Can anyone suggest an alternate solution that has less of a performance hit?
--
Larry Garfield
[email protected]
--- End Message ---
--- Begin Message ---
On Fri, Dec 26, 2008 at 6:53 PM, Larry Garfield <[email protected]>wrote:
> Excuse me a moment while I delve into complex OO. :-)
>
> I have an object to which I want to add behavior (methods). I cannot use
> inheritance here because the object is already of a type or subtype (vis, I
> am
> already using inheritance for something else), and because I want to be
> able
> to add multiple types of behavior at runtime. The normal OO response to
> this
> situation is the Decorator pattern.
>
> --------------------
>
> interface F {
> function doStuff();
> }
>
> class Foo {
> function doStuff() { ... }
> }
>
> class Decorator implements F {
> protected $foo;
>
> function __construct(Foo $foo) {
> $this->foo = $foo;
> }
>
> function doStuff() {
> $this->foo->doStuff();
> }
> }
>
> class Bar extends Decorator {
> function doThings() { ... }
> }
>
> $f = new Foo();
>
> $b = new Bar($f);
> $b->doStuff();
> $b->doThings();
>
> --------------------
>
> OK, great, that's wonderful. You can also nest such decorators
> indefinitely,
> provided that they only override methods from Foo and change its behavior,
> then pass on up the chain. Neat. What you cannot do, however, is nest
> decorators that have public methods. That is:
>
> --------------------
>
> class Baz extends Decorator {
> function doOtherThings();
> }
>
> $f = new Baz(new Bar(new Foo));
> $f->doOtherThings(); // Works.
> $f->doStuff(); // Works.
> $f->doThings(); // Fail.
>
> --------------------
>
> Now, PHP does have a loophole around this problem in the form of __call().
> Specifically, instead of Decorator wrapping each method of F/Foo directly
> it
> implements __call():
>
> --------------------
> class Decorator {
> protected $foo;
>
> function __construct(Foo $foo) {
> $this->foo = $foo;
> }
>
> function __call($method, $args) {
> return call_user_func_array(array($this->foo, $method), $args);
> }
> }
> --------------------
>
> That should work and allow the code snippet above to run, but it has two
> significant problems:
>
> 1) Because Decorator does not directly implement F, you cannot use type
> hinting.
>
> 2) __call() and call_user_func_array() are both fairly slow operations, and
> stacking them then becomes a nightmare for performance.
>
> #1 can largely be solved by both directly implementing F *and* implementing
> __call(), but we're still left with the performance problems of #2. While
> for
> some uses cases that is OK, it can add up to unpleasant microseconds lost.
>
> Can anyone suggest an alternate solution that has less of a performance
> hit?
the main drawback to decoration vs inheritance is the fact that code is not
essentially 'written for you', which results in lots of boilerplate code in
decorators, in my experience. what that amounts to, is if you have 10
methods, whereby you only want to alter one of them in a decorator, then w/
decoration youve got 9 additional methods of crappy boilerplate code to
write, that you wouldnt have to when extending instead.
what is really irritating about the php __call() implementation is that
interfaces are not implemented by it. i think this is pretty silly (there
may be a solid reason the internals people could mention). what i mean is,
intuitively, i would expect
class A implements B {
public function __call() {}
}
to work, no matter what B declares. but it doesnt, WEAK, *cough* *cough*..
*sigh* sadly, i think the best solution is just to add bolierplate code in
your decorators, such that deocration methods explicitly implement the
interrface w/ each successive layer, and not incur the performance overhead
of __call(). essentially this is what the language would do for you when
extending something. i rarely put methods all on one line elsewhere, but
when decorating ill just end up doing something like this
/* these are here just to implement interface F */
function doStuff() { return $this->doStuff(); }
another alternative is to really buy into the whole 'dynamic' thing, and
forget about the interface, roll w/ __call() and take the performance hit,
which is more akin to something like youd see in javascript. personally i
like to use a medly of the two.
i never did much with it, but i suspect C++ templates make decoration nearly
as simple as inheritence, and avoid performace overhead of something like
__call(). which brings me to the third option, only really for the truely
brave php programmer. templating php w/ php; its often done in code
generation systems, like propel and other orm's, but basically, you'd have a
template w/ skeletons for all the methods and then youd have to run some
sort of generation script in order to create concreate classes for actual
use. esoteric, and perhaps a little ugly (editors dont really work 'right'
when templating php w/ php =/), but the technique is very powerful.
to summarize, using your example above, i would most liely add doThings() to
Baz, or create another decoration interface for doThings() if you plan on
using the Bar implementation of doThings() in many places,
interface G {
function doThings();
}
class Bar extends Decorator implements G {
function doThings() {
// concreate implementation
}
}
class Baz implements F, G {
// recycle Bar::doThings()
public function doThings() {
return $this->foo->doThings();
}
public function doOtherThings() {}
}
i appologize if this response is long winded, but im a big fan of the
decorator, and ive actually got some pretty slick code in production in the
photobucket code that uses the decorator pattern :D it took about 2 months
to code, and i leraned a lot about some of the practical aspects of
decroration, specifically within the realm of php. i know i repeated a few
things there, but i felt it neccessary to better explain myself.
-nathan
--- End Message ---
--- Begin Message ---
On Friday 26 December 2008 11:06:07 pm Nathan Nobbe wrote:
> to summarize, using your example above, i would most liely add doThings()
> to Baz, or create another decoration interface for doThings() if you plan
> on using the Bar implementation of doThings() in many places,
>
> interface G {
> function doThings();
> }
>
> class Bar extends Decorator implements G {
> function doThings() {
> // concreate implementation
> }
> }
>
> class Baz implements F, G {
> // recycle Bar::doThings()
> public function doThings() {
> return $this->foo->doThings();
> }
> public function doOtherThings() {}
> }
>
> i appologize if this response is long winded, but im a big fan of the
> decorator, and ive actually got some pretty slick code in production in the
> photobucket code that uses the decorator pattern :D it took about 2 months
> to code, and i leraned a lot about some of the practical aspects of
> decroration, specifically within the realm of php. i know i repeated a few
> things there, but i felt it neccessary to better explain myself.
>
> -nathan
Thanks, Nathan. Unfortunately, what you describe is impossible. It requires
me to know all the possible decorators ahead of time and implement the
interface for each in each decorator, at which point I've gotten no benefit at
all over just putting everything in the original base class in the first place.
That defeats the purpose of decorators if I can't come up with a new one a
month from now and not have to modify any of the existing code.
--
Larry Garfield
[email protected]
--- End Message ---
--- Begin Message ---
Hi All,
I'm wondering if it's possible or practical to implement MDB2 in my web
application, but without requiring a PEAR installation on the destination
server?
Essentially, I'd like to include MDB2 entirely within my web application, so
I can make use of db abstraction even on servers where PEAR isn't and can't
be installed.
Any suggestions?
Many thanks in advance,
M is for Murray
--- End Message ---
--- Begin Message ---
Hi John,
Well, this is the thing -- I suspect there are dependencies, particularly on
the core PEAR files themselves. I'm just wondering if someone else has done
this and if it's too difficult to make the effort worthwhile.
The Wordpress project, for example, I think rebuilt an abstraction layer in
the application. Since it uses a similar (or exact?) syntax as MDB2, I'd
always assumed they basically ported the MDB2 engine into the application,
rather than relying on PEAR and MDB2 as external dependencies.
Obviously there are good reasons for maintaining the PEAR libraries, since
these can be (relatively) easily updated to latest releases, but I for one
have previously helped out people who were hosted on sites that didn't allow
users to maintain PEAR libraries, and I'd like to remove that sort of
'compatibility' issue for my own project.
Thanks for your reply!
M is for Murray
On Sat, Dec 27, 2008 at 12:34 PM, <[email protected]> wrote:
> I guess you could just put MDB2.php and /MDB2 somewhere in your include
> path, right?
>
> If MDB2 has any dependencies, you'd need those too.
>
> I've never tried it, couldn't say whether they'd work outside of the PEAR
> installation/framework.
>
> John Corry
>
> On Dec 26, 2008 9:11pm, Murray <[email protected]> wrote:
> > Hi All,
> >
> >
> >
> > I'm wondering if it's possible or practical to implement MDB2 in my web
> >
> > application, but without requiring a PEAR installation on the destination
> >
> > server?
> >
> >
> >
> > Essentially, I'd like to include MDB2 entirely within my web application,
> so
> >
> > I can make use of db abstraction even on servers where PEAR isn't and
> can't
> >
> > be installed.
> >
> >
> >
> > Any suggestions?
> >
> >
> >
> > Many thanks in advance,
> >
> >
> >
> > M is for Murray
> >
--- End Message ---
--- Begin Message ---
As far as I recall, having done this, all that is required for a basic
MDB2 is the PEAR base class and the driver classes for the platforms you
want to support.
Murray wrote:
Hi All,
I'm wondering if it's possible or practical to implement MDB2 in my web
application, but without requiring a PEAR installation on the destination
server?
Essentially, I'd like to include MDB2 entirely within my web application, so
I can make use of db abstraction even on servers where PEAR isn't and can't
be installed.
Any suggestions?
Many thanks in advance,
M is for Murray
--- End Message ---
--- Begin Message ---
Thanks John and Mattias,
It looks like your advice has helped me achieve my goal.
Thanks again!
M is for Murray
On Sat, Dec 27, 2008 at 2:05 PM, Mattias Thorslund <[email protected]>wrote:
> As far as I recall, having done this, all that is required for a basic MDB2
> is the PEAR base class and the driver classes for the platforms you want to
> support.
>
>
>
> Murray wrote:
>
>> Hi All,
>>
>> I'm wondering if it's possible or practical to implement MDB2 in my web
>> application, but without requiring a PEAR installation on the destination
>> server?
>>
>> Essentially, I'd like to include MDB2 entirely within my web application,
>> so
>> I can make use of db abstraction even on servers where PEAR isn't and
>> can't
>> be installed.
>>
>> Any suggestions?
>>
>> Many thanks in advance,
>>
>> M is for Murray
>>
>>
>>
>
>
--- End Message ---
--- Begin Message ---
Hi All,
In the index.php file of my application I define several variables,
including such things as the base path of the app, and the theme path etc.
Since I use 'define()' to do this, are these variables available to my app
regardless of where a particular user enters the app?
So, in starting the app, I define these variables by visiting index.php. But
if another user gets sent a url to, for example, the help page, when they
visit it will those variables be available, or will I need to explicitly
check on each to make sure the variables are defined, because the user
entered at a different entry point than the 'normal' one?
Note: I will probably do an explicit check anyway, since this seems more
robust, but I ask to better understand how define works.
Many thanks,
M is for Murray
--- End Message ---
--- Begin Message ---
On Friday 26 December 2008 11:54:30 pm Murray wrote:
> Hi All,
>
> In the index.php file of my application I define several variables,
> including such things as the base path of the app, and the theme path etc.
>
> Since I use 'define()' to do this, are these variables available to my app
> regardless of where a particular user enters the app?
>
> So, in starting the app, I define these variables by visiting index.php.
> But if another user gets sent a url to, for example, the help page, when
> they visit it will those variables be available, or will I need to
> explicitly check on each to make sure the variables are defined, because
> the user entered at a different entry point than the 'normal' one?
>
> Note: I will probably do an explicit check anyway, since this seems more
> robust, but I ask to better understand how define works.
>
> Many thanks,
>
> M is for Murray
Well, there is no such thing as a "defined variable". You are, I presume,
talking about constants. (That's what you get from define().) A global
constant (vis, not a class constant) is "super-global", that is, available
absolutely everywhere after the line of code that defines it has executed.
So if the user goes to index.php, and the first line defines a constant
DEBUG_LEVEL, then that constant now exists anywhere in any function or method
for the rest of that page request, period.
However, if someone goes to help.php then the line in index.php is never
executed (why would it be, since the file was never included?), so the constant
is not defined.
Does that make sense?
--
Larry Garfield
[email protected]
--- End Message ---
--- Begin Message ---
Hi Larry,
You're absolutely right, I'm talking about constants rather than variables.
I guess in my very crude way, I'm trying to ask about the following:
UserA goes to the site via index.php, which defines several helpful
constants.
So do UserB through UserF.
UserG, however, first arrives at the site on help.php.
Because UserA, UserB, UserC etc have been to index.php, which has now been
executed, are the constants available with their values in help.php, even
though UserG, in particular, started in the application at this point?
So, another way of putting it, do these constants live for the life of the
application per se (ie, presumably until the server is restarted etc), or
will code in help.php be unable to access the values of defined constants
for this particular user because they were not at index.php first?
Many thanks for your reply,
M is for Murray
On Sat, Dec 27, 2008 at 5:00 PM, Larry Garfield <[email protected]>wrote:
> On Friday 26 December 2008 11:54:30 pm Murray wrote:
> > Hi All,
> >
> > In the index.php file of my application I define several variables,
> > including such things as the base path of the app, and the theme path
> etc.
> >
> > Since I use 'define()' to do this, are these variables available to my
> app
> > regardless of where a particular user enters the app?
> >
> > So, in starting the app, I define these variables by visiting index.php.
> > But if another user gets sent a url to, for example, the help page, when
> > they visit it will those variables be available, or will I need to
> > explicitly check on each to make sure the variables are defined, because
> > the user entered at a different entry point than the 'normal' one?
> >
> > Note: I will probably do an explicit check anyway, since this seems more
> > robust, but I ask to better understand how define works.
> >
> > Many thanks,
> >
> > M is for Murray
>
> Well, there is no such thing as a "defined variable". You are, I presume,
> talking about constants. (That's what you get from define().) A global
> constant (vis, not a class constant) is "super-global", that is, available
> absolutely everywhere after the line of code that defines it has executed.
>
> So if the user goes to index.php, and the first line defines a constant
> DEBUG_LEVEL, then that constant now exists anywhere in any function or
> method
> for the rest of that page request, period.
>
> However, if someone goes to help.php then the line in index.php is never
> executed (why would it be, since the file was never included?), so the
> constant
> is not defined.
>
> Does that make sense?
>
> --
> Larry Garfield
> [email protected]
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
I'm trying to make something to redirect people to my home page if they some
how access my include pages. For example, I have a generic copyright .htm with
links in it that I add to all my pages with the include(). Problem is when I'm
trying to make it the uri is always where it is in the include folder I made,
even when I'm on the home page trying to view the links. This is what I have:
<?
$uri=$_SERVER["REQUEST_URI"];
if($uri=='/'.strpbrk($uri, 'include')){header("Location: ../index.php");}
else{
?>
<p>page content</p>
<? } ?>
But the error is that since it always returns the /include/...htm uri even when
I'm viewing it on http://www.domain.com/index.php
Help please! Thank you!
_____________________________________________
Kenton P. Kammer
E1: [email protected]
E2: [email protected]
P: (309)677-1152
C: (708)309-1876
F: (708)263-4424
_____________________________________________
--- End Message ---
--- Begin Message ---
On Fri, 2008-12-26 at 22:02 -0800, Kenton P. Kammer wrote:
> I'm trying to make something to redirect people to my home page if they some
> how access my include pages. For example, I have a generic copyright .htm
> with links in it that I add to all my pages with the include(). Problem is
> when I'm trying to make it the uri is always where it is in the include
> folder I made, even when I'm on the home page trying to view the links. This
> is what I have:
>
> <?
> $uri=$_SERVER["REQUEST_URI"];
> if($uri=='/'.strpbrk($uri, 'include')){header("Location: ../index.php");}
> else{
> ?>
> <p>page content</p>
> <? } ?>
>
> But the error is that since it always returns the /include/...htm uri even
> when I'm viewing it on http://www.domain.com/index.php
>
> Help please! Thank you!
The most common way to do this (I think) is to define a variable in your
site's main config. In each include file test for it having been set. If
it is not set, then the file is being accessed improperly and so you
redirect.
For instance:
File: myConfig.php
------------------
<?php
define( 'MY_CONFIG_LOADED', 1 );
?>
File: myClass.php
-----------------
<?php
if( !defined( 'MY_CONFIG_LOADED' ) )
{
header( 'Location: http://www.foo.bar.nuh.uh.com/403.php' );
}
?>
On a related note though... they probably shouldn't be able to dig
around your include directory in the first place. Better to deny those
requests via a webserver config (usually a .htaccess file).
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
