164260 - online.lloydstsb.co.uk - Lloyds TSB - lloydstsb.com - login information is not retained

Status: VERIFIED FIXED

(Tech Evangelism Graveyard :: English Other, defect, P2)

Description

[Graeme Coates]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1b) Gecko/20020721
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1b) Gecko/2002082304

After logging into the banking system at
https://online.lloydstsb.co.uk/customer.ibc, and then attempting to navigate
inside the banking system (eg by selecting an account from the account list),
the page changes back to the login screen, despite showing the correct URL in
the address bar for the link clicked. Same behaviour would occur if the session
timed out - perhaps session handling is not working correctly.

Problem is apparent with build 2002082304 but does not occur with 1.1b from
download page (2002072104).

Bug may require a valid banking log on to reproduce.

Reproducible: Always

Steps to Reproduce:
1.Log on to https://online.lloydstsb.co.uk/customer.ibc
2.Select a link on the first page (eg account in list).
3.Navigation will return to logon screen despite correct URL showing.

Actual Results:  
Navigation returned to login screen.

Expected Results:  
Navigated to correct page within banking system.

N/a

Comment 1

[Sam J. Fleet]

Sound like cookie or session problem.  They are used by the server side 
languages.  If the user turned off the cookie or restrict the cookie then this 
is where the banking can't keep track of the user and moved the user to the 
login page.  It's the bank way of keeping hte unauthorize user from fiddling 
around.  

Comment 2

[Sam J. Fleet]

Change this bug to "Tech Envangelism"??

Comment 3

[Graeme Coates]

Cookies are all turned on - and not sure why it should be OK with an older 1.1b build, and then fall over with a recent 1.1b nightly build...hmm. 

Comment 4

[Ian Neal]

*** Bug 168291 has been marked as a duplicate of this bug. ***

Comment 5

[Ian Neal]

Duped bug topic was "When choosing banking account, you get bounced back to
login screen. 1.1 works correctly" and it was set to PSM Client Library
Confirming.

Comment 6

[Ian Neal]

Adding regression keyword as this used to work fine in 1.1b, I see the problem
in BuildID 2002090708 on Win2KSP2, from duped bug affects Windows ME too.

Comment 7

[Ian Neal]

Tested on BuildID 2002083005 on Linux (RH7.3), also fails, setting OS to All
This doesn't just happen on 1.2a, tested against BuildIDs 2002083108, 2002082008
and 2002080508 on Win2KSP2. It works fine on BuildID 2002080508 but fails on the
other two, so something that landed between 2002080508 and 2002082008 has caused
this regression.

Comment 8

[Stephane Saux]

I don't think this is crypto related, so PSM is not the right component.

Kai take a look and reassign to the component tha makes most sense?

Comment 9

[Kai Engert [:KaiE:]]

Making a wild guess, what could be the cause of the problem, and transfering
this bug to => browser, cookies

This bug needs investigation. A banking site does no longer work. We don't know
yet what the cause is.

But at least it should not be crypto/https/SSL, since general connectivity/page
loading seems to be working.

Comment 10

[Jon Levell]

*** Bug 171719 has been marked as a duplicate of this bug. ***

Comment 11

[Jon Levell]

*** Bug 172206 has been marked as a duplicate of this bug. ***

Comment 12

[Jon Levell]

Ok, had a bit of a play with the cookie manager (and this cookie log thing from
bug 171507). Not cookie's are being rejected or not sent. What is happening is
the following.

Early in the login process Lloyds sets a cookie called ibcsession=0 once you
have logged in you are given another cookie with a valid ibcsession (a very long
string of numbers). It also sets another cookie: ShutdownRequested=No

Then as you try to navigate around it asks for the cookies back. My guess is for
some reason the order that the cookies as sent back in has changed, now it sends
oldest first: ibcsession=0; ibcsession=000etc; ShutdownRequested=no. And the
Lloyds site sees session=0 and thinks we don't have a valid session. Presumably
it used to send the ibcsession=<valid string> first (but I can't tell as the
older builds don't have cookie logging).

Anyhow here is a simple work around! All you need to do is delete the
ibcsession=0 cookie once you are logged in then navigating around the site works
fine. 

Hopefully this will help with a fix?

Comment 13

[Kai Engert [:KaiE:]]

Jon, thanks for the analysis.
So I'm reassigning this to the browser-cooky owners.

So what happening is:

- you received:
    key=value

- then you received:
    key=AnotherValue

And you end up with both cookies being stored.

I would have naively assumed, only one cooky for each key must be stored at any
time. When you receive AnotherValue, shouldn't that replace/overwrite the
earlier cooky?

Comment 14

[Jon Levell]

Yes the cookie name for both of them is ibcsession. I think it is not
overwritting because the Host field in the cookie manager says:
online.lloydstsb.co.uk for the ibcsession=0 cookie but the field changes to
domain and reads .online.lloydtsb.co.uk for the second cookie. We've always kept
both cookies. Looking at the range of dates in comment #7, surprisingly little
happened in relation to the cookies, I've had a brief glance at the patches
checked in but can't see anything related. 

I'm wildly guessing that this is related to bug 155114 which I don't have access
to but was related to a security flaw involving cookies.

Comment 15

[Stephen P. Morse]

This was reported back in August and several changes have been made and
subseqently backed out recently.  Especially regarding handling of the path
attribute.

Try it again and let me know if it is still a problem.  If so, attach the cookie
log to the bug report.  You can generate a log by doing:

    set NSPR_LOG_MODULES=cookie:3 -- shows rejected cookies
    set NSPR_LOG_MODULES=cookie:4 -- shows accepted and rejected cookies
    set NSPR_LOG_FILE=c:\cookie.log

Use both 3 and 4 (two separate runs of course) and attach both logs.

Comment 16

[Jon Levell]

Stephen,

It is still a problem in the latest nightly builds. As I said in comment #12 I
have run with your cookie logging and none are rejected or not sent. I'm loathe
to attach the report here as the cookie values include my user-name as part of
the string. If you still think it will be useful after my description of the
situation I'll post a censored version of the log?

I'm a bit confused about when you think this bug occurred, we know (comment #7)
that it worked with nightly builds upto 5th Sept and we know it didn't work on
the 23rd September so I don't think we need worry about checkins in August?!?

Comment 17

[Stephen P. Morse]

The bug was reported on August 23, so I'm presuming that it wasn't working on
that date.

Yes, I still would like to see the cookie log, just to verify that what you said
is true.  You can truncate the cookie values since the specific value is of no
relevance, except to indicate when the value has actually changed or that it
differs from another cookie having the same name.

Comment 18

[Jon Levell]

Attachment: Cookie log with cookie:4 set.

Cookie Log with NSPR_LOG_MODULES = cookie:4 set while navigating around the
LloydsTSB websie

Comment 19

[Jon Levell]

Excuse my last comment Stephen, we know the problem occurred between the 5th and
23rd of August not of September (too early in the morning here ;). I've attached
a log, of what happened when I loaded mozilla, logged into the site, clicked on
a link then re-entered my username and password when prompted. If I use cookie:3
as the log module I get a blank file. 

Comment 20

[Stephen P. Morse]

Problems that I see in the cookie log:

1. Secure attribute

   ===== COOKIE ACCEPTED =====
   request URL: https://online.lloydstsb.co.uk/customer.ibc
   cookie string: ibcsession=<censored value>; domain=online.lloydstsb.co.uk;
                  path=/;secure=yes;
   current time (gmt): Fri Oct 11 09:57:09 2002
   ----------------
   name: ibcsession
   value: <censored value>
   domain: .online.lloydstsb.co.uk
   path: /
   expires (gmt): at end of session
   is secure: false

Note that the set-cookie header had "secure=yes" but the cookie got stored
without the secure attribute.  That means that the cookie will be sent out on
future requests to non https sites which is against the instructions of the site
when the cookie was set.  I believe that the problem here might be that are
parsing is being thrown off by the "=yes" part which is syntactically incorrect
for the "secure" attribute according to the cookie spec.  That requires more
investigation.  However I don't think this has anything to do with the current
problem.

2. Sending duplicate cookies

   ===== COOKIE SENT =====
   request URL: https://online.lloydstsb.co.uk/scripts/scripts1.css
   cookie string: ibcsession=0; ibcsession=<censored value>
   current time (gmt): Fri Oct 11 09:57:09 2002

This is perfectly correct since the two cookies differ in both their domain
attributes which makes them distinct cookies.  The rule is that cookies be sent
back with longest path first.  In this case both cookies have the path attribute
of "/", so the ordering of the cookies is is undefined.

It should be noted that only one of the set-cookie headers specified a path (of
"/") and the other did not have a path attribute.  By default we assigned the
latter a path attribute of "/".  That might be the problem.  That is, at one
time we might not have been forcing a "/" if the attribute was missing but
rather using a blank path.  In that case the cookie ordering would be such that
this missing-path cookie would always be sent out last.

I don't know if this is the problem or not, but it certainly is worthy of
further investigation.

Comment 21

[Stephen P. Morse]

I just filed bug report 174104 on the "secure=" problem noted in comment 20. 
But that couldn't have any bearing on the current symptoms.

Comment 22

[Olivier Cahagne]

*** Bug 174117 has been marked as a duplicate of this bug. ***

Comment 23

[Olivier Cahagne]

*** Bug 174958 has been marked as a duplicate of this bug. ***

Comment 24

[Stephen P. Morse]

This one's pretty serious since it involves a major bank and we are starting to
get dups on it.

I'll argue that it's really an evangelism issue.  Site is intentionally setting
two cookies with the same name, and then getting confused when we send them back
not in the order that they expect.  And our ordering is correct since one cookie
was set without a path name (which meand "/" path by default) and the other with
an explicit path name of "/".  (The spec requires that the ordering be by
inverse path length.)

Reassiging to evangelism.

Comment 25

[Stephen P. Morse]

Really reassigning this time.

Comment 26

[john_pub_mail1]

For the Evangelists:

Contact adresses/numbers for Lloyds-Tsb Online banking are at
http://www.lloydstsb.com/contacts/0,1006,general,00.html (you don't need to log
in or have an account for this).  You can email them (takes you to a webform).

They do list requirements as  "Netscape Navigator 4.06 and above or Internet
Explorer 4 and above", and indicate that my "Netscape 5" passes the needed
requirements, so hopefully they may be willing to change the behaviour of their
cookies.

Comment 27

[Frank Wein [:mcsmurf]]

*** Bug 175034 has been marked as a duplicate of this bug. ***

Comment 28

[emmet]

From my reading of the spec, Mozilla is a fault rather than the bank.

Can I just make very explicit what the problem is here (I will use the cookie
spec http://wp.netscape.com/newsref/std/cookie_spec.html being unable to find a
proper RFC and assuming (possibly wrongly) that Netscape's stuck)

On first connect, the bank sends a cookie with

Name:   ibcsession
Info:   0
Host:   online.lloydstsb.co.uk
Path: 

and after a sucessfull login form completion

Name:   ibcsession
Info:   <long string of numbers>
Domain: .online.lloydstsb.co.uk
Path:   /

We can see that there are two differences in what ought to be (and as the bank
assumes to be interpreted as) the same cookie.

1) The hostname becomes a domain by the insertion of a '.' at the front.
According to the spec, on this point, both cookies can not be distinguished
since all that is required is that (in the '.uk' case) there is a 'tail match'
of the last three terms. *This is the case*

2) The inital path name is blank and the subsiquent path names are '/'.
According to the spec a blank path name is reinterpreted as being the same as
the path of the document fetched with the cookie. In this case that path is '/'.
*As such the two paths match.*

Since according to this application of the Cookie Specifications the cookies
identifiers match, Mozilla should overwrite the new one with the old one.

Therefore (since I can't) please reassign to [Browser:Cookies]

Comment 29

[John Unruh]

Browser:Cookies

Comment 30

[john_pub_mail1]

Given: 

 - the number of dupes.
 - the fact that it affects a major online bank.
 - it has been outstanding for some time after being incorrectly marked as the
banks fault.

is there any way of increasing the priority of this in order to get a quick fix?

I've seen similar cookie related weirdness with Yahoo groups and Sourceforge
downloads which I suspect are related to this problem of incorrect
setting/returning of cookies.

Comment 31

[Kai Engert [:KaiE:]]

I will send an email message to Mozilla drivers now, asking them to thing about
this bug.

Steve, what's your opinion on comment 28?

Comment 32

[Stephen P. Morse]

comment 28 is confused about the difference between a host cookie and a domain
cookie.  In fact the following from comment 28 is misleading

> On first connect, the bank sends a cookie with
>
> Name:   ibcsession
> Info:   0
> Host:   online.lloydstsb.co.uk
> Path: 

What the bank actually sent was a cookie header of the form 

   set-cookie: ibcsession=0

and nothing more.  There was no mention of a host since indeed there is no such
thing as a host attribute in a set-cookie header.  Instead, by default, if no
domain attribute is specified, then the cookie is taken to be a host cookie
which means it will be sent back only to the exact host that set the cookie.  It
will not be sent back to any other hosts in a domain  ending with the host name.

In the second instance the bank sent a cookie header of the form

   set-cookie: ibcsession=<censored value>;
               domain=online.lloydstsb.co.uk; path=/;secure=yes;

That's a domain cookie.  It is syntactically incorrect since a domain is
supposed to start with a dot (see the spec) but the cookie code is forgiving and
silently inserts the dot.  This cookie wil then get sent back to every host
which tail-matches .online.lloydstsb.co.uk.  For example it will send it to host
xxx.online.lloydstsb.co.uk.  It will also send it to the host that is simply
.online.lloydstsb.co.uk, treating that as a special case.

So you can see, these are two different cookies.  One is a host cookie that gets
sent back only to the one host.  The other is a domain cookie that gets sent
back to all hosts in the domain.

As far as the paths differing, that is not a problem.  In the first case there
was no path specified in the set-cookie header, so in that case the cookie
module uses the path of "/" by default.  In the second case the set-cookie
header explicitly specified the path of "/".  So the two are treated identically
by the cookie module.  Had there not been the discrepency of the host/domain
part, the cookie module would have recognized these as being the same cookie in
spite of this path difference.

I stand by my original conclusion -- this is not a problem with our cookie code
but is a site issue that needs to be handled be evangelism.

Reassiging back to evangelism.

Comment 33

[Stephen P. Morse]

> I've seen similar cookie related weirdness with Yahoo groups and Sourceforge
> downloads which I suspect are related to this problem of incorrect
> setting/returning of cookies.

If you've seen other problems with other sites, then please report them as
separate bugs so that they can get investigated.  Do not assume that they are
related to this bug, because this one is very specific and has to do with the
site setting the same cookie twice -- once with a domain attribute and once
without it.

Comment 34

[Stephen P. Morse]

Updating summary line to explicitly mention Lloyds Bank so that it can be found
by doing a query

Comment 35

[emmet]

Ok, Steven, I agree. I have found RFC2109
( http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2109.html ) -- for the purposes
of Evangelism, is this (or some other) the agreed specification of cookies and
by what authority?

Comment 36

[Stephen P. Morse]

I have no idea what authority agrees on the specification.  But, yes, this is
the agreed-upon spec.

However, in the case of cookies, its impossible to implement the exact spec
because it breaks too many websites.  So instead we try to implement as much of
it as possible and back off only in extreme cases.  This is not an extreme case
-- it involves only one website and so should be evangelized.

A case in which we have had to back off was in not letting sites set cookies for
paths in which they were not on.  The spec clearly prohibits that.  But when I
implemented it, too many important websites broke.

Comment 37

[emmet]

Attachment: evangelism letter sent to Lloyds

Ok, so I sent Lloyds. It's very polite.

Comment 38

[emmet]

Comment on attachment 105454 [details]
evangelism letter sent to Lloyds

As a long and happy user of the Lloyds (then LloydsTSB) online banking system I
write concerning a problem with the system’s implementation of cookies, in
particular how it sets the cookie ‘ibcsession’. My investigation of the problem
identifies the site’s failure to follow RFC2109 causes an incompatibility with
Mozilla browser versions 1.2 upwards. As I am sure you are aware, the Netscape
browser is a branded version of the Mozilla browser and, as such, making it
highly likely that forthcoming releases of the Netscape browser will also
suffer the same incompatibility.

May I first point out the problem and then make very explicit why it is a
problem.

When a browser first connects to https://online.lloydstsb.co.uk/customer.ibc
the following cookie is sent from the site

request URL: https://online.lloydstsb.co.uk/customer.ibc
cookie string: ibcsession=0;

The problem is that no domain attribute has been set and that the string should
have been:

cookie string: ibcsession=0; domain=.online.lloydstsb.co.uk;



I will now provide a detailed analysis.

The parameters: domain, path, secure etc are not specified in the cookie string
above and RFC2109:4.3.1 describes how to fill these parameters with default
values:

name: ibcsession
value: 0
request-host: online.lloydstsb.co.uk
path: /
expires (gmt): at end of session
is secure: false

The most important (and the source of the error in implementation according to
RFC2109) is that there is no ‘domain’ attribute and as such a “request-host” is
set (4.3.1) – this will be fully explained below.

After the user fills in their User ID and Password the following cookie is sent
to the browser from the site

request URL: https://online.lloydstsb.co.uk/customer.ibc
cookie string: ibcsession=<censored value>; domain=online.lloydstsb.co.uk;
path=/;secure=yes;

which according to RFC2109 should be interpreted as

name: ibcsession
value: <censored value>
domain: .online.lloydstsb.co.uk
path: /
expires (gmt): at end of session
is secure: false

There are several problems with the cookie string as can be seen by this
interpretation. The most obvious (which is not the cause of the
incompatibility) is that the ‘secure’ attribute is not set – this is because
RFC2109:4.2.2 specifies that the ‘secure’ attribute in the cookie string should
be specified “with no value”. The second problem (also not a cause of an
incompatibility with Mozilla but a possible problem for the future) is that
according to RFC2109:4.2.2 when specifying the domain attribute “an explicitly
specified domain must always start with a dot.” otherwise according to 4.3.1
the cookie should actually be rejected (although Mozilla like many browsers
ignores this requirement).

When the user next clicks upon a link (to service their account) they find that
they have been returned to the initial login page *rather than the account
information page they expected*. This is because Mozilla returns this cookie
string to the LloydsTSB site:

cookie string: ibcsession=0; ibcsession=<censored value>

The source of the incompatibility is clear, Mozilla sends two values of
‘ibcsession’ and the site, expecting only one, sees the first and returns the
login page since ‘ibcsession=0’. Mozilla returns two values because according
to RFC2019:4.3.1 when *no* domain attribute is set then the browser should “…
defaults to the request-host . (Note that there is no dot at the beginning of
request-host.)” When a domain is supplied then the domain attribute is set to
the supplied string where (4.2.2) “An explicitly specified domain must always
start with a dot.”.

As such the two cookies are seen as *different* so *the second does not update
the first* and according to RFC2109:4.3.4 *both* shall be returned by the
browser (though the order they are to be returned in is a little unclear
(4.3.4) “Ordering with respect to other attributes (e.g., Domain) is
unspecified.”)

I write to request that LloydsTSB make the small change to the code that I have
identified at the top of this letter and look forward to hearing your thoughts
upon this incompatibility.

Best regards,

Dr. Emmet Spier.

Comment 39

[emmet]

Comment on attachment 105454 [details]
evangelism letter sent to Lloyds

As a long and happy user of the Lloyds (then LloydsTSB) online banking system I
write concerning a problem with the system’s implementation of cookies, in
particular how it sets the cookie ‘ibcsession’. My investigation of the problem
identifies the site’s failure to follow RFC2109 causes an incompatibility with
Mozilla browser versions 1.2 upwards. As I am sure you are aware, the Netscape
browser is a branded version of the Mozilla browser and, as such, making it
highly likely that forthcoming releases of the Netscape browser will also
suffer the same incompatibility.

May I first point out the problem and then make very explicit why it is a
problem.

When a browser first connects to https://online.lloydstsb.co.uk/customer.ibc
the following cookie is sent from the site

request URL: https://online.lloydstsb.co.uk/customer.ibc
cookie string: ibcsession=0;

The problem is that no domain attribute has been set and that the string should
have been:

cookie string: ibcsession=0; domain=.online.lloydstsb.co.uk;



I will now provide a detailed analysis.

The parameters: domain, path, secure etc are not specified in the cookie string
above and RFC2109:4.3.1 describes how to fill these parameters with default
values:

name: ibcsession
value: 0
request-host: online.lloydstsb.co.uk
path: /
expires (gmt): at end of session
is secure: false

The most important (and the source of the error in implementation according to
RFC2109) is that there is no ‘domain’ attribute and as such a “request-host” is
set (4.3.1) – this will be fully explained below.

After the user fills in their User ID and Password the following cookie is sent
to the browser from the site

request URL: https://online.lloydstsb.co.uk/customer.ibc
cookie string: ibcsession=<censored value>; domain=online.lloydstsb.co.uk;
path=/;secure=yes;

which according to RFC2109 should be interpreted as

name: ibcsession
value: <censored value>
domain: .online.lloydstsb.co.uk
path: /
expires (gmt): at end of session
is secure: false

There are several problems with the cookie string as can be seen by this
interpretation. The most obvious (which is not the cause of the
incompatibility) is that the ‘secure’ attribute is not set – this is because
RFC2109:4.2.2 specifies that the ‘secure’ attribute in the cookie string should
be specified “with no value”. The second problem (also not a cause of an
incompatibility with Mozilla but a possible problem for the future) is that
according to RFC2109:4.2.2 when specifying the domain attribute “an explicitly
specified domain must always start with a dot.” otherwise according to 4.3.1
the cookie should actually be rejected (although Mozilla like many browsers
ignores this requirement).

When the user next clicks upon a link (to service their account) they find that
they have been returned to the initial login page *rather than the account
information page they expected*. This is because Mozilla returns this cookie
string to the LloydsTSB site:

cookie string: ibcsession=0; ibcsession=<censored value>

The source of the incompatibility is clear, Mozilla sends two values of
‘ibcsession’ and the site, expecting only one, sees the first and returns the
login page since ‘ibcsession=0’. Mozilla returns two values because according
to RFC2019:4.3.1 when *no* domain attribute is set then the browser should “…
defaults to the request-host . (Note that there is no dot at the beginning of
request-host.)” When a domain is supplied then the domain attribute is set to
the supplied string where (4.2.2) “An explicitly specified domain must always
start with a dot.”.

As such the two cookies are seen as *different* so *the second does not update
the first* and according to RFC2109:4.3.4 *both* shall be returned by the
browser (though the order they are to be returned in is a little unclear
(4.3.4) “Ordering with respect to other attributes (e.g., Domain) is
unspecified.”)

I write to request that LloydsTSB make the small change to the code that I have
identified at the top of this letter and look forward to hearing your thoughts
upon this incompatibility.

Best regards,

Dr. Emmet Spier.

Comment 40

[emmet]

I have received the following email from Lloyds, looking up but not till next year.

===========================================================================


Further to your email.

Thank you for bringing this to our attention.  Your email has been passed on to
our Internet banking IT team who have investigated the issue relating to the
Mozilla browser that you raised in your mail.  As a result, an enhancement
request has been raised which will be implemented in the first quarter of 2003.

If you have any further queries, please do not hesitate to contact us again at
[e-mail]

Regards

Margo Agnew
Lloyds TSB Online
_________________

Comment 41

[Torben]

*** Bug 182214 has been marked as a duplicate of this bug. ***

Comment 42

[Olivier Cahagne]

*** Bug 183070 has been marked as a duplicate of this bug. ***

Comment 43

[R.K.Aa.]

*** Bug 183325 has been marked as a duplicate of this bug. ***

Comment 44

[Olivier Cahagne]

*** Bug 184991 has been marked as a duplicate of this bug. ***

Comment 45

[Olivier Cahagne]

*** Bug 186119 has been marked as a duplicate of this bug. ***

Comment 46

[Richard van der Hoff]

Attachment: Email sent to LloydsTSB

I asked LloydsTSB to educate their telephone help desk...

Comment 47

[Rob Little]

Can the summary be updated so this bug can be found by people searching on
Lloyds TSB or lloydstsb.com? That's why I didn't find it originally and instead
contributed to a different bug...

Comment 48

[Torben]

Lloyds TSB and lloydstsb.com added to the summary.

Comment 49

[WD]

*** Bug 186501 has been marked as a duplicate of this bug. ***

Comment 50

[emmet]

Further comments from Lloyds:

"I have just received a mail from our Internet banking IT team, informing me
that they have successfully applied the fix you suggested to the Mozilla browser
issue you raised in November , and that it will be implemented on the live site
in mid-February 2003. 
 
"They have asked me to pass on their thanks to you for your detailed analysis,
which has saved them a considerable amount of time.
 
"Best wishes for Christmas and the new year."

and likewise from me.

Comment 51

[Brant Gurganus]

Setting milestone per comment.

Comment 52

[Olivier Cahagne]

*** Bug 190935 has been marked as a duplicate of this bug. ***

Comment 53

[Richard van der Hoff]

This seems to have been fixed.  It works for me, anyway, and the cookie log
looks better; though I did download a new nightly yesterday, so it's possible
something else has changed.

Comment 54

[graham marshall]

Agreed, works for me in 1.2.1.

Comment 55

[patrick]

This has definately been fixed, I am using mozilla 1.3a, on monday the problem
was still there, today I can login and cookies are OK. Could the owner or
someone with permission please mark this as resolved.

Comment 56

[Jon Levell]

Yep, works here to with the same old build that used to choke. Marking fixed

Comment 57

[Brant Gurganus]

Verifying due to abundance of comments.

Comment 58

[Bob Clary [:bc] (inactive)]

tech evang june 2003 reorg