* 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
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 an forth.
I know DB should be used for cart items, b
11 matches
Mail list logo