Posted by Sebastian Lisken on 01/18/08 05:10

Jerry Stuckle <jstucklex@attglobal.net> wrote:

[Having the session ID in SID even when cookies are used]
> Very simple. Some programmer comes along and sees there isn't anything
> in SID - and, not knowing any better, gets the session id and places it
> in there. Do you think you're the only one who well ever work on these
> scripts?

Ah - now at last you are beginning to explain. Thank you. All this time
I was asking about users messing things up, not other programmers. So
forgive me for not being able to make that connection with the very
terse responses you gave before this one.

So, hm, other programmers. Let me think. No - let me read the manual.

http://www.php.net/session
> SID (string)
> Constant containing either the session name and session ID in the
> form of "name=ID" or empty string if session ID was set in an
> appropriate session cookie.

So, it's a constant. The documentation makes it clear that it's a value
that programmers will want to read for informative purposes. Why should
they want to write to it instead and destroy that information?

Actually, the word "constant" should signify something more fundamental
to the open-minded reader. Could it be ...? Yes. SID is read-only. I've
just tried to assign a value to it in a script and got an error. No
surprise really - it doesn't start with a $ either.

Sorry, Jerry, I have seen other threads and realise that you are a
frequent and helpful advisor in this group, but with all due respect -
you are quite wrong in your judgement on SID, and you are in denial about
that. (I do share your argument about code bloat and maintainability, but
I've explained why I'm coming from the opposite direction on that one.)

[Also about SID being empty if cookies are used]
> Yep. But that doesn't mean you should increase your exposure. And if
> cookies are not active, PHP handles it for you, anyway.

Yes, I know PHP handles it for me. I've said so myself.

But I still don't see myself increasing my exposure.

[Passing on Session IDs in situations where cookies won't work]
> I say don't do it at all for important stuff - like private logins. If
> cookies aren't accepted, they can't use the site. For sites where it
> really doesn't matter if the session id is propagated or not, I let them
> use cookies or not.

Yes, that's a reasonable position - but nothing to do with the question
whether I'm using SID or not.

> But that's OK. It's your code. Your exposure. And your code that
> someone else will see at some point in time. If you don't care about
> any of that, it's no skin off my back.

> We tried to tell you. All you've done is argue. So have fun - but
> don't come crying to us when someone hacks your system.

I won't come crying, don't worry. And though it might seem so to you,
I'm honestly not a fan of using SID either. My only reasons for sticking
with it are the ones I've mentioned several times. I don't really want to
argue for it.

All I'm trying to do is achieve an informed debate, where both sides take
in what the other person is saying and, if necessary, explain what they
themselves are saying. Rather than find something to gut-react to and
then go ahead with that reaction. I've had such a hard time trying to
make several people see that this is not about putting the session ID
into URLs in situations where they wouldn't appear normally. And that
I see the risks of them showing up there just as much as you do. That
was quite frustrating. Maybe we are finally making some progress there.

Sebastian

[Back to original message]