lynx-dev Re: persistent cookies - needs changes

[Klaus Weide]

First, I found something that looks like a definite bug in store_cookie:

        if (persistent_cookies) {
            if ((de->bv = FROM_FILE) != 0) {
                HTList_appendObject(cookie_list, co);
            } else {
                HTList_insertObjectAt(cookie_list, co, pos);
            }
        }

That should be

            if (de->bv == FROM_FILE) {

right?  It was probably written as

            if (de->bv = FROM_FILE) {

by mistake, and then someone changed it the wrong way to get rid of a
compiler warning.

This may have caused some problems since cookies are effectively
never ordered by pathlen if persistent_cookies is on.

It also adds to the problem discussed below.  Once you accept one
cookie from a new domain, whether it is meant as a persistent cookie
or not, the FROM_FILE flag is set and further prompts are skipped.

There seems to be another omission in this section:

#ifdef EXP_PERSISTENT_COOKIES
        /* ... */
        if (persistent_cookies) {
            if ((de->bv = FROM_FILE) != 0) {
                HTList_appendObject(cookie_list, co);
            } else {
                HTList_insertObjectAt(cookie_list, co, pos);
            }
        } else        <<<<<
#else
        HTList_insertObjectAt(cookie_list, co, pos);
#endif /* EXP_PERSISTENT_COOKIES */

The `else' should be added (or the whole thing be rewritten some other way).
Otherwise cookies are silently dropped if defined(EXP_PERSISTENT_COOKIES)
but !persistent_cookies.


On Tue, 8 Dec 1998, brian j. pardy wrote:

> On Tue, 8 Dec 1998, Klaus Weide wrote:
> > Currently Lynx is misleading the user if (s)he uses persistent cookies but
> > still wants control over accepting cookies.  The Cookie Jar page says
> > (Persistent Cookies.) for any domain with a cookie read from the persistent
> > file and gives no indication that this actually means (All new cookies
> > automatically accepted and you will never be prompted.)!  The documentation
> > also doesn't tell this part of the story.  According to the text in the
> > Users Guide, Set-Cookie MIME headers should still invoke confirmation
> > prompts.
> 
> This could be a simple fix. 
> 
> Is the display of "(Persistent Cookies.)" really necessary for cookies read
> from the cookie file?

Not really as a property of the *domain*, I think.  Instead, the display for
each individual cookie could show "(from a previous session)".  We already
have this as per-cookie information in the flags.  As far as I can see this
flag will survive (until the cookie is cleared or removed or refreshed).
That is about a cookie's past; as for the future, i.e. whether it _will be_
written to the persistent file, that should be implied by the other
per-cookie info which is already displayed (expires, discard) -- if the
appropriate additional checks are added in LYStoreCookies (see one of
my other messages, <URL: 
http://www.flora.org/lynx-dev/html/month1298/msg00232.html>).

> Perhaps FROM_FILE can be done away with entirely,
> by setting de->bv to QUERY_USER when loading a cookie from the cookie list
> (unless it has already been set to ALWAYS_ALLOW or REJECT from .lynxrc),
> and add cookies to the cookie list within LYLoadCookies without using
> store_cookie.  

That sounds good (but I haven't thought it all through).
But if you don't want to use store_cookie, some of the functionality of
store_cookie has to be duplicated.  Maybe store_cookie should be split
into two functions, one store_cookie_with_checks which does the checks
based on `hostname' and `path', and another store_cookie_without_checks
which does the actual adding to the lists (and gets called from the
first).  LYLoadCookies could then just call the inner function
store_cookie_without_checks directly.  The `domain' and `path' parameters
currently passed to store_cookie from LYLoadCookies are kinda fake
anyway, they are just being passed so that store_cookie's checks won't
fail.

I don't know the full history of why the hack around the "Section 4.3.2, 
condition 4" check in store_cookie was deemed necessary. assuming this was
only for the benefit of persistent cookies, the `if (!LYAcceptAllCookies)'
around the confirmation prompt could be removed if cookies from files
never take this code path.

> This will take care of automatically accepting cookies from
> domains that have cookies stored, which would otherwise happen if 
> HTConfirmCookie was not called for FROM_FILE domains.

A problem could be that some people may _want_ the current behavior,
i.e. once a cookie stored for a domain => always accept cookies.
But at least ther isn't anything in the current documentation (that
I could find) to support that expectation, and there are already other
ways for accepting all cookies from a given domain.

> Thoughts?

There you have some...

   Klaus