Advanced search  

News:

cpg1.5.48 Security release - upgrade mandatory!
The Coppermine development team is releasing a security update for Coppermine in order to counter a recently discovered vulnerability. It is important that all users who run version cpg1.5.46 or older update to this latest version as soon as possible.
[more]

Pages: [1]   Go Down

Author Topic: SCRIPT_NAME vs. PHP_SELF in future releases (cgi problem)  (Read 3174 times)

0 Members and 1 Guest are viewing this topic.

ulikoeln

  • Coppermine newbie
  • Offline Offline
  • Posts: 10
SCRIPT_NAME vs. PHP_SELF in future releases (cgi problem)
« on: December 08, 2004, 01:15:05 pm »

Hi,

this is not a "function" type feature request ... mods feel free to move it
to a better place if necessary.

My suggestion would be to check the necessity of using "SCRIPT_NAME" in a few places
in the code and replace it with something that is more reliable. AFAIK, its currently used in
include/init.inc.php
functions.inc.php
db_ecard.php
themes/styleguide/theme.php
calendar.php
Unfortunately, many mods and hacks do it the same style.

There have been quite a number of reports about problems with this
setting, and most of the time the answer by other members or by
coppermine team members is "change line X from script_name to php_self".
In 1.3.2, it did work for me to change it to php_self in the files listed above,
but doing line-by-line hacks are not very elegant and is void after every upgrade.
Also, each additional mod has to be checked, too.

One of the big advantages (!) of coppermine is that it runs fine in
CGI-php / safe_mode environments like many webhosters have. This is great, please
leave it this way. In this environment, the script_name is often something like "/cgi-bin/php" or
"/path/to/some/wrapper/script".

There is already a config option for safe-mode problems, so why not do something
similar for the script_name problem. AFAIK, it is used mostly for constructing self-referential
URLs.  I think it would be easy to replace the explicit use of "script_name" with some
wrapper code in init.inc or some other central place where the proper URL or URL
part is detected and then either SCRIPT_NAME is overwritten or a different global variable
is set that can be used from there on.

What do you think?

Regards,
Ulrich

« Last Edit: December 08, 2004, 06:11:51 pm by GauGau »
Logged

Joachim Müller

  • Dev Team member
  • Coppermine addict
  • ****
  • Offline Offline
  • Gender: Male
  • Posts: 47844
  • aka "GauGau"
    • gaugau.de
Re: SCRIPT_NAME vs. PHP_SELF in future releases (cgi problem)
« Reply #1 on: December 08, 2004, 06:11:23 pm »

good point, will go on the todo-list.

Joachim
Logged
Pages: [1]   Go Up
 

Page created in 0.013 seconds with 19 queries.