lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Re: persistent cookies - needs changes


From: brian j. pardy
Subject: Re: lynx-dev Re: persistent cookies - needs changes
Date: Wed, 9 Dec 1998 13:10:34 -0800 (PST)

On Wed, 9 Dec 1998, Klaus Weide wrote:

> On Tue, 8 Dec 1998, brian j. pardy wrote:
> 
> > On Tue, 8 Dec 1998, Klaus Weide wrote:
> > > [...]
> > > 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).

Okay, I agree here. 

> 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>).

I saw that post, and think you're right that it's something that needs to
be looked at.  Offhand, I think there is something in store_cookie that
loops through the cookie list, looking for expired cookies, but I don't
remember if this is related.

Once I'm free from finals, I'm going to give these another good look. :)

> > 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 thought about splitting it up as well, or possibly passing one more
parameter to store_cookie which would tell it to check or not, that might
create less overhead.

> 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.

I believe LV added this (he'll yell if I'm wrong) because he was getting
cookies from my.yahoo.com with an invalid domain of 'yahoo.com' (or 
something similar) and he wanted to treat LYAcceptAllCookies literally, and 
not throw them away for a broken 'domain' attribute.  I don't think this was
specifically related to persistent cookies.

Ah, here it is:

2.8.1dev.27:

* modify store_cookie to suppress warning message for invalid domain if Lynx is
  setup to accept all cookies - LV

> > 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.

I can't think of any way to guarantee the existing behavior (well, short
of shellscript+cookie_file+.lynxrc) , but I don't think documentation
backs it up either.

One can always add that domain to COOKIE_ACCEPT_DOMAINS, too.

> > Thoughts?
> 
> There you have some...

Thanks!

-- 
GPG & PGP public keys: <URL:http://www.psnw.com/~posterkid/keys/> 
PGP fingerprint: 42 57 B3 D2 39 8E 74 C3  5E 4D AC 43 25 D2 26 D4

reply via email to

[Prev in Thread] Current Thread [Next in Thread]