Sessions...

[Simon Dean]

And while Im at it... should I be using PHP's built in sessions, or use
my own functions that I've chobbled together from various sources and
takes advantage of also validating IP Addresses???

I don't like to use things just because they're there. Im currently
rewriting a web front end to a helpdesk. The old one was written in ASP
and very very poorly structured and programmed. Im blazing in with PHP
and unfortunately SQL Server and I've got about 50% of it done in about
2 days...

Of course, they won't let me build any extra bits in, and they're not
willing let me expand it into all singing all dancing despite me
volunteering my own time... grrr grrr grr...

Still there's the nagging doubt that Im probably not doing things right,
Sessions being one of them.... how to split templates out properly and
giving enough flexibility to enable Error Messages to be returned... etc...

Cya
Simon

[armando padilla]

Re: Sessions...

PHP session handling is excellent IMOP but thats just my take :-)

[Gordon Burditt]

Re: Sessions...

>And while Im at it... should I be using PHP's built in sessions, or use[color=blue]
>my own functions that I've chobbled together from various sources and
>takes advantage of also validating IP Addresses???[/color]

Using sessions does not prohibit you from also validating IP
addresses. Record the IP address in the session and compare it to
later ones. You should be aware that validating IP addresses can
make your site unusable for people using round-robin proxies, which
may make requests for parts of the same page appear to come from
several different IP addresses. Perhaps you don't care about this
(if it's a private web site for use from the office LAN, you very
well might not).
[color=blue]
>I don't like to use things just because they're there. Im currently[/color]

But if you spend all your time inventing a replacement for the
ASCII character set or HTML, you will never get much useful done.
[color=blue]
>rewriting a web front end to a helpdesk. The old one was written in ASP
>and very very poorly structured and programmed. Im blazing in with PHP
>and unfortunately SQL Server and I've got about 50% of it done in about
>2 days...[/color]
[color=blue]
>Of course, they won't let me build any extra bits in, and they're not
>willing let me expand it into all singing all dancing despite me
>volunteering my own time... grrr grrr grr...[/color]
[color=blue]
>Still there's the nagging doubt that Im probably not doing things right,
>Sessions being one of them.... how to split templates out properly and
>giving enough flexibility to enable Error Messages to be returned... etc...[/color]

Gordon L. Burditt

[John]

Re: Sessions...

Simon Dean wrote:[color=blue]
> And while Im at it... should I be using PHP's built in sessions, or use
> my own functions that I've chobbled together from various sources and
> takes advantage of also validating IP Addresses???[/color]
[color=blue]
> I don't like to use things just because they're there.[/color]

I know what you mean, but if it's there and it's working well, then use it.

PHP sessions do work very well - except for one problem I found.

MS IE kept using a different session ID for every page it requested !

I solved this by creating my own session ID and storing it in a cookie,
so I could get it back and force the same session ID each time.

Of course, now you need the user to have cookies enabled.

So I now use session data for 'this visit' stuff, and cookie data for
longer term 'user info' stuff.

Let me know if you want any code...

John.

[Simon Dean]

Re: Sessions...

John wrote:[color=blue]
> Simon Dean wrote:
>[color=green]
>> And while Im at it... should I be using PHP's built in sessions, or
>> use my own functions that I've chobbled together from various
>> sources and takes advantage of also validating IP Addresses???[/color]
>
>[color=green]
>> I don't like to use things just because they're there.[/color]
>
>
> I know what you mean, but if it's there and it's working well, then
> use it.
>
> PHP sessions do work very well - except for one problem I found.
>
> MS IE kept using a different session ID for every page it requested !
>
>
> I solved this by creating my own session ID and storing it in a
> cookie, so I could get it back and force the same session ID each
> time.[/color]

Hrm... apart from setting a cookie and hoping (since you can't rely on
PHP sessions), what you do isn't too different from what I do... I just
pass a session id either in a cookie, or on the url, and verify it's
still active with the right ip address...

which brings me I think onto my next question... another poster said
tcpip addresses are unreliable in some circumstances, so what else can
you use to verify that someone else hasn't stolen someone elses
sessionid and is using that account?


Thanks
Simon

[Jerry Stuckle]

Re: Sessions...

Simon Dean wrote:[color=blue]
> John wrote:
>[color=green]
>> Simon Dean wrote:
>>[color=darkred]
>>> And while Im at it... should I be using PHP's built in sessions, or
>>> use my own functions that I've chobbled together from various
>>> sources and takes advantage of also validating IP Addresses???[/color]
>>
>>
>>[color=darkred]
>>> I don't like to use things just because they're there.[/color]
>>
>>
>>
>> I know what you mean, but if it's there and it's working well, then
>> use it.
>>
>> PHP sessions do work very well - except for one problem I found.
>>
>> MS IE kept using a different session ID for every page it requested !
>>
>>
>> I solved this by creating my own session ID and storing it in a
>> cookie, so I could get it back and force the same session ID each
>> time.[/color]
>
>
> Hrm... apart from setting a cookie and hoping (since you can't rely on
> PHP sessions), what you do isn't too different from what I do... I just
> pass a session id either in a cookie, or on the url, and verify it's
> still active with the right ip address...
>
> which brings me I think onto my next question... another poster said
> tcpip addresses are unreliable in some circumstances, so what else can
> you use to verify that someone else hasn't stolen someone elses
> sessionid and is using that account?
>
>
> Thanks
> Simon[/color]

Simon,

You really can't.

The other person is right - IP addresses are not reliable. Some ISP's
(especially AOL), corporate networks, etc. are set up with redundant
proxies. Every incoming request can potentially come from a redundant
proxy. And the IP address you see will be that of the proxy, not the
original requester.


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

[John]

Re: Sessions...

Simon Dean wrote:[color=blue]
> John wrote:
>[color=green]
>> Simon Dean wrote:
>>[color=darkred]
>>> And while Im at it... should I be using PHP's built in sessions, or
>>> use my own functions that I've chobbled together from various
>>> sources and takes advantage of also validating IP Addresses???[/color]
>>
>>
>>[color=darkred]
>>> I don't like to use things just because they're there.[/color]
>>
>>
>>
>> I know what you mean, but if it's there and it's working well, then
>> use it.
>>
>> PHP sessions do work very well - except for one problem I found.
>>
>> MS IE kept using a different session ID for every page it requested !
>>
>>
>> I solved this by creating my own session ID and storing it in a
>> cookie, so I could get it back and force the same session ID each
>> time.[/color]
>
>
> Hrm... apart from setting a cookie and hoping (since you can't rely on
> PHP sessions), what you do isn't too different from what I do... I just
> pass a session id either in a cookie, or on the url, and verify it's
> still active with the right ip address...
>
> which brings me I think onto my next question... another poster said
> tcpip addresses are unreliable in some circumstances, so what else can
> you use to verify that someone else hasn't stolen someone elses
> sessionid and is using that account?[/color]

A good question - I'm may be getting out of my depth here, but this is
what I understand:

1) if you used PHP sessions (and their own ID's) natively, it would take
care of all that for you, but then you may run into the MS IE problem.

2) as I set my own session ID, I rely on generating a unique ID through
mt_rand() and a time() combination. I must admit, I do no more checking
on it, so it could happen that 2 people get the same ID - I'm just
relying on it being a very small probability...

I'm going to look into using the original PHP generated session ID, but
keep it in my own cookie !


Are you looking for a VERY secure method for doing something ? If so,
maybe you should be looking at something else, a secure server page ?
HTTPS ?

John.

[Sean]

Re: Sessions...

You can't rely on cookies either, you will need to factor in when
people have cookies disabled, which will be in allot of cases.

I tired building something similar matching on ip addresses, basically
it didn't work in all cases. It can be useful though e.g. what I like
to do is set up a dark area on a website that I setup, that nobody
should no about and set up a feature so that if anyone tries to access
that section of the site I assume they are up to no good, log their ip
address and put it on a black list.

If you know the user base of the site I would recommend password
protected client certificates, with a user name and password to log in.

[John]

Re: Sessions...

Simon,

FYI, some behaviour I just observed :-

When you open/start a second browser (a fresh one):

Linux/Mozila - uses same session ID as first browser,

W2K/IE - generates a new session ID.
But if you 'open a new window' from the browser, then the new
window has the same session ID.

John.

[Simon Dean]

Re: Sessions...

John wrote:[color=blue]
> Simon Dean wrote:
>[color=green]
>> John wrote:
>>[color=darkred]
>>> Simon Dean wrote:
>>>
>>>> And while Im at it... should I be using PHP's built in sessions, or
>>>> use my own functions that I've chobbled together from various
>>>> sources and takes advantage of also validating IP Addresses???
>>>
>>>
>>>
>>>
>>>> I don't like to use things just because they're there.
>>>
>>>
>>>
>>>
>>> I know what you mean, but if it's there and it's working well, then
>>> use it.
>>>
>>> PHP sessions do work very well - except for one problem I found.
>>>
>>> MS IE kept using a different session ID for every page it requested !
>>>
>>>
>>> I solved this by creating my own session ID and storing it in a
>>> cookie, so I could get it back and force the same session ID each
>>> time.[/color]
>>
>>
>>
>> Hrm... apart from setting a cookie and hoping (since you can't rely on
>> PHP sessions), what you do isn't too different from what I do... I
>> just pass a session id either in a cookie, or on the url, and verify
>> it's still active with the right ip address...
>>
>> which brings me I think onto my next question... another poster said
>> tcpip addresses are unreliable in some circumstances, so what else can
>> you use to verify that someone else hasn't stolen someone elses
>> sessionid and is using that account?[/color]
>
>
> A good question - I'm may be getting out of my depth here, but this is
> what I understand:
>
> 1) if you used PHP sessions (and their own ID's) natively, it would take
> care of all that for you, but then you may run into the MS IE problem.
>
> 2) as I set my own session ID, I rely on generating a unique ID through
> mt_rand() and a time() combination. I must admit, I do no more checking
> on it, so it could happen that 2 people get the same ID - I'm just
> relying on it being a very small probability...
>
> I'm going to look into using the original PHP generated session ID, but
> keep it in my own cookie !
>
>
> Are you looking for a VERY secure method for doing something ? If so,
> maybe you should be looking at something else, a secure server page ?
> HTTPS ?
>
> John.
>[/color]

Oh no, no, far from it. Just reusing my session id algorithms that I
created for my celebrity website and reuse it for the new work helpdesk
system.

Interesting note about the redundant proxies. That might explain why
I've had a couple of AOL users complaining to me...

Cya
Simon

[Gordon Burditt]

Re: Sessions...

>>> And while Im at it... should I be using PHP's built in sessions, or[color=blue][color=green][color=darkred]
>>> use my own functions that I've chobbled together from various
>>> sources and takes advantage of also validating IP Addresses???[/color]
>>
>>[color=darkred]
>>> I don't like to use things just because they're there.[/color]
>>
>>
>> I know what you mean, but if it's there and it's working well, then
>> use it.
>>
>> PHP sessions do work very well - except for one problem I found.
>>
>> MS IE kept using a different session ID for every page it requested !
>>
>>
>> I solved this by creating my own session ID and storing it in a
>> cookie, so I could get it back and force the same session ID each
>> time.[/color][/color]

I have to wonder WHY this would fix the problem. What is better
about YOU creating the session ID and storing it in a cookie vs.
PHP creating a session ID and storing it in a cookie? Perhaps
someone is blocking the cookie 'PHPSESSID' and leaving others alone?
[color=blue]
>Hrm... apart from setting a cookie and hoping (since you can't rely on
>PHP sessions), what you do isn't too different from what I do... I just
>pass a session id either in a cookie, or on the url, and verify it's
>still active with the right ip address...
>
>which brings me I think onto my next question... another poster said
>tcpip addresses are unreliable in some circumstances, so what else can
>you use to verify that someone else hasn't stolen someone elses
>sessionid and is using that account?[/color]

You CAN'T verify it as far as people are concerned. It is quite
possible for the user to get bonked on the head and someone else
continues his session for him. Governments do this occasionally,
and sometimes design the raids so they can do this to gather evidence.
There's also the "unattended computer" problem and the "shared
family computer" problem.

If you define "session" as "a period of time during which the user
sits down at a computer and uses your site", the main problem with
FALSE triggering of IP checks is round-robin proxies. Different
parts of the same page, or several successive pages, may appear to
be from different IPs. On the other hand, your test WON'T trigger
when it really should in the case of a whole office behind a NAT
gateway which may have only one public IP, and one guy in the office
is spoofing another's session.

If you define "session" as something longer, say, more than a day,
you run into the problem that users have more than one computer
(say, home and work) and want to use your site from both, and an
IP check will block that. Also, dialup users will probably change
IPs every time they redial.

Bank of America recently set up an interesting addition to their
online banking setup. You used to log in by entering a user
identifier and password on a web page. Now, after you've set it
up, it works like this:

1. You enter your user identifier on a web page and submit.
2. *IF* your computer has the cookie left by setting it
up, go to step 4.
3. Your computer doesn't have the cookie. It will ask you
one of three questions you set up and you have to
supply the correct answer you entered during setup.
4. The web page shows you an image and a caption you selected
at setup (For example, a fire-breathing dragon and the
caption "my mother-in-law"). Users are told NOT to
enter their password unless they see the correct image
and caption. In this way the user can be sure they aren't
on a spoofed web site.
5. You enter your password to log in.
6. You see the main page for online banking.

If you log in successfully and you didn't have the cookie, it will
ask if you log in from the computer you are on often, so you can
set up the cookie on several systems. However, DON'T set up the
cookie if you are logging in from an Internet Cafe or public library.

Depending on your memory and how much you might have to answer the
questions in an emergency, it might be a good idea to give illogical
answers to the questions (For example: what month is your wedding
anniversary? Answer: Saddam Hussein. One problem with this
approach is you have to remember how to spell the answer. I also
recall one guy had some irritating problems with his phone service
because he had put a password on it to lock out unauthorized changes,
and his password was 'Go f**k yourself', which had to be given to
human customer service representatives as well as on the web site,
but they didn't check the correct password before reacting badly.)

Gordon L. Burditt

[John]

Re: Sessions...

Gordon Burditt wrote:[color=blue][color=green][color=darkred]
>>>PHP sessions do work very well - except for one problem I found.
>>>
>>>MS IE kept using a different session ID for every page it requested !
>>>
>>>
>>>I solved this by creating my own session ID and storing it in a
>>>cookie, so I could get it back and force the same session ID each
>>>time.[/color][/color]
>
>
> I have to wonder WHY this would fix the problem. What is better
> about YOU creating the session ID and storing it in a cookie vs.
> PHP creating a session ID and storing it in a cookie? Perhaps
> someone is blocking the cookie 'PHPSESSID' and leaving others alone?[/color]

Yes, I know what you mean, as far as I understand, PHP just uses a
cookie to store the session ID anyway.

But, I found that MS IE users were being treated to a new session ID
for every page requested...

I fixed it, but I shouldn't have needed to ?

John.

[Gordon Burditt]

Re: Sessions...

>>>>PHP sessions do work very well - except for one problem I found.[color=blue][color=green][color=darkred]
>>>>
>>>>MS IE kept using a different session ID for every page it requested !
>>>>
>>>>
>>>>I solved this by creating my own session ID and storing it in a
>>>>cookie, so I could get it back and force the same session ID each
>>>>time.[/color]
>>
>>
>> I have to wonder WHY this would fix the problem. What is better
>> about YOU creating the session ID and storing it in a cookie vs.
>> PHP creating a session ID and storing it in a cookie? Perhaps
>> someone is blocking the cookie 'PHPSESSID' and leaving others alone?[/color]
>
>Yes, I know what you mean, as far as I understand, PHP just uses a
>cookie to store the session ID anyway.[/color]

It does have a fallback strategy of putting the session ID in the
URL, but if cookies seem to be working, that's what it will use.
[color=blue]
>But, I found that MS IE users were being treated to a new session ID
>for every page requested...
>
>I fixed it, but I shouldn't have needed to ?[/color]

My comment was more along the lines of:
Why the heck did your fix work? And if it did, why did PHP fail?

Gordon L. Burditt

[John]

Re: Sessions...

Gordon Burditt wrote:[color=blue][color=green]
>>But, I found that MS IE users were being treated to a new session ID
>>for every page requested...
>>
>>I fixed it, but I shouldn't have needed to ?[/color]
>
>
> My comment was more along the lines of:
> Why the heck did your fix work? And if it did, why did PHP fail?[/color]

I have no idea.

I just put it down to MS crap...

John.