* Thus wrote Joel Rees ([EMAIL PROTECTED]):
> > if you do sniff the hash, the key, and the session. You will have
> > to get your request in before the key becomes stale,
>
> race, race!
>
> > In most cases the authentication is the first thing done so we're
> > dealing with micro seconds.
>
>
This is what I decided to do. So the pages that need to be secured, I
send the the SID as a GET QUERY variable.
I don't like it, but it's the only thing I seems right.
Joel Rees wrote:
if you do sniff the hash, the key, and the session. You will have to
get your request in before the key beco
> if you do sniff the hash, the key, and the session. You will have to
> get your request in before the key becomes stale,
race, race!
> In most cases the authentication is the
> first thing done so we're dealing with micro seconds.
Most cases?
Why re-invent the wheel?
--
Joel Rees, progra
John Manko wrote:
You dont need to touch any php code, just modify the html so the
properlinks point to https where needed.
I tried that. However, the session is different when going from 80 to 443.
You'll have to pass the SID through the form or URL when switching from
HTTP to HTTPS.
--
-
You dont need to touch any php code, just modify the html so the
properlinks point to https where needed.
I tried that. However, the session is different when going from 80 to
443.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
* Thus wrote John W. Holmes ([EMAIL PROTECTED]):
> Curt Zirzow wrote:
>
> >On and advanced note, there are ways to protect a users password on a
> >normal http connection. The authentication program I helped
> >developed and use has the abilty to make a hash of the password on
> >the client side
Curt Zirzow wrote:
On and advanced note, there are ways to protect a users password on a
normal http connection. The authentication program I helped developed
and use has the abilty to make a hash of the password on the client side
then send the hash value to the authentication script. The authen
On Monday 21 July 2003 00:30, Curt Zirzow wrote:
> I'm curious as to why your email has these headers:
>
> References: <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> In-Reply-To: <[EMAIL PROTECTED]>
>
> My email program thinks your discussing db sized and how you can get it
> into
I'm curious as to why your email has these headers:
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
My email program thinks your discussing db sized and how you can get it
into a variable in php.
Curt
--
"I used to think I was indecisive,
* Thus wrote John Manko ([EMAIL PROTECTED]):
> I'm having a little trouble understanding how to accomplish this.
> Should the entire browsing session be HTTPS after login, or just for
> important functions like "login" and "checkout"
> If noly for those function, who should I design to jump back a
10 matches
Mail list logo
