NEOHAPSIS - Peace of Mind Through Integrity and Insight

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com

Neohapsis > Archives > PHP Discussion Digest> 2003-06

php-general Digest 5 Jun 2003 01:49:46 -0000 Issue 2098

php-general-digest-helplists.php.net
Date: Wed Jun 04 2003 - 20:49:46 CDT

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

php-general Digest 5 Jun 2003 01:49:46 -0000 Issue 2098

Topics (messages 150155 through 150290):

Re: How to optimize this MySQL command?
        150155 by: PHP4 Emailer
        150157 by: Erick
        150177 by: James Lobley
        150190 by: Sunil Samuel

Is "gd" present?
        150156 by: Todd Cary
        150159 by: Erick
        150161 by: Esteban Fernandez
        150167 by: CPT John W. Holmes
        150179 by: Todd Cary
        150186 by: Esteban Fernandez
        150188 by: Esteban Fernandez
        150196 by: Armand Turpel
        150197 by: Svein Larsen
        150200 by: Esteban Fernandez

Re: Best open source banner advertising application
        150158 by: John Wards
        150166 by: Awlad Hussain
        150171 by: John Wards
        150174 by: Awlad Hussain
        150195 by: esctoday.com | wouter van vliet
        150202 by: John Wards
        150237 by: Manuel Lemos

Sessions and headers
        150160 by: Chris Boget
        150164 by: Ed Gorski
        150165 by: CPT John W. Holmes
        150173 by: Chris Boget
        150176 by: Ed Gorski
        150180 by: Chris Boget
        150181 by: Ed Gorski
        150182 by: Chris Boget

Using register_globals
        150162 by: Todd Cary
        150203 by: Bobby Patel
        150204 by: Jay Blanchard
        150206 by: Leif K-Brooks
        150207 by: Rasmus Lerdorf
        150208 by: Jay Blanchard
        150209 by: Rasmus Lerdorf
        150210 by: Rasmus Lerdorf
        150212 by: Armand Turpel
        150213 by: Leif K-Brooks
        150216 by: Jay Blanchard
        150220 by: Rouvas Stathis
        150222 by: Bobby Patel
        150227 by: Jason Wong
        150232 by: Wendell Brown
        150243 by: Armand Turpel
        150244 by: Philip Olson
        150250 by: Tony Crockford
        150254 by: Edward Peloke
        150259 by: Philip Olson
        150267 by: Lars Torben Wilson

Configuration values
150163 by: Hardik Doshi

Re: Gracefully dealing with Cookies OFF
        150168 by: Carl Furst
        150269 by: Monty
        150289 by: Justin French

unix time stamp to readable date
        150169 by: Diana Castillo
        150172 by: sven
        150192 by: Justin French

4.3.2 compile error on redhat 7.3, gcc 2.96
150170 by: Kent C. Kollasch

Re: setlocale() changes?
150175 by: Mike At Spy

Re: move_uploaded_file > 1MB
150178 by: Mauricio AGP5

Re: Multi Selection
150183 by: esctoday.com | wouter van vliet

file output, columns, etc...
        150184 by: Dan Joseph
        150185 by: CPT John W. Holmes
        150191 by: Dan Joseph

Best method to detect Apache, IIS, or CLI?
        150187 by: Jean-Pierre Arneodo
        150194 by: Chris Hayes
        150198 by: Esteban Fernandez

function re-defined | WorkAround? [and some more Q's]
150189 by: esctoday.com | wouter van vliet
150193 by: CPT John W. Holmes

Re: pagenting logic to cut short
150199 by: Haseeb Iqbal

multi-part upload fails in some php environments but not others
150201 by: Kendal
150215 by: Esteban Fernandez

Other error messages due to the migration
150205 by: Øystein Håland

Re: Compile 4.3.2 Errors.
150211 by: Kent C. Kollasch

Re: Imgs in Database
150214 by: Alexware
150217 by: Craig

Re: Using register_globals [ note on multi-developer en v ]
150218 by: Johnson, Kirk
150219 by: Jay Blanchard

Re: Error capturing
        150221 by: Jason Wong
        150223 by: Svein Larsen
        150225 by: Jason Wong
        150226 by: Svein Larsen
        150228 by: Jason Wong

Re: PHP and base32 encryption
150224 by: Hugh Bothwell

Migration once again
        150229 by: Øystein Håland
        150230 by: R'twick Niceorgaw
        150234 by: Øystein Håland
        150238 by: R'twick Niceorgaw
        150240 by: Øystein Håland
        150241 by: Dan Joseph
        150242 by: Dan Joseph
        150247 by: Øystein Håland
        150265 by: Lars Torben Wilson

new line question
150231 by: Meay Santiglia
150233 by: Dan Joseph

oasis banners - ot -
150235 by: Ryan A
150236 by: John S. Huggins

Browser detection script (css)
150239 by: Øystein Håland
150264 by: \[cz\]Emo

Evaluating defines
        150245 by: Yann Larrivee
        150256 by: Ernest E Vogelsinger
        150260 by: Yann Larrivee

HTML and PHP
        150246 by: Christian Ista
        150248 by: Edward Peloke
        150249 by: Esteban Fernandez

Calling HTML pages
        150251 by: Daniel J. Rychlik
        150253 by: Jay Blanchard
        150255 by: Esteban Fernandez
        150257 by: Esteban Fernandez
        150258 by: Edward Peloke
        150262 by: Lars Torben Wilson
        150266 by: Daniel J. Rychlik

Needing Just a Little Advice!
150252 by: sevenfiftyflat
150261 by: Evan Nemerson

New word proposition (was: Re: [PHP] HTML and PHP)
150263 by: Evan Nemerson
150268 by: Michael A Smith

RELEASE ANNOUNCEMENT phpDocumentor 1.2.0
150270 by: Greg Beaver

insert loop logic
        150271 by: Ryan A
        150272 by: Daniel J. Rychlik
        150274 by: Jennifer Goodie

SQL Select on a DATE field
150273 by: Lorenzo Ciani

Morph an object
        150275 by: Info.Best-IT
        150278 by: Lars Torben Wilson
        150283 by: Info.Best-IT

header function problem
150276 by: Daniel J. Rychlik
150277 by: Daniel J. Rychlik

MySQL Problem
150279 by: Felipe R.
150290 by: Oscar F

Text file breaking!
        150280 by: zavaboy
        150285 by: Bobby Patel
        150286 by: zavaboy

POST Variables get passed as GET variables.
150281 by: Michael A Smith
150284 by: Leif K-Brooks

(no) file creation by convert (ImageMagik)
150282 by: Bobby Patel

Re:RE: [PHP] Re: Using register_globals
150287 by: fongming

regex: line breaks to <br> w/exclusion
150288 by: Andrew Warner

Administrivia:

To subscribe to the digest, e-mail:
php-general-digest-subscribelists.php.net

To unsubscribe from the digest, e-mail:
php-general-digest-unsubscribelists.php.net

To post to the list, e-mail:
php-generallists.php.net

----------------------------------------------------------------------

attached mail follows:

YEAH, disregard my message, I was doing what James was doing but didn't see
that you where using ""2"" seperate tables already, sigh been a great
morning already. but there's my idea anyhow!! hehe
David :)

-----Original Message-----
From: James Lobley [mailto:jameswestcoast.co.uk]
Sent: Wednesday, June 04, 2003 8:22 AM
To: 'Erick'; php-generallists.php.net
Subject: RE: [PHP] How to optimize this MySQL command?
Importance: High

I'd guess at:

$resultb = mysql_query("SELECT bt_member.nick FROM bt_member, bt_message
WHERE bt_member.id=bt_message.mid AND bt_message.ch='$ch'", $db);
$result2 = mysql_fetch_array($resultb);
.........

-----Original Message-----
From: Erick [mailto:webmasterpczonehk.com]
Sent: 04 June 2003 13:12
To: php-generallists.php.net
Subject: [PHP] How to optimize this MySQL command?

$resultb = mysql_query("SELECT id,mid FROM bt_message where ch='$ch' ",$db);
while ($result = mysql_fetch_array($resultb)) {
$result2b = mysql_query("SELECT nick FROM bt_member where id ='$result[mid]'
",$db);
$result2 = mysql_fetch_array($result2b);
.........
}

Can combine together?

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

This email is only intended for the person(s) to whom it is addressed and
may contain confidential information. Unless stated to the contrary, any
opinions or comments are personal to the writer and do not represent the
official view of the company. If you have received this e-mail in error,
please notify us immediately by reply e-mail and then delete this message
from your system. Please do not copy it or use if for any purposes, or
disclose its contents to any other person.

We make every effort to keep our network free from viruses. You should
independently check this e-mail and any attachments for viruses, as we
can take no responsibility for any computer viruses that might be
transferred by way of this e-mail.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

attached mail follows:

So, how about this?

$resultb = mysql_query("SELECT id,title,mid,lastedit,hit,reply,`lock` FROM
bt_message where ch='$ch' ORDER BY top,lastedit DESC LIMIT $limit,30",$db);
while ($result = mysql_fetch_array($resultb)) {
$result2b = mysql_query("SELECT nick FROM bt_member where id
='$result[mid]'",$db);
$result2 = mysql_fetch_array($result2b);
mysql_free_result($result2b);
..........
}

"James Lobley" <jameswestcoast.co.uk>
???????:6DD748110EA1D411AD1200A0C996FDFA013CE66Fhost16.westcoast.co.uk...
> I'd guess at:
>
> $resultb = mysql_query("SELECT bt_member.nick FROM bt_member, bt_message
> WHERE bt_member.id=bt_message.mid AND bt_message.ch='$ch'", $db);
> $result2 = mysql_fetch_array($resultb);
> .........
>
>
> -----Original Message-----
> From: Erick [mailto:webmasterpczonehk.com]
> Sent: 04 June 2003 13:12
> To: php-generallists.php.net
> Subject: [PHP] How to optimize this MySQL command?
>
>
> $resultb = mysql_query("SELECT id,mid FROM bt_message where ch='$ch'
",$db);
> while ($result = mysql_fetch_array($resultb)) {
> $result2b = mysql_query("SELECT nick FROM bt_member where id
='$result[mid]'
> ",$db);
> $result2 = mysql_fetch_array($result2b);
> .........
> }
>
> Can combine together?
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> This email is only intended for the person(s) to whom it is addressed and
> may contain confidential information. Unless stated to the contrary, any
> opinions or comments are personal to the writer and do not represent the
> official view of the company. If you have received this e-mail in error,
> please notify us immediately by reply e-mail and then delete this message
> from your system. Please do not copy it or use if for any purposes, or
> disclose its contents to any other person.
>
> We make every effort to keep our network free from viruses. You should
> independently check this e-mail and any attachments for viruses, as we
> can take no responsibility for any computer viruses that might be
> transferred by way of this e-mail.
>
>

attached mail follows:

try this:

$resultb = mysql_query("SELECT bt_message.id, bt_message.title,
bt_message.mid,
bt_message.lastedit, bt_message.hit, bt_message.reply, bt_message.`lock`,
bt_member.nick
FROM bt_message, bt_member WHERE bt_member.id=bt_message.mid ch='$ch'
ORDER BY bt_message.top,bt_message.lastedit DESC LIMIT $limit,30",$db);
while ($result = mysql_fetch_array($resultb)) {
..........
}

If field names are explicit (ie, only in one table), you can get away
without specifying
the table name (as in "SELECT title, mid,...") but be carefull with that -
from your
original example, I see you have field 'id' in both tables...

I would suggest taking a look at the mysql manual at the select & join
sections...

James

-----Original Message-----
From: Erick [mailto:webmasterpczonehk.com]
Sent: 04 June 2003 14:45
To: php-generallists.php.net
Subject: Re: [PHP] How to optimize this MySQL command?

So, how about this?

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

attached mail follows:

This is actually more an sql questions. ;-) Take a look at Joins in
sql. Should be something like the following:

SELECT mesg.id, mesg.mid, memb.nick
FROM bt_message mesg, bt_member memb
WHERE mesg.ch='$ch' AND memb.id=mesg.mid

Erick wrote:

>$resultb = mysql_query("SELECT id,mid FROM bt_message where ch='$ch' ",$db);
>while ($result = mysql_fetch_array($resultb)) {
>$result2b = mysql_query("SELECT nick FROM bt_member where id ='$result[mid]'
>",$db);
>$result2 = mysql_fetch_array($result2b);
>.........
>}
>
>Can combine together?
>
>
>
>
>

attached mail follows:

Is there a way to check within an application if the "gd" library has
been installed?

Todd
--

attached mail follows:

just use phpinfo() ?

"Todd Cary" <toddaristesoftware.com>
???????:3EDDF7AD.5050706aristesoftware.com...
> Is there a way to check within an application if the "gd" library has
> been installed?
>
> Todd
> --
>

----------------------------------------------------------------------------
----

> Is there a way to check within an application if the "gd" library has been
installed?
>
> Todd
>
> --
>

attached mail follows:

<?php phpinfo(); ?>

"Todd Cary" <toddaristesoftware.com> escribió en el mensaje
news:3EDDF7AD.5050706aristesoftware.com...
> Is there a way to check within an application if the "gd" library has
> been installed?
>
> Todd
> --
>

----------------------------------------------------------------------------
----

> Is there a way to check within an application if the "gd" library has been
installed?
>
> Todd
>
> --
>

attached mail follows:

> Is there a way to check within an application if the "gd" library has
> been installed?

Maybe get_loaded_extensions() ????

---John Holmes...

attached mail follows:

Wouldn't I then have to scan the results? I use phpinfo() to checks the
client's installation, but I would like to do it within the app.

Todd

Esteban Fernandez wrote:

><?php phpinfo(); ?>
>
>"Todd Cary" <toddaristesoftware.com> escribió en el mensaje
>news:3EDDF7AD.5050706aristesoftware.com...
>
>
>>Is there a way to check within an application if the "gd" library has
>>been installed?
>>
>>Todd
>>--
>>
>>
>>
>
>
>----------------------------------------------------------------------------
>----
>
>
>
>
>>Is there a way to check within an application if the "gd" library has been
>>
>>
>installed?
>
>
>>Todd
>>
>>--
>>
>>
>>
>
>
>
>
>

attached mail follows:

I don't understand you, but i think u need some app to tell you, if GD is
installed or not ?, if is that what u need, then put this code.

<?php
ob_start();
phpinfo(8);
$phpinfo=ob_get_contents();
ob_end_clean();
$phpinfo=strip_tags($phpinfo);
if (stristr($phpinfo,"gd version")) {
echo "GD installed";
} else {
echo "GD NOT installed";
}
?>

Regards,
EF.

"Todd Cary" <toddaristesoftware.com> escribió en el mensaje
news:3EDE04DE.8030000aristesoftware.com...
> Wouldn't I then have to scan the results? I use phpinfo() to checks the
> client's installation, but I would like to do it within the app.
>
> Todd
>
> Esteban Fernandez wrote:
>
> ><?php phpinfo(); ?>
> >
> >"Todd Cary" <toddaristesoftware.com> escribió en el mensaje
> >news:3EDDF7AD.5050706aristesoftware.com...
> >
> >
> >>Is there a way to check within an application if the "gd" library has
> >>been installed?
> >>
> >>Todd
> >>--
> >>
> >>
> >>
> >
> >
>
>---------------------------------------------------------------------------
-
> >----
> >
> >
> >
> >
> >>Is there a way to check within an application if the "gd" library has
been
> >>
> >>
> >installed?
> >
> >
> >>Todd
> >>
> >>--
> >>
> >>
> >>
> >
> >
> >
> >
> >
>
> --
>
>

----------------------------------------------------------------------------
----

> Wouldn't I then have to scan the results? I use phpinfo() to checks the
client's installation, but I would like to do it within the app.
>
> Todd
>
> Esteban Fernandez wrote:
>
> <?php phpinfo(); ?>
>
> "Todd Cary" <toddaristesoftware.com> escribió en el mensaje
> news:3EDDF7AD.5050706aristesoftware.com...
> Is there a way to check within an application if the "gd" library has
> been installed?
>
> Todd
> --
>
>
>
> --------------------------------------------------------------------------
--
> ----
>
>
> Is there a way to check within an application if the "gd" library has
been
> installed?
> Todd
>
> --
>
>
>
>
>
>
> --
>
>

attached mail follows:

Also works... :)

<?php
$array = get_loaded_extensions();
for ($i=0;$i<=count($array);$i++) {
if ("gd" == $array[$i]) $installed = true;
else $installed = false;
}
if ($installed = true) echo "yeah... GD installed";
else echo "shit.. GD not installed.";
?>

Regards.
EF.

"Cpt John W. Holmes" <holmes072000charter.net> escribió en el mensaje
news:00bd01c32aa3$2840b130$a629089bTBHHCCDR...
> > Is there a way to check within an application if the "gd" library has
> > been installed?
>
> Maybe get_loaded_extensions() ????
>
> ---John Holmes...

attached mail follows:

This check if gd is installed and which version.

        if( $img = imageCreate(1, 1) )
        {
             // Check if GD version >= 2.0.1
             //
             $img = imageCreateTrueColor(1, 1);
             if (!$img)
             {
                 echo 'gd < 2.0.1 installed';
             }
             else
             {
                 echo 'gd >= 2.0.1 installed';
             }
         }
         else
         {
            echo 'No gd image tool available!';
         }

----- Original Message -----
From: "CPT John W. Holmes" <holmes072000charter.net>
To: "Todd Cary" <toddaristesoftware.com>; <php-generallists.php.net>
Sent: Wednesday, June 04, 2003 4:11 PM
Subject: Re: [PHP] Is "gd" present?

> > Is there a way to check within an application if the "gd" library has
> > been installed?
>
> Maybe get_loaded_extensions() ????
>
> ---John Holmes...
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>

attached mail follows:

$gd_loaded = (extension_loaded('gd'))?1:0;

Then you can use if ($gd_loaded) later in your code.

- Svein

> -----Original Message-----
> From: Esteban Fernandez [mailto:efernandeztecsol.cl]
> Sent: Wednesday, June 04, 2003 17:09
> To: php-generallists.php.net
> Subject: Re: [PHP] Is "gd" present?
>
>
> Also works... :)
>
> <?php
> $array = get_loaded_extensions();
> for ($i=0;$i<=count($array);$i++) {
> if ("gd" == $array[$i]) $installed = true;
> else $installed = false;
> }
> if ($installed = true) echo "yeah... GD installed";
> else echo "shit.. GD not installed.";
> ?>
>
> Regards.
> EF.
>
>
> "Cpt John W. Holmes" <holmes072000charter.net> escribió en
> el mensaje news:00bd01c32aa3$2840b130$a629089bTBHHCCDR...
> > > Is there a way to check within an application if the "gd" library
> > > has been installed?
> >
> > Maybe get_loaded_extensions() ????
> >
> > ---John Holmes...
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

attached mail follows:

Everyday i learn some new :)

"Svein Larsen" <sveincustompublish.com> escribió en el mensaje
news:002d01c32aad$1b7bc1b0$70a4a1d5custompue6s8p2...
$gd_loaded = (extension_loaded('gd'))?1:0;

Then you can use if ($gd_loaded) later in your code.

- Svein

attached mail follows:

On Wednesday 04 Jun 2003 2:41 pm, Randum Ian wrote:
> The best one without a shadow of a doubt would be phpnewads.

I would have to disagree on that one ;-)

http://oasis.sourceforge.net/

It wipes the floor with phpadsnew, I have used both.

But it can be a bit overkill if you are only a small site.

Cheers
John Wards
SportNetwork.net

attached mail follows:

John,
Since you have used both systems, would you kindly share with us whats pro &
cons of them both systems??
I have used phpadsnew and like their user interface.. very neat.. not much
sure about oasis.

Thanks

----- Original Message -----
From: "John Wards" <j.wardssportnetwork.net>
To: "Randum Ian" <ianrandumian.co.uk>; <adrianjustcompete.com>
Cc: <php-generallists.php.net>
Sent: Wednesday, June 04, 2003 2:50 PM
Subject: Re: [PHP] Best open source banner advertising application

> On Wednesday 04 Jun 2003 2:41 pm, Randum Ian wrote:
> > The best one without a shadow of a doubt would be phpnewads.
>
> I would have to disagree on that one ;-)
>
> http://oasis.sourceforge.net/
>
> It wipes the floor with phpadsnew, I have used both.
>
> But it can be a bit overkill if you are only a small site.
>
> Cheers
> John Wards
> SportNetwork.net
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

attached mail follows:

On Wednesday 04 Jun 2003 3:07 pm, Awlad Hussain wrote:
> Since you have used both systems, would you kindly share with us whats pro
> & cons of them both systems??
> I have used phpadsnew and like their user interface.. very neat.. not much
> sure about oasis.

oooh errr put on the sport...

Pros for PhpAdsNew:

Simple to install
Simpleish admin area.
Runs on anything that runs apache/php

Pros For Oasis

Very powerfull and intergrates great into our major website (which phpadsnew
didn't)
Fast as bits.
More features than phpadsnew (traffic shaping for one which is rather handy)
Pdf reports (Not sure if phpadsnew does that but I can't think of it.)
Can be set up to cluster so has the ablility to handle unlimited page views.
120+ page manual

Cons for Phpadsnew.

To simple...
Slows our system down due to the number of requests we were pushing to it. We
do 150-200 thousand page views a day but when running phpadsnew we had about
4 or 5 different advert loactions so it was producing about 1 million
requests a day for adverts.

Cons for Oasis.

Install not for the wary
Need root access
Has trouble with FreeBSD shared memory (Took our server down a few times so we
had to stop using it, we are now on linux and are busy installing it again)
120+ page manual

HTH

Cheers
John Wards
SportNetwork.net

attached mail follows:

Thanks John :)

----- Original Message -----
From: "John Wards" <j.wardssportnetwork.net>
To: "Awlad Hussain" <phpsheridan-phoenix.com>
Cc: <php-generallists.php.net>
Sent: Wednesday, June 04, 2003 3:25 PM
Subject: Re: [PHP] Best open source banner advertising application

> On Wednesday 04 Jun 2003 3:07 pm, Awlad Hussain wrote:
> > Since you have used both systems, would you kindly share with us whats
pro
> > & cons of them both systems??
> > I have used phpadsnew and like their user interface.. very neat.. not
much
> > sure about oasis.
>
> oooh errr put on the sport...
>
> Pros for PhpAdsNew:
>
> Simple to install
> Simpleish admin area.
> Runs on anything that runs apache/php
>
> Pros For Oasis
>
> Very powerfull and intergrates great into our major website (which
phpadsnew
> didn't)
> Fast as bits.
> More features than phpadsnew (traffic shaping for one which is rather
handy)
> Pdf reports (Not sure if phpadsnew does that but I can't think of it.)
> Can be set up to cluster so has the ablility to handle unlimited page
views.
> 120+ page manual
>
> Cons for Phpadsnew.
>
> To simple...
> Slows our system down due to the number of requests we were pushing to it.
We
> do 150-200 thousand page views a day but when running phpadsnew we had
about
> 4 or 5 different advert loactions so it was producing about 1 million
> requests a day for adverts.
>
> Cons for Oasis.
>
> Install not for the wary
> Need root access
> Has trouble with FreeBSD shared memory (Took our server down a few times
so we
> had to stop using it, we are now on linux and are busy installing it
again)
> 120+ page manual
>
> HTH
>
> Cheers
> John Wards
> SportNetwork.net
>

attached mail follows:

Does any of both (or any other) banner advertising applications support
langauge specific banners.. So that Greek visitors would get only the
banners you have said to be Greek? And for example maybe even if you don't
have any advertisements for Cyprus it would get the Greek ones
automatically?

(or am I asking too much now?)

-----Oorspronkelijk bericht-----
Van: Awlad Hussain [mailto:phpsheridan-phoenix.com]
Verzonden: woensdag 4 juni 2003 16:24
Aan: John Wards
CC: php-generallists.php.net
Onderwerp: Re: [PHP] Best open source banner advertising application

Thanks John :)

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

attached mail follows:

On Wednesday 04 Jun 2003 4:21 pm, esctoday.com | wouter van vliet wrote:
> Does any of both (or any other) banner advertising applications support
> langauge specific banners.. So that Greek visitors would get only the
> banners you have said to be Greek? And for example maybe even if you don't
> have any advertisements for Cyprus it would get the Greek ones
> automatically?
>
> (or am I asking too much now?)

Both have geocoding ablity but you have to pay for it in both cases.

Cheers
John

attached mail follows:

Hello,

On 06/04/2003 10:12 AM, Adrian Teasdale wrote:
> We are looking for an open source banner advertising application to
> integrate into a site. The site will be getting a LOT of hits, so something
> that will scale well, report well and just work well would be useful. Anyone
> got any thoughts on their preferred application? I'd be interested in
> speaking to people who have implemented something on a high traffic site

phpAdsNew.

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP
http://www.phpclasses.org/

attached mail follows:

When using PHP sessions, if the user's browser supports
cookies, PHP sets the session id as a cookie (so far as I
understand it). So when trying to use the session ID in a
script, a cookie request is sent to the browser to get the ID
and assigns it to the internal variable $PHPSESSID (again,
so far as I understand it).
My problem is this and I'm hoping someone has come up
with a workaround...
When I try to use the Header() function call (which I do alot
to set the content type such as PDF, doc, xl, etc), I'm getting
errors opening up the file due to previous headers already
having been sent - namely, the header call to get the cookie
value.
This problem prevents me from using sessions in scripts I
write to output and open up Word, Acrobat, Excel, etc. and
I am finding that to be an increasing problem as it requires
that I come up with a different way to access the session
data and open the script up to vulnerabilities.
I've tried using ob_start() and ob_end_clean() before and
after the session calls hoping that it might somehow solve
my problem but it doesn't.
Has anyone else come up against this problem? Have you
found a workaround other than come up with a different way
to do the same thing as code you already have and use to
access session data?

thnx,
Chris

attached mail follows:

Well you are partly right Chris. But the client automatically sends the
cookie with the HTTP request. IE your request for a cookie doesn't send a
separate request header to the client.

You might want to check to see if you are accidentally outputting something
else after you call session_start() (or before). I did something similar to
what you are describing. I have the user log on, the php creates a file and
prompts them to download. On the download page I check the session before I
output anything and it works fine for me. Can you paste a bit of the
non-functioning source code so that we can see the problem more clearly?

-----Original Message-----
From: Chris Boget [mailto:chriswild.net]
Sent: Wednesday, June 04, 2003 9:52 AM
To: PHP General
Subject: [PHP] Sessions and headers

thnx,
Chris

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

attached mail follows:

> When using PHP sessions, if the user's browser supports
> cookies, PHP sets the session id as a cookie (so far as I
> understand it). So when trying to use the session ID in a
> script, a cookie request is sent to the browser to get the ID
> and assigns it to the internal variable $PHPSESSID (again,
> so far as I understand it).
> My problem is this and I'm hoping someone has come up
> with a workaround...
> When I try to use the Header() function call (which I do alot
> to set the content type such as PDF, doc, xl, etc), I'm getting
> errors opening up the file due to previous headers already
> having been sent - namely, the header call to get the cookie
> value.

What errors, exactly? Can you show some examples?

I had problems like this with IE over SSL that was solved by changing the
session.cache_limiter. Does it work for other browsers at all or is it a PHP
error you're getting?

---John Holmes...

attached mail follows:

> What errors, exactly? Can you show some examples?

The errors are not PHP. They are from the browser trying to open the
data being sent from the server (the HTML or binary data) in the appropriate
program. eg, Acrobat for PDF, Word for DOC, Excel for XL.
For this particular case, I'm using the following header call:

header( "Content-Type: application/pdf" );

and I'm following it up with PDF binary data. As everyone well knows, this
will cause Acrobat to start up and the data displayed therein. Well, if any
headers are sent to the browser prior to the above header() call, the app
fails to load up and your browser gives you an error. In this case, the error
I am getting is as follows:

"Internet explorer cannot download YOURFILENAME
Internet Explorer was not able to open this Internet site. The requested
site is either unavailable or cannot be found. Please try again later."

The offending function call that causes all this grief is "session_start()".
When I comment out the call to session_start(), the PDF opens up just
fine. When I leave the function call in, I get the above error.
(And a quick note, I have trans-sid enabled)
Since you need session_start() to start or resume a session and since
that function call messes with any subsequent header() calls, I've not
been able to use sessions in scripts that output data to Word, Acrobat,
Excel, etc. and I need to do something about that.

> I had problems like this with IE over SSL that was solved by changing the
> session.cache_limiter. Does it work for other browsers at all or is it a PHP
> error you're getting?

It's a browser error I'm getting. And I get this problem on all browsers.

thnx,
Chris

attached mail follows:

Are you downloading these files over HTTPS://?

-----Original Message-----
From: Chris Boget [mailto:chriswild.net]
Sent: Wednesday, June 04, 2003 10:24 AM
To: CPT John W. Holmes; PHP General
Subject: Re: [PHP] Sessions and headers

> What errors, exactly? Can you show some examples?

header( "Content-Type: application/pdf" );

"Internet explorer cannot download YOURFILENAME
Internet Explorer was not able to open this Internet site. The requested
site is either unavailable or cannot be found. Please try again later."

It's a browser error I'm getting. And I get this problem on all browsers.

thnx,
Chris

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

attached mail follows:

> Are you downloading these files over HTTPS://?

Yes. But I just tried to force HTTP:// and that didn't
change anything.

thnx,
Chris

attached mail follows:

Try including "session_cache_limiter('public');" before your
session_start(); call at the top of the page.

-----Original Message-----
From: Chris Boget [mailto:chriswild.net]
Sent: Wednesday, June 04, 2003 10:40 AM
To: Ed Gorski; 'CPT John W. Holmes'; 'PHP General'
Subject: Re: [PHP] Sessions and headers

> Are you downloading these files over HTTPS://?

Yes. But I just tried to force HTTP:// and that didn't
change anything.

thnx,
Chris

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

attached mail follows:

> Try including "session_cache_limiter('public');" before your
> session_start(); call at the top of the page.

This is *exactly* what I needed!! It worked perfectly. Thank
you Ed, John very much for your feedback with this issue!

Chris

attached mail follows:

I have noticed that quite a few applications are designed with the
assumption that "register_globals = Yes"; in other words, the
application does not use $HTTP_xxx_VARS. In contrast, I always retrieve
my vars.

Is there a preference?

Todd
--

attached mail follows:

If it's a preference it's a bad one. Have register globals set to ON is one
way of leaving your script open to being exploitable. I would suggest that
if you really need to use that code then either modify it or write something
from scratch and use that code as a guide line.

search php.net for register globals and the warnings associated with it.

Bobby
"Todd Cary" <toddaristesoftware.com> wrote in message
news:3EDDF71B.4060907aristesoftware.com...
> I have noticed that quite a few applications are designed with the
> assumption that "register_globals = Yes"; in other words, the
> application does not use $HTTP_xxx_VARS. In contrast, I always retrieve
> my vars.
>
> Is there a preference?
>
> Todd
> --
>

----------------------------------------------------------------------------
----

> I have noticed that quite a few applications are designed with the
assumption that "register_globals = Yes"; in other words, the application
does not use $HTTP_xxx_VARS. In contrast, I always retrieve my vars.
>
> Is there a preference?
>
> Todd
>
> --
>
>

attached mail follows:

[snip]
Have register globals set to ON is one way of leaving your script open
to being exploitable.
[/snip]

Please explain this, how does it make it more exploitable? I think that
this is only true if the code is sloppy.

Thanks!
Jay

attached mail follows:

It's true that register_globals being on only makes sloppy code more
insecure. Most people aren't going to write perfect code, though. It's
incredibly annoying to have to unset every variable that shouldn't be
from an outside source. Even if you do so, it's very likely that you
will forget one variable on one page. It will, of course, be the
variable allowing admins to blow up a nuclear bomb over New York. :)

Jay Blanchard wrote:

>[snip]
>Have register globals set to ON is one way of leaving your script open
>to being exploitable.
>[/snip]
>
>Please explain this, how does it make it more exploitable? I think that
>this is only true if the code is sloppy.
>
>Thanks!
>Jay
>
>
>

--
The above message is encrypted with double rot13 encoding. Any unauthorized attempt to decrypt it will be prosecuted to the full extent of the law.

attached mail follows:

On Wed, 4 Jun 2003, Jay Blanchard wrote:
> [snip]
> Have register globals set to ON is one way of leaving your script open
> to being exploitable.
> [/snip]
>
> Please explain this, how does it make it more exploitable? I think that
> this is only true if the code is sloppy.

Correct, if you properly initialize your internal variables there is
nothing insecure about leaving register_globals on.

-Rasmus

attached mail follows:

[snip]
On Wed, 4 Jun 2003, Jay Blanchard wrote:
> [snip]
> Have register globals set to ON is one way of leaving your script open

> to being exploitable. [/snip]
>
> Please explain this, how does it make it more exploitable? I think
> that this is only true if the code is sloppy.

Correct, if you properly initialize your internal variables there is
nothing insecure about leaving register_globals on.
[/snip]

Then why has there been such a big deal about register_globals security?
Is it because so much code is sloppy?

Thanks!

Jay

attached mail follows:

On Wed, 4 Jun 2003, Leif K-Brooks wrote:
> It's true that register_globals being on only makes sloppy code more
> insecure. Most people aren't going to write perfect code, though. It's
> incredibly annoying to have to unset every variable that shouldn't be
> from an outside source. Even if you do so, it's very likely that you
> will forget one variable on one page. It will, of course, be the
> variable allowing admins to blow up a nuclear bomb over New York. :)

It's incredibly annoying to have to initialize your variables?

This would be an example:

  for($i=0;$i<10;$i++) {
    $str .= $i;
  }

Here, since you haven't initialized $str and you are appending to it,
someone can inject something into $str via GET or POST data. To fix it,
you have to make the code:

  $str = '';
  for($i=0;$i<10;$i++) {
    $str .= $i;
  }

Is that really what you find incredibly annoying? Even without
register_globals, you should be initializing your variables this way.
What if other parts of your code happened to use $str and left stuff in it
you didn't expect?

-Rasmus

attached mail follows:

On Wed, 4 Jun 2003, Jay Blanchard wrote:
> [snip]
> On Wed, 4 Jun 2003, Jay Blanchard wrote:
> > [snip]
> > Have register globals set to ON is one way of leaving your script open
>
> > to being exploitable. [/snip]
> >
> > Please explain this, how does it make it more exploitable? I think
> > that this is only true if the code is sloppy.
>
> Correct, if you properly initialize your internal variables there is
> nothing insecure about leaving register_globals on.
> [/snip]
>
> Then why has there been such a big deal about register_globals security?
> Is it because so much code is sloppy?

From a robustness perspective, it is not a bad idea to be more explicit
about where your user data is coming from and being able to easily
distinguish user-oriented data from internal data. What has been blown a
bit out of proportion is the idea that you cannot possibly write secure
code with register_globals on. That is of course completely false, but
you do have to be a little bit more careful which why the default was
changed to error on the side of safety.

-Rasmus

attached mail follows:

> On Wed, 4 Jun 2003, Jay Blanchard wrote:
> > [snip]
> > Have register globals set to ON is one way of leaving your script open
> > to being exploitable.
> > [/snip]
> >
> > Please explain this, how does it make it more exploitable? I think that
> > this is only true if the code is sloppy.
>
> Correct, if you properly initialize your internal variables there is
> nothing insecure about leaving register_globals on.

But how you know, if you have a few tausends of php code lines, which part
have some sloppy code. Nobody is perfect. In my opinion you should turn
register_globals to off if it's possible. It's much more secure.

>
> -Rasmus
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>

attached mail follows:

True, it's not incredibly annoying in all cases. It is in some cases,
however. For instance,

if(user_is_authorized){
$explodenuke = 1;
}
...
if(!empty($explodenuke)){
//Explode a nuke!
}

The only reason there to initialize $explodenuke would be for security
(register_globals), and there are other cases like this. I generally
initialize variables before using them, but there's always going to be a
time when someone forgets. That shouldn't present a security hazard,
which is why I think register_globals should *always* be off.

Rasmus Lerdorf wrote:

>On Wed, 4 Jun 2003, Leif K-Brooks wrote:
>
>
>>It's true that register_globals being on only makes sloppy code more
>>insecure. Most people aren't going to write perfect code, though. It's
>>incredibly annoying to have to unset every variable that shouldn't be
>>from an outside source. Even if you do so, it's very likely that you
>>will forget one variable on one page. It will, of course, be the
>>variable allowing admins to blow up a nuclear bomb over New York. :)
>>
>>
>
>It's incredibly annoying to have to initialize your variables?
>
>This would be an example:
>
> for($i=0;$i<10;$i++) {
> $str .= $i;
> }
>
>Here, since you haven't initialized $str and you are appending to it,
>someone can inject something into $str via GET or POST data. To fix it,
>you have to make the code:
>
> $str = '';
> for($i=0;$i<10;$i++) {
> $str .= $i;
> }
>
>Is that really what you find incredibly annoying? Even without
>register_globals, you should be initializing your variables this way.
>What if other parts of your code happened to use $str and left stuff in it
>you didn't expect?
>
>-Rasmus
>
>
>

--
The above message is encrypted with double rot13 encoding. Any unauthorized attempt to decrypt it will be prosecuted to the full extent of the law.

attached mail follows:

[snip]
The only reason there to initialize $explodenuke would be for security
(register_globals), and there are other cases like this. I generally
initialize variables before using them, but there's always going to be a

time when someone forgets. That shouldn't present a security hazard,
which is why I think register_globals should *always* be off.
[/snip]

In the corporate environment with multiple developers we have to
initialize every variable (it's a rule). We even scan code once a day
for variables that have not been declared. It's part of our
documentation.

Jay

attached mail follows:

Armand Turpel wrote:
>
> > On Wed, 4 Jun 2003, Jay Blanchard wrote:
> > > [snip]
> > > Have register globals set to ON is one way of leaving your script open
> > > to being exploitable.
> > > [/snip]
> > >
> > > Please explain this, how does it make it more exploitable? I think that
> > > this is only true if the code is sloppy.
> >
> > Correct, if you properly initialize your internal variables there is
> > nothing insecure about leaving register_globals on.
>
> But how you know, if you have a few tausends of php code lines, which part
> have some sloppy code. Nobody is perfect. In my opinion you should turn
> register_globals to off if it's possible. It's much more secure.

I strongly disagree with that.
Consider the following code (assuming $foo is 'external' variable):

1: if ($foo=='yes') transfer_money_to_me();

2: if ($_GET['foo']=='yes']) transfer_money_to_me();

Why (2) is safer than (1)? Answer: It is *not*.

As Rasmus has correctly pointed out, the usage of "register_globals=off"
per se cannot be considered a security measure. If you don't initialize
and/or check *all* user-supported variables, you're dead. It's as simple
as that. Is it annoying? Maybe. Is it necessary? *yes*

Anyway, IIRC the whole issue of register_globals started when some guy
presented a paper named "A Study in Scarlet". A whole lot of issues
where presented in that paper, which in my opinion, have been blown
quite out of perspective. register_globals is one of them.

Oh boy, this is starting to look like an urban myth : "-Hey do you know
that register_globals=on is bad? - Really? -Yeah, and you know what? It
allows the bad boys do eeeevil things".

-Stathis.

>
> >
> > -Rasmus
> >

attached mail follows:

I agree that you can write secure scripts with register_globals set to ON.

I usually think that alot of rookie PHP programmers (I just started PHP a
year ago, myself) read the list, and the way I figure is that it is good to
make readers of the list aware of the issues of register globals.

Plus, after coding in both states of register globals, I personally like
explictly referring to the assoc array $HTTP_xxx_VARS to retrieve the
variable. Coders are familiar with "magic numbers" and we should stay away
from that, but to me register_globals seems like "magic variables" I look at
this variable and I think to myself "Where did this variable come from?"
(but that's just me).

"Rasmus Lerdorf" <rasmuslerdorf.com> wrote in message
news:Pine.LNX.4.56.0306040936500.5965thinkpad.lerdorf.com...
> On Wed, 4 Jun 2003, Jay Blanchard wrote:
> > [snip]
> > On Wed, 4 Jun 2003, Jay Blanchard wrote:
> > > [snip]
> > > Have register globals set to ON is one way of leaving your script open
> >
> > > to being exploitable. [/snip]
> > >
> > > Please explain this, how does it make it more exploitable? I think
> > > that this is only true if the code is sloppy.
> >
> > Correct, if you properly initialize your internal variables there is
> > nothing insecure about leaving register_globals on.
> > [/snip]
> >
> > Then why has there been such a big deal about register_globals security?
> > Is it because so much code is sloppy?
>
> From a robustness perspective, it is not a bad idea to be more explicit
> about where your user data is coming from and being able to easily
> distinguish user-oriented data from internal data. What has been blown a
> bit out of proportion is the idea that you cannot possibly write secure
> code with register_globals on. That is of course completely false, but
> you do have to be a little bit more careful which why the default was
> changed to error on the side of safety.
>
> -Rasmus

attached mail follows:

On Thursday 05 June 2003 01:43, Rouvas Stathis wrote:

> I strongly disagree with that.
> Consider the following code (assuming $foo is 'external' variable):
>
> 1: if ($foo=='yes') transfer_money_to_me();
>
> 2: if ($_GET['foo']=='yes']) transfer_money_to_me();
>
> Why (2) is safer than (1)? Answer: It is *not*.

Consider this slightly more substantial example:

  // Case 1: register_globals = on
  if ($user == 'me' && $password == 'correct') {
    $admin = TRUE;
  }
  if ($admin) { list_all_members_sordid_details(); }

and

  // Case 2: register_globals = off
  if ($_GET['user'] == 'me' && $_GET['password'] == 'correct') {
    $admin = TRUE;
  }
  if ($admin) { list_all_members_sordid_details(); }

In case 1, a malicious person can bypass your password checks by passing
admin=1 in the URL.

> As Rasmus has correctly pointed out, the usage of "register_globals=off"
> per se cannot be considered a security measure. If you don't initialize
> and/or check *all* user-supported variables, you're dead. It's as simple
> as that. Is it annoying? Maybe. Is it necessary? *yes*

I tend to think of it as a safety net.

Of course the problems with case 1 could be prevented by explicitly
initialising the variables ...

  if ($user == 'me' && $password == 'correct') {
    $admin = TRUE; }
  else {
    $admin = FALSE;
  }

... and extra meticulous coding:

if ($admin === TRUE) { list_all_members_sordid_details(); }

Nobody's perfect, heck even MS cannot write safe code (!), so
register_globals=0 gives you a little extra breathing space.

--
Jason Wong -> Gremlins Associates -> www.gremlins.biz
Open Source Software Systems Integrators
* Web Design & Hosting * Internet & Intranet Applications Development *
------------------------------------------
Search the list archives before you post
http://marc.theaimsgroup.com/?l=php-general
------------------------------------------
/*
You can't judge a book by the way it wears its hair.
*/

attached mail follows:

On Thu, 5 Jun 2003 02:10:32 +0800, Jason Wong wrote:

>In case 1, a malicious person can bypass your password checks by passing
>admin=1 in the URL.

Actually, I set up a very similar user security system by taking
advantage of the $PHP_AUTH_USER variable.

I would check to see if the variable was set and if so, the user was an
"administrator" and could get to additional stuff. To get apache to
set the variable and pass it to me, I added a "login.php" and a
matching .htaccess mod to force login.php to require authentication.

It worked like a champ! Unfortunately, it also worked to add
"?PHP_AUTH_USER=1" to the calling script. A simple change to use
$_SERVER['PHP_AUTH_USER'] GREATLY enhanced the security!

Can it still be hacked? Probably. Is it more secure? Absolutely!

attached mail follows:

>> But how you know, if you have a few tausends of php code lines, which
part
>> have some sloppy code. Nobody is perfect. In my opinion you should turn
>> register_globals to off if it's possible. It's much more secure.

>Rouvas Stathis wrote:
>I strongly disagree with that.
>Consider the following code (assuming $foo is 'external' variable):

>1: if ($foo=='yes') transfer_money_to_me();

>2: if ($_GET['foo']=='yes']) transfer_money_to_me();

>Why (2) is safer than (1)? Answer: It is *not*.

As I wrote before, I dont talking about a 3 liner, but if some developers
work on a huge project. There is no reason why dont make use of the _GET[]
_POST[] ....... arrays and switch this register_globals to OFF

attached mail follows:

You guys should consider reading this:

http://www.php.net/manual/en/security.registerglobals.php

Most likely it's been updated since anyone here
read it, it covers everything discussed in this
thread.

Regards,
Philip

attached mail follows:

On this topic, could anyone point me to a good tutorial on how to
convert from sloppy code that assumes register_globals is on to good,
secure code that assumes register_globals is off.

something that covers what to look for and what to change it to would be
a great help.

I've been learning by working with someone else's (we bought it) code
and it won't run with register_globals off and I'd like it too.

it makes use of sessions (an area I'm still struggling with) and passes
a lot of variables from form to form, sometimes with post and sometimes
with get.

any suggestions would be much appreciated.

I looked at the manual and googled a lot, but can't find a plain english
guide to doing it right!

Thanks

Tony

attached mail follows:

unfortunately, it might just require someone starting at page 1, finding all
the forms and the variables they pass, then find the pages they pass the
variables to and changing them to the $HTTP_ method...may have to do it a
form at a time....

-----Original Message-----
From: Tony Crockford [mailto:tonycboldfish.co.uk]
Sent: Wednesday, June 04, 2003 4:13 PM
To: Php-GeneralLists. Php. Net
Subject: RE: [PHP] Re: Using register_globals

On this topic, could anyone point me to a good tutorial on how to
convert from sloppy code that assumes register_globals is on to good,
secure code that assumes register_globals is off.

something that covers what to look for and what to change it to would be
a great help.

I've been learning by working with someone else's (we bought it) code
and it won't run with register_globals off and I'd like it too.

it makes use of sessions (an area I'm still struggling with) and passes
a lot of variables from form to form, sometimes with post and sometimes
with get.

any suggestions would be much appreciated.

I looked at the manual and googled a lot, but can't find a plain english
guide to doing it right!

Thanks

Tony

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

attached mail follows:

This is pretty straight forward. First, you really should
know where your data comes from, only you know that:

  If it comes from GET, use $_GET
  If it comes from POST, use $_POST
  If it comes from COOKIE, use $_COOKIE
  If it comes from SERVER, use $_SERVER
  If it comes from ENV, use $_ENV
  If it comes from SESSION, use $_SESSION
  If it comes from FILES, use $_FILES

  If you could care less if it comes from
  GET, POST, or COOKIE and want to accept
  all three as one, use $_REQUEST

What's the question? So for example:

http://www.example.com/index.php?id=42
print $_GET['id'];

print $_SERVER['PHP_SELF']

  session_start();
  $_SESSION['somesessionvar'] = 'avalue';
  print $_SESSION['somesessionvar'];

setcookie('foo', 'bar');
print $_COOKIE['foo'];

...

Of course this doesn't make your script secure, but
you will know where the variable comes from. Related
manual pages are:

  http://us2.php.net/language.variables.predefined
  http://us2.php.net/language.variables.external
  http://us2.php.net/security.registerglobals

And before you blindly use this arrays inside strings, be
sure to know how to do that:

http://us2.php.net/language.types.string

And remember, users are evil.

Regards,
Philip

On Wed, 4 Jun 2003, Tony Crockford wrote:

> On this topic, could anyone point me to a good tutorial on how to
> convert from sloppy code that assumes register_globals is on to good,
> secure code that assumes register_globals is off.
>
> something that covers what to look for and what to change it to would be
> a great help.
>
> I've been learning by working with someone else's (we bought it) code
> and it won't run with register_globals off and I'd like it too.
>
> it makes use of sessions (an area I'm still struggling with) and passes
> a lot of variables from form to form, sometimes with post and sometimes
> with get.
>
> any suggestions would be much appreciated.
>
> I looked at the manual and googled a lot, but can't find a plain english
> guide to doing it right!
>
> Thanks
>
> Tony
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

attached mail follows:

On Wed, 2003-06-04 at 10:43, Rouvas Stathis wrote:
> Armand Turpel wrote:
> >
> > > On Wed, 4 Jun 2003, Jay Blanchard wrote:
> > > > [snip]
> > > > Have register globals set to ON is one way of leaving your script open
> > > > to being exploitable.
> > > > [/snip]
> > > >
> > > > Please explain this, how does it make it more exploitable? I think that
> > > > this is only true if the code is sloppy.
> > >
> > > Correct, if you properly initialize your internal variables there is
> > > nothing insecure about leaving register_globals on.
> >
> > But how you know, if you have a few tausends of php code lines, which part
> > have some sloppy code. Nobody is perfect. In my opinion you should turn
> > register_globals to off if it's possible. It's much more secure.
>
> I strongly disagree with that.
> Consider the following code (assuming $foo is 'external' variable):

I think his point had more to do with the fact that there is some
benefit to having register_globals = off in that everybody is going to
screw up sometime, and with register_globals = off at least you have
a bit more help when you do.

>From my point of view, this whole thing is being looked at the wrong
way 'round. The question shouldn't be "what is the advantage of
register_globals = off?", but "what is the advantage of
register_globals = on?" The answer, of course, is that there isn't any.
While the advantages of 'off' have been way overblown, at least there
are some. :)

Torben

> 1: if ($foo=='yes') transfer_money_to_me();
>
> 2: if ($_GET['foo']=='yes']) transfer_money_to_me();
>
> Why (2) is safer than (1)? Answer: It is *not*.
>
> As Rasmus has correctly pointed out, the usage of "register_globals=off"
> per se cannot be considered a security measure. If you don't initialize
> and/or check *all* user-supported variables, you're dead. It's as simple
> as that. Is it annoying? Maybe. Is it necessary? *yes*
>
> Anyway, IIRC the whole issue of register_globals started when some guy
> presented a paper named "A Study in Scarlet". A whole lot of issues
> where presented in that paper, which in my opinion, have been blown
> quite out of perspective. register_globals is one of them.
>
> Oh boy, this is starting to look like an urban myth : "-Hey do you know
> that register_globals=on is bad? - Really? -Yeah, and you know what? It
> allows the bad boys do eeeevil things".
>
> -Stathis.
>
> >
> > >
> > > -Rasmus
> > >

attached mail follows:

Hi Group,

I have a question regarding setting up configuration
values (environmental variables) for particular PHP
based web application. Currently i am doing it by
using DEFINE but is there any better way to do it?

Please let me know.

Thanks

Hardik Doshi

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

attached mail follows:

I think most people just put it in some sort of privacy policy I know
Harrypotterfanfiction.com says it outright that you have to be able to
accept not just their cookie but third party ones as well..Ouch..be sure to
run SpyBot after you visit them.

Vote.com has it in their privacy policy and explains how having cookies
turned off limits your enjoyment of the site, but doesn't require cookie
activation nor does use third party cookies, thank G-d..

Carl Furst

-----Original Message-----
From: Monty [mailto:monty3hotmail.com]
Sent: Wednesday, June 04, 2003 3:08 AM
To: php-generallists.php.net
Subject: [PHP] Gracefully dealing with Cookies OFF

I've decided to require that members for a site need to have cookies enabled
in their browsers to sign-up and use the site. Is there a graceful way to
deal with this when users who have cookies off try to sign-up or log-in to
the site?

Thanks,

Monty

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

attached mail follows:

Hi Justin,

I hear what you're saying about refusing people without cookies turned off,
and I really tried to make it work on my site, but, keep running into lots
of problems. I do have enable-trans-sid turned on, but, get inconsistent
results. For example, when someone logs out I return them to the log-in
page. Even though I've deleted all sessions vars and destroyed the session
before redirecting them, I noticed that the login page is full of PHPSESSID=
tags that are sometimes empty and sometimes filled with a session ID. This
happens whether or not I use session_start() at the beginning of my login
script. As a result, it totally screws up the log-in process. I was seeing
instances where it was appending two different PHPSESSIDs to the URL!

And then there are things like header redirects (which you had a good
solution for) and javascript popups. Those are ignored by enable-trans-sid,
so, it means I have to go through all my scripts (there are many) and tweak
them to pass the SID to every URL.

The reason I decided against doing all this tweaking was because while
researching this online, I read many statements by developers saying that
passing Session IDs via the URL is more of a security risk than allowing
this to be done via cookies. As the site I'm working on will be a pay
membership site, it seems like a good idea to require cookies.

I realize I may be turning people away, which would also be the case for
those using ancient browsers. But, I don't have the level of programming
expertise or resources of companies like Amazon and MSN who probably have
very robust security systems in place even though they are passing sessions
via the URL.

I do appreciate your comments and insight on this, it makes me keep
thinking: should I? could I? I'd be interested in hearing how others have
dealt with requiring users to have cookies turned on for sessions, or not.

Monty

> From: justinindent.com.au (Justin French)
> Newsgroups: php.general
> Date: Wed, 04 Jun 2003 19:23:11 +1100
> To: Monty <monty3hotmail.com>, <php-generallists.php.net>
> Subject: Re: [PHP] Gracefully dealing with Cookies OFF
>
> Why on earth would you refuse users without cookies?? Take a look at all
> the major websites (amazon & msn for starters).
>
> Do they require cookies? No.
> Do they require JavaScript? No.
> Do they require anything else special on the site? No.
>
> They take advantage of technology where available (DHTML and CSS for
> example), but the basic guts of the site can function without any of it, to
> the best of my knowledge.
>
> Instead, you choose to defy what every major site is doing, and require
> cookies.
>
> Cookies are not available to a wide number of users:
>
> - those in corporations where the IT dept. has disabled them
> - those accessing the 'net from any public computer:
> - libraries
> - airports
> - internet cafe's
> - those who choose to have a more secure, private web experience
> - those who don't understand the technology
>
>
> Doesn't make sense to me at all, but as long as you properly inform the
> client of your choice to ignore a large portion of users, then I guess it's
> your (and their) choice.
>
>
> PHP actually has a nice degradation of sessions built in. If you compile
> PHP with enable-trans-sid (compiled by default on PHP >= 4.3 I *think*), PHP
> will:
>
> 1. use cookies wherever possible, OR
>
> 2. rewrite* all relative URLs/links in your pages to include the session
> id, where cookies are not available
>
> * in practice, it doesn't handle javascript or other client side scripting
> that well from memory.
>
>
> Even with enable-trans-sid not compiled, you can manually append the session
> id to all your URLs with the pre defined constant SID.
>
>
> This is just my point of view, but I don't believe you have any excuse for
> not allowing non-cookie users to join in the fun, and CERTAINLY not without
> informing the client of your decision.
>
>
> To manually test for cookies, know that you're testing, then let the user
> know that you don't want their business/traffic is more work than just
> letting PHP handle it with enable-trans-sid.
>
>
> Justin French
>

attached mail follows:

on 05/06/03 8:05 AM, Monty (monty3hotmail.com) wrote:

> Hi Justin,
>
> I hear what you're saying about refusing people without cookies turned off,
> and I really tried to make it work on my site, but, keep running into lots
> of problems. I do have enable-trans-sid turned on, but, get inconsistent
> results. For example, when someone logs out I return them to the log-in
> page. Even though I've deleted all sessions vars and destroyed the session
> before redirecting them, I noticed that the login page is full of PHPSESSID=
> tags that are sometimes empty and sometimes filled with a session ID. This
> happens whether or not I use session_start() at the beginning of my login
> script. As a result, it totally screws up the log-in process. I was seeing
> instances where it was appending two different PHPSESSIDs to the URL!

I'd have to see your logout script and login script but here's what happens
(pretty much):

1. you request the first page with a session_start()

2. PHP doesn't know if you have cookies or not, so it appends the sid to all
URLs AND sets a cookie.

3. any internal link you click on this page will have the SID attached, so
it will appear in the URL of the second page you view.

4. the second page you view, PHP can see that there is a SID in the URL...
if it also finds a cookie, then it can stop rewriting the URLs... if it
can't find the cookie, then it keeps on rewriting URLs.

Make sense?

So, if your logout script kills the session, but your next page starts a new
session, i would expect to see SID's in some URLs around the logout/login
area, and I would expect the SID to change.

What you need to do is turn off cookies in your browser, and actually test
how this works in your app, preferably using very simple code (not your
large app) from the PHP site's samples. If it works, then why worry about
how????

If it doesn't work, post the code here, and we'll attempt to fix it.

> And then there are things like header redirects (which you had a good
> solution for) and javascript popups. Those are ignored by enable-trans-sid,
> so, it means I have to go through all my scripts (there are many) and tweak
> them to pass the SID to every URL.

well, for a smart application, you'd have them all in a couple of include
files or .js files, which you could easily search for things like
window.open to point you to problems.

or perhaps your definition of "degrade gracefully" may not include the SID
being available in pop-ups (is it needed???)

just to throw another spanner into it all, what happens if I have JS off?
will I still be able to access the content of the pop-ups? i bet not :)

perhaps now is the time to re-think all this stuff, decide if you are going
to support everyone (which i would for any paying client with a wide target
market), or skip over those who don't meet your definition of a web visitor.

me personally, I would not have mission-critical parts of the site rely on
cookies, javascript, or anything else client side, other than HTML with
simple CSS.

> The reason I decided against doing all this tweaking was because while
> researching this online, I read many statements by developers saying that
> passing Session IDs via the URL is more of a security risk than allowing
> this to be done via cookies. As the site I'm working on will be a pay
> membership site, it seems like a good idea to require cookies.

both the cookie and URL based session passed over without SSL is insecure.
i'd love to know who told you otherwise.

given that your site has paid membership, this reinforces the need for you
to reach as many paying customers as possible.

> I realize I may be turning people away, which would also be the case for
> those using ancient browsers. But, I don't have the level of programming
> expertise or resources of companies like Amazon and MSN who probably have
> very robust security systems in place even though they are passing sessions
> via the URL.

most of it has been done for you via PHP sessions... you just need to write
a small few-page site from scratch using simple, clean code (most of which
will be on php.net already) to learn what needs to be done, test test test,
then apply your new wealth of knowledge to your existing application.

or, turn them away -- i'm trying to tell you what should be done, i'm trying
to tell you that sessions via the URL is not the issue... perhaps it's a
simple coding mistake, or a lack of understanding of what happens, or
perhaps you just don't what to know :)

> I do appreciate your comments and insight on this, it makes me keep
> thinking: should I? could I? I'd be interested in hearing how others have
>