Hi Jeff,
I manage the website for the credit report reseller. We don't normally
use cookie but we use session only. You were expressing some concern about
someone knowing the session id. What we normally use is we used the
encrypted session id and use use long aphanumeric number. This make it hard
for someone to crack the code. We also use certain features that check the
session id and if it is a mismatch, we logged the user out. The only
problem we had is that when the user closed the browser, the session was not
destroyed but we have a work around to it. That is when the user logged in
again, we can tell if it is the same user or not and issue a new session id.
We also use the feature like logging the user out if the user is idle for 15
mintues.
If you want a copy of the sample code and analyze it then give me a
holler! Then I'll post it here. By the way, I enjoyed your other posting
about the encryption problem with libmcrypt. I had the same problem as
yours until I read it and found out that I need to install the mcrypt too.
So, I filed the PHP bug making a request that the documentation be updated
to include more information about mcrypt.
FletchSOD
"Jeff Bluemel" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> I put this block of code in, and all of the array's they should send back
> are 100% blank. I will try the protoscope to see what I can turn up on
> this.
>
>
> "Chris Shiflett" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Jeff,
> >
> > One quick thought ...
> >
> > Is your cookie domain the same domain as the URL domain you are using to
> > test this? If not, the browser will not send the cookie, so that is a
> > potential reason for this behavior.
> >
> > If the domain is the same, I see no reason why this shouldn't work, but
> > I have two ideas you can try.
> >
> > 1. Rather than using the name of the cookie, try this on the receiving
> page:
> >
> > <pre>
> > <?
> > print_r($_COOKIE);
> > ?>
> > </pre>
> >
> > This should dump the entire array to the screen and would reveal any
> > naming problems.
> >
> > 2. View the HTTP transactions themselves to make sure the proper
> > Set-Cookie and Cookie headers are being used. There are several
> > utilities that can help do this, and I recently wrote one in PHP (it's a
> > quick hack though) you can get at http://protoscope.org/. The messages
> > of interest are the original HTTP response from your Web server (which
> > should contain the Set-Cookie header) and any future HTTP request (which
> > should contain the Cookie header). This is the most reliable way to
> > really analyze these types of problems.
> >
> > Hopefully these ideas will help uncover something.
> >
> > Chris
> >
> > Jeff Bluemel wrote:
> >
> > >ok - no cookie exists... I have Netscape set to accept all cookies.
> > >
> >
>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
