423,336 Members | 1,194 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 423,336 IT Pros & Developers. It's quick & easy.

Sessions...

P: n/a
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
Dec 13 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
PHP session handling is excellent IMOP but thats just my take :-)

Dec 13 '05 #2

P: n/a
>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???
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).
I don't like to use things just because they're there. Im currently
But if you spend all your time inventing a replacement for the
ASCII character set or HTML, you will never get much useful done.
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...


Gordon L. Burditt
Dec 13 '05 #3

P: n/a
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.

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.

Dec 14 '05 #4

P: n/a
John wrote:
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.


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
Dec 14 '05 #5

P: n/a
Simon Dean wrote:
John wrote:
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.

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


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.
js*******@attglobal.net
==================
Dec 14 '05 #6

P: n/a
Simon Dean wrote:
John wrote:
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.

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?


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.

Dec 14 '05 #7

P: n/a
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.

Dec 14 '05 #8

P: n/a
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.

Dec 14 '05 #9

P: n/a
John wrote:
Simon Dean wrote:
John wrote:
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.


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?

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.


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
Dec 14 '05 #10

P: n/a
>>> 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.


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?
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?


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
Dec 15 '05 #11

P: n/a
Gordon Burditt wrote:
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.

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?


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.

Dec 16 '05 #12

P: n/a
>>>>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.

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?


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


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.
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 ?


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
Dec 16 '05 #13

P: n/a
Gordon Burditt wrote:
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 ?

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


I have no idea.

I just put it down to MS crap...

John.

Dec 16 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.