__SELF__?

[Chung Leong]

Re: __SELF__?

Alan Little wrote:[color=blue]
> A couple of examples:
>
> 1. Phorm plugins use it to ensure they're being called from Phorm.
> I encourage users to secure their plugins directory with .htaccess
> or equivalent for their server, but users don't always do as they're
> encouraged. The idea is to prevent
>
> http://www.example.com/phorm/plugins/someplugin.php[/color]

<?php include("my_usu al_rant_about_u sing_includes_a s_functions.php ");
?>

I don't really get why it's necessary to use PHP_SELF for this suppose.
Surely it's easier to do a define('IN_PHOR M', 1) and then check for
the presence of the constant. Even easier is to have all these plug-ins
of yours call a function within Phorm. If the script is accessed
directly, it automatically blows up.
[color=blue]
> 2. I have a homebrew template processor I use in all my applications.
> The calling script can, of course, specify the template, but if it
> doesn't, the default is (for example) example.html if called from
> example.php. Using $PHP_SELF works fine for me, but I've been thinking
> of making it generally available.[/color]

Still, you don't really need to know the actually URI. All you need is
the filename, which you can obtain reliably through debug_backtrace ().

Having an application "know where it is" tend to cause problems during
deployment. Recently I've had to proxy a few sites through Apache
mod_proxy and the presence of absolute URLs was a major headache.

[Alan Little]

Re: __SELF__?

Carved in mystic runes upon the very living rock, the last words of
Chung Leong of comp.lang.php make plain:
[color=blue]
> Alan Little wrote:[color=green]
>> A couple of examples:
>>
>> 1. Phorm plugins use it to ensure they're being called from Phorm.
>> I encourage users to secure their plugins directory with .htaccess
>> or equivalent for their server, but users don't always do as
>> they're encouraged. The idea is to prevent
>>
>> http://www.example.com/phorm/plugins/someplugin.php[/color]
>
> <?php include("my_usu al_rant_about_u sing_includes_a s_functions.php ");
> ?>[/color]

I'm not sure how this applies to plugins (then again, I'm not familiar
with your usual rant about using includes as functions :)
[color=blue]
> I don't really get why it's necessary to use PHP_SELF for this
> suppose. Surely it's easier to do a define('IN_PHOR M', 1) and then
> check for the presence of the constant. Even easier is to have all
> these plug-ins of yours call a function within Phorm. If the script is
> accessed directly, it automatically blows up.[/color]

I hadn't thought of those methods, both excellent. Thank you.
[color=blue][color=green]
>> 2. I have a homebrew template processor I use in all my applications.
>> The calling script can, of course, specify the template, but if it
>> doesn't, the default is (for example) example.html if called from
>> example.php. Using $PHP_SELF works fine for me, but I've been
>> thinking of making it generally available.[/color]
>
> Still, you don't really need to know the actually URI.[/color]

True -- see my other post from yesterday.
[color=blue]
> All you need is the filename, which you can obtain reliably through
> debug_backtrace ().[/color]

I wasn't aware of this function. Thanks again.

--
Alan Little
Phorm PHP Form Processor

http://www.phorm.com/

[Chung Leong]

Re: __SELF__?

Alan Little wrote:[color=blue]
> I'm not sure how this applies to plugins (then again, I'm not familiar
> with your usual rant about using includes as functions :)[/color]

As I understood it, your plugins are basically naked code sitting in
files that get included. That's why direct access through a web
address is a problem. If the code is wrapped in a function or in a
class, then you wouldn't have that problem, as nothing would happen
when PHP processes the file.

[Toby Inkster]

Re: __SELF__?

Chung Leong wrote:
[color=blue]
> Surely it's easier to do a define('IN_PHOR M', 1) and then check for
> the presence of the constant.[/color]

Better still:

define('PHORM_V ERSION', 2.001);

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[Alan Little]

Re: __SELF__?

Carved in mystic runes upon the very living rock, the last words of Chung
Leong of comp.lang.php make plain:
[color=blue]
> Alan Little wrote:[color=green]
>> I'm not sure how this applies to plugins (then again, I'm not familiar
>> with your usual rant about using includes as functions :)[/color]
>
> As I understood it, your plugins are basically naked code sitting in
> files that get included.[/color]

Correct.
[color=blue]
> That's why direct access through a web address is a problem. If the
> code is wrapped in a function or in a class, then you wouldn't have
> that problem, as nothing would happen when PHP processes the file.[/color]

OK. When you said, "using includes as functions", I took it to mean
having a bit of code that's called from various places in the main code,
and putting it in an included file, rather than a function. I once had a
date-selector generator that I did that with, but long ago converted it
to a function. I'm not trying to be a smart@$$, I just didn't see how
that applied to plugins.

But as far as wrapping the code in a function or class in order to
prevent it being executed directly, that's another way of doing it, but I
like the define() approach better; I just include the file and it's done,
rather than having to include it and then invoke the function.

--
Alan Little
Phorm PHP Form Processor

http://www.phorm.com/

[Chung Leong]

Re: __SELF__?

Alan Little wrote:[color=blue]
> OK. When you said, "using includes as functions", I took it to mean
> having a bit of code that's called from various places in the main code,
> and putting it in an included file, rather than a function. I once had a
> date-selector generator that I did that with, but long ago converted it
> to a function. I'm not trying to be a smart@$$, I just didn't see how
> that applied to plugins.[/color]

Whether the code is included once or many times is unimportant. The key
deficencies of includes are the lack of a clear interface and the lack
of variable scoping. For your plug-ins, how are the authors supposed to
know what variables are available? I mean their code would just inherit
the entire global scope. How do you prevent them from accidently
overwriting variables?

[Andy Jeffries]

Re: __SELF__?

On Thu, 11 May 2006 12:36:19 -0700, Chung Leong wrote:[color=blue][color=green]
>> Or PHP configured as a CLI binary (AFAIK $_SERVER is only available to
>> apache modules and ISAPI modules).[/color]
>
> I'm pretty sure that $_SERVER, along with $_GET, $_POST, and $_COOKIE are
> available in PHP-CLI. They're built fairly deep inside PHP. There's no
> easy way to rip them out. It's certainly not worth the effort, as you'll
> only end up breaking things.[/color]

Sorry, you're right, $_SERVER is available, what I meant was that I didn't
think $_SERVER[PHP_SELF] was available to CLI. Having actually tested it,
I'm pleased to say I'm wrong and it is indeed available to CLI PHP.
[color=blue]
> Only session and file support support are removed from CLI if I remember
> correctly.[/color]

Actually it creates session files in the current folder if you start a
session from a CLI script (made that mistake with an import script) and it
certainly does contain file support (same import script reads local files).

Cheers,


Andy

--
Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
http://www.gphpedit.or g | PHP editor for Gnome 2
http://www.andyjeffrie s.co.uk | Personal site and photos

[Alan Little]

Re: __SELF__?

Carved in mystic runes upon the very living rock, the last words of
Chung Leong of comp.lang.php make plain:
[color=blue]
> Alan Little wrote:[color=green]
>> OK. When you said, "using includes as functions", I took it to mean
>> having a bit of code that's called from various places in the main
>> code, and putting it in an included file, rather than a function. I
>> once had a date-selector generator that I did that with, but long ago
>> converted it to a function. I'm not trying to be a smart@$$, I just
>> didn't see how that applied to plugins.[/color]
>
> Whether the code is included once or many times is unimportant. The
> key deficencies of includes are the lack of a clear interface and the
> lack of variable scoping. For your plug-ins, how are the authors
> supposed to know what variables are available? I mean their code would
> just inherit the entire global scope. How do you prevent them from
> accidently overwriting variables?[/color]

Good points. So far I've been the only one to write plugins, so it hasn't
been a problem, and I've considered operating in the global scope a plus.

Of course, a lot of what we've discussed in this thread is moot, as far
as Phorm is concerned. The next release will be v4, which is a complete
re-build from the ground up, and is done as a class, so things are much
more encapsulated.

But you've certainly given me some things to think about. Thanks.

--
Alan Little
Phorm PHP Form Processor

http://www.phorm.com/