-> PHP4 Singleton implementation question <-

Sanders Kaufman wrote:
> Jerry Stuckle wrote:
>
>> Sanders Kaufman wrote:
>
>
>>> It *resumes* a session?!
>>> If I put a bunch of values into session variables, how do I get those
>>> back with the resumed session... and how do I make sure I resumed the
>>> right session?
>>
>>
>> Just call session_start() on every page that uses sessions. PHP
>> ensures the correct session id is used again.
>
>
> So with this page:
>
> -----
> session_start();
> $_SESSION["MyVar"] = 123;
> ----
>
> When the user reloads, MyVar *will* equal 123?
> It's that simple?
>

It is if you have register_globals on - but that's a very bad thing to
have - a potential security risk.

What it will do is set $_SESSION('MyVar'] equal to 123. To get the
value out of the session on another page, just do:

session_start();
$MyVar = $_SESSION["MyVar"];

or, a better way (in case the user got to the second page without going
through the first one)

session_start();
$MyVar = isset($_SESSION['MyVar']) ? $_SESSION['MyVar'] : 0;

If $_SESSION['MyVar'] is set, the value in it will be placed in $MyVar.
But if $_SESSION['MyVar'] is not set, the code will set $MyVar to 0
(adjust the default value as you wish - even null is ok).

> When I was trying to learn about them, I ran into something to do with
> ob or ob_flush. Was I on a wrong tracK?
>
>

The problem with a session is you must start it before the headers are
sent to the browser. This will happen if there is *any* output sent,
even white space. So, for instance, if you have:

---top of file----

<?php
session_start();
?>

..... more of the file....

the session will fail because you sent output (a blank line) to the
browser. This caused the headers to be sent, and it's now too late to
start the session.

ob_start() buffers any output to the browser, so the headers aren't sent
right away. But IMHO this is a "quick and dirty" fix which just
bypasses the real problem. I think it's much better to structure code
properly so you issue the session_start() call at the beginning of your
page.

Others feel differently, but about the only time I use ob_start(), etc.,
is when I'm doing templating or similar, and need to parse the output
before sending it to the browser - i.e. substituting a persons name for
a [NAME] tag. But that's a little more advanced than we need to get
into right here.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jerry Stuckle wrote:
> Sanders Kaufman wrote:

> It is if you have register_globals on - but that's a very bad thing to
> have - a potential security risk.

Aha! I seem to remember that being part of why I made up my own session
logic. And it begs my next question:

What is the security risk attached to having register_globals turned on?


> $MyVar = isset($_SESSION['MyVar']) ? $_SESSION['MyVar'] : 0;


BONUS! Is that a way of saying "if myvar isn't set, set it to zero"?
I hope so because I've got a bunch of pages with the most convoluted
code just to handle that "unset vs. set to zero" issue.

> If $_SESSION['MyVar'] is set, the value in it will be placed in $MyVar.
> But if $_SESSION['MyVar'] is not set, the code will set $MyVar to 0
> (adjust the default value as you wish - even null is ok).

Cool. Thanks.
You just despaghetti'd a mess o' code.

ps. I tantrumed you as a troll about a month ago when an answer you
gave was a little too *personal*. I'm glad I rebuilt my system and lost
my filter.

Sanders Kaufman wrote:
> Jerry Stuckle wrote:
>
>> Sanders Kaufman wrote:
>
>
>> It is if you have register_globals on - but that's a very bad thing to
>> have - a potential security risk.
>
>
> Aha! I seem to remember that being part of why I made up my own session
> logic. And it begs my next question:
>
> What is the security risk attached to having register_globals turned on?
>

Well,among other things, a smart user could do something like:

http://www.example.com?authorized=1&level=admin

This could set the person as authorized, with admin level. Of course, a
simple example - but you get the idea. Even the PHP designers have
recommended against its use, and it will probably be removed in a future
release.

>
>> $MyVar = isset($_SESSION['MyVar']) ? $_SESSION['MyVar'] : 0;
>
>
>
> BONUS! Is that a way of saying "if myvar isn't set, set it to zero"?
> I hope so because I've got a bunch of pages with the most convoluted
> code just to handle that "unset vs. set to zero" issue.
>

Yep. I use something similar all the time.

>> If $_SESSION['MyVar'] is set, the value in it will be placed in
>> $MyVar. But if $_SESSION['MyVar'] is not set, the code will set
>> $MyVar to 0 (adjust the default value as you wish - even null is ok).
>
>
> Cool. Thanks.
> You just despaghetti'd a mess o' code.
>
> ps. I tantrumed you as a troll about a month ago when an answer you
> gave was a little too *personal*. I'm glad I rebuilt my system and lost
> my filter.
>
>

:-)

I do have a tendency to get rather pissed off at people who think they
know it all when they really have no clue. But after almost 40 years of
programming I get a little jaded :-)

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jerry Stuckle wrote:
> Sanders Kaufman wrote:

>> What is the security risk attached to having register_globals turned on?
>
> Well,among other things, a smart user could do something like:
>
> http://www.example.com?authorized=1&level=admin
>
> This could set the person as authorized, with admin level. Of course, a
> simple example - but you get the idea. Even the PHP designers have
> recommended against its use, and it will probably be removed in a future
> release.

It looks like you're saying that query string variables are
automatically made into $_SESSION variables - is that right?

If not - then the whole security issue is resolved by using $_GET and
$_POST correctly, right?


>>> $MyVar = isset($_SESSION['MyVar']) ? $_SESSION['MyVar'] : 0;


> I do have a tendency to get rather pissed off at people who think they
> know it all when they really have no clue. But after almost 40 years of
> programming I get a little jaded :-)

They say the toothless get ruthless. :)

Sanders Kaufman wrote:
> Jerry Stuckle wrote:
>
>> Sanders Kaufman wrote:
>
>
>>> What is the security risk attached to having register_globals turned on?
>>
>>
>> Well,among other things, a smart user could do something like:
>>
>> http://www.example.com?authorized=1&level=admin
>>
>> This could set the person as authorized, with admin level. Of course,
>> a simple example - but you get the idea. Even the PHP designers have
>> recommended against its use, and it will probably be removed in a
>> future release.
>
>
> It looks like you're saying that query string variables are
> automatically made into $_SESSION variables - is that right?
>

I'm saying that any variable ($_GET, $_POST or $_SESSION) with that
index can replace the variable, i.e. $MyVar could originate in
$_SESSION["MyVar"], but could also come from $_POST["MyVar"] or
$_GET["MyVar"]. And if you have multiple, the settings in your php.ini
file determines which takes precedence.

This can be very dangerous.

> If not - then the whole security issue is resolved by using $_GET and
> $_POST correctly, right?
>

Yes, you can use $_GET and $_POST (and $_SESSION). And if you leave
register_globals off, then you *must* use them. Less chance for error.

>
>>>> $MyVar = isset($_SESSION['MyVar']) ? $_SESSION['MyVar'] : 0;
>
>
>
>> I do have a tendency to get rather pissed off at people who think they
>> know it all when they really have no clue. But after almost 40 years
>> of programming I get a little jaded :-)
>
>
> They say the toothless get ruthless. :)


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jerry Stuckle wrote:
> Sanders Kaufman wrote:

>> If not - then the whole security issue is resolved by using $_GET and
>> $_POST correctly, right?
>
> Yes, you can use $_GET and $_POST (and $_SESSION). And if you leave
> register_globals off, then you *must* use them. Less chance for error.

So - as long as I explicitly reference $_SESSION[] when continuing a
session, I'm not subject to the security vulnerabilities of
register_globals, right?

One more thing - on the session token.
I notice that PHP puts it in the query string.
Is it possible to force that into a cookie?

I know this will mess with folks who turn cookies off, but I'm
accounting for that elsehow.

Jerry Stuckle wrote:

> I'm saying that any variable ($_GET, $_POST or $_SESSION) with that
> index can replace the variable, i.e.

Index, index, index.... hmmmm. Just a s a curiosity, can I reference
other sessions like so:

$x = $_SESSION[$sSessionToken]["MyVar"]

Sanders Kaufman wrote:
> Jerry Stuckle wrote:
>
>> Sanders Kaufman wrote:
>
>
>>> If not - then the whole security issue is resolved by using $_GET and
>>> $_POST correctly, right?
>>
>>
>> Yes, you can use $_GET and $_POST (and $_SESSION). And if you leave
>> register_globals off, then you *must* use them. Less chance for error.
>
>
> So - as long as I explicitly reference $_SESSION[] when continuing a
> session, I'm not subject to the security vulnerabilities of
> register_globals, right?
>

True - but ANY misstep can be disastrous. The problem is,

$i = $MyVar;

doesn't cause an error of $MyVar hasn't been explicitly assigned a value
in your code, but it is in the $_SESSION, $_POST, $_GET or $_COOKIES
(forgot the last one) array. That's very dangerous.

> One more thing - on the session token.
> I notice that PHP puts it in the query string.
> Is it possible to force that into a cookie?
>
> I know this will mess with folks who turn cookies off, but I'm
> accounting for that elsehow.

PHP can put it in a cookie if the user has cookies enabled. This is
controlled by the session.use_cookies and session.use_only_cookie in
your php.ini file.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Sanders Kaufman wrote:
> Jerry Stuckle wrote:
>
>> I'm saying that any variable ($_GET, $_POST or $_SESSION) with that
>> index can replace the variable, i.e.
>
>
> Index, index, index.... hmmmm. Just a s a curiosity, can I reference
> other sessions like so:
>
> $x = $_SESSION[$sSessionToken]["MyVar"]

No, you only have one session available.

Your example would access an array (index found in $sSessionToken) with
element 'MyVar'.

Sessions are particular to that site. Anything else would be a major
security breach. Additionally, the session info is kept on the server,
so even if you (theoretically) could access another site's session, the
data wouldn't be there.

As for accessing the info for another browser's session, you can't with
the default session handling. But you could put your own session
handler in there and do whatever you want - i.e. store the data in a
database. Then you could access data from other sessions on your
machine. But it's not recommended.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jerry Stuckle wrote:
> Sanders Kaufman wrote:

>> One more thing - on the session token.
>> I notice that PHP puts it in the query string.
>> Is it possible to force that into a cookie?
>>
>> I know this will mess with folks who turn cookies off, but I'm
>> accounting for that elsehow.
>
> PHP can put it in a cookie if the user has cookies enabled. This is
> controlled by the session.use_cookies and session.use_only_cookie in
> your php.ini file.

I would need my app to handle that gracefully. Is there a built-in
function to programatically determine which way it's set?