> On Thu, 2002-03-14 at 17:05, Michael wrote:
>
> > aaarrrggghhhh...... that was it. The windoze box was two
> > minutes behind the server. This is pretty common, I try to make my
> > applications that use cookies resistant to this kind of problem as it
> > is very common for my users as well as (blush) me too :-(
> >
> > Turns out that this is the reason behind the database lock up as
> > well. I'd suggest that this is a serious problem that should be fixed
> > since it leaves junk in the database. The cookie timing should be
> > immune to small offsets and at worst should generate a warning to the
> > client.
>
Things are different again today -- very frustrating!!! Browser
dependent problems have reappeared, the two above problems are
related somehow, but the timing skew is not the immediate cause (I
don't think). The problem has re-appeared and I have messed around
with the browser host time, moving it forward and back with respect
to the http host without being able to make the the login or database
lockup go away. There is some kind of race condition that is causing
the problem. It is difficult to get repeatable results except where
seeing the results produces a very complex set of clues.
1) with SSL enabled for login only
or
2) when attempting to create a story
there may be other scenarios, but I haven't gotten beyond this. It
appears that only the Netscape browser is affected
Let's take the ssl enabled login scenario. When loging in, the
autentication is successful and the appropriate AUTH cookie is
returned. Netscape for some reason responds in such a manner that the
server thinks it necessary to send the cookie 4 times for bric
version 1.2.1, (one time for bric version 1.2.2) while sending it
only once for MSIE5.5. The redirect to non-encoded space generates a
request for and Expire for the BRICOLAGE cookie which is replaced
with a new one -- I am assuming this is the session key??? What
follows immediately is a return to the login screen. Probably??
because the session now has a different identifier.
I am continuing to investigate this problem, any assistance or ideas
would be appreciated.
Michael
Michael@Insulin-Pumpers.org
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general
>
> > aaarrrggghhhh...... that was it. The windoze box was two
> > minutes behind the server. This is pretty common, I try to make my
> > applications that use cookies resistant to this kind of problem as it
> > is very common for my users as well as (blush) me too :-(
> >
> > Turns out that this is the reason behind the database lock up as
> > well. I'd suggest that this is a serious problem that should be fixed
> > since it leaves junk in the database. The cookie timing should be
> > immune to small offsets and at worst should generate a warning to the
> > client.
>
Things are different again today -- very frustrating!!! Browser
dependent problems have reappeared, the two above problems are
related somehow, but the timing skew is not the immediate cause (I
don't think). The problem has re-appeared and I have messed around
with the browser host time, moving it forward and back with respect
to the http host without being able to make the the login or database
lockup go away. There is some kind of race condition that is causing
the problem. It is difficult to get repeatable results except where
seeing the results produces a very complex set of clues.
1) with SSL enabled for login only
or
2) when attempting to create a story
there may be other scenarios, but I haven't gotten beyond this. It
appears that only the Netscape browser is affected
Let's take the ssl enabled login scenario. When loging in, the
autentication is successful and the appropriate AUTH cookie is
returned. Netscape for some reason responds in such a manner that the
server thinks it necessary to send the cookie 4 times for bric
version 1.2.1, (one time for bric version 1.2.2) while sending it
only once for MSIE5.5. The redirect to non-encoded space generates a
request for and Expire for the BRICOLAGE cookie which is replaced
with a new one -- I am assuming this is the session key??? What
follows immediately is a return to the login screen. Probably??
because the session now has a different identifier.
I am continuing to investigate this problem, any assistance or ideas
would be appreciated.
Michael
Michael@Insulin-Pumpers.org
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general