- Dillo-dev - lists.mailman3.com

[Patch 3/4] Key bindings

by tim.nieradzik＠gmx.de

This patch adds support for configurable key bindings. --Tim

April 10, 2009

[Patch 2/4] Refactoring src/prefs.c and src/dir.c

by tim.nieradzik＠gmx.de

This patch cleans up src/prefs.c and introduces the PrefsParser (src/prefsparser.cc). Furthermore, src/dir.c is now C++-based as in C this declaration would have been problematic: bool Paths::getPrefs(const char* rcFile, FILE* &fp) --Tim

April 10, 2009

[Patch 1/4] Camel case in src/dillo.cc

by tim.nieradzik＠gmx.de

As I have had some time, I finally split the monolithic patch into four independent ones. However, they must be applied in the correct order. This first patch deals with renaming all method names in src/dillo.cc their camel case notation.

April 10, 2009

Dillo + Partial Javascript Support

by matopoftheworld＠live.co.uk

Justus wrote: There are several free ecmascript interpreters available, choosing one of them and putting it into a dillo plugin is the easy part. But in order to be useful the script needs the ability to manipulate the page content. And designing that part right is hard... ... Thanks Justus, corvid also sent an email. I found another thread about Javascript support in the dillo archives: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2005-March/002614.html As I mentioned, I am not interested in the parts of Javascript that does dynamic HTML but the ones that allow logins which I assume is network based (sorry for lack of knowledge, I had done some basic Javascript a year or two ago). Hopefully this will not require too much change to Dillo as my C skills are a bit rusty and would like to concentrate on something small like a plugin while I get up to speed. I've got some time off work so if I don't get distracted I'll have a look how you could go about it. _________________________________________________________________ View your Twitter and Flickr updates from one place ? Learn more! http://clk.atdmt.com/UKM/go/137984870/direct/01/

April 9, 2009

http authentication: http digest

by Johannes.Hofmann＠gmx.de

On Thu, Apr 09, 2009 at 11:29:14AM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hofmann Johannes wrote: > > I've just one minor comment for now: It would be nice if the > > password dialog would show the authentication method used. > > Or can one already see what is going to happen? > You are absolutely right, and this is in fact on my wishlist as well > (grep 'inform the user' src/auth.c). I am going to fix that next week. > Ah nice! Johannes

April 9, 2009

http authentication: http digest

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hofmann Johannes wrote: > I've just one minor comment for now: It would be nice if the > password dialog would show the authentication method used. > Or can one already see what is going to happen? You are absolutely right, and this is in fact on my wishlist as well (grep 'inform the user' src/auth.c). I am going to fix that next week. Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkndv+oACgkQoPmwNWhsaZbJtACgoi7ELkYRm22j+iJE0RNfSvda TMsAnikrxyb4oo4iArMf1kYgoTePpR5c =f6d9 -----END PGP SIGNATURE-----

April 9, 2009

http authentication: http digest

by Johannes.Hofmann＠gmx.de

On Thu, Apr 09, 2009 at 09:59:53AM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > corvid wrote: > > Justus wrote: > >> On Wed, Apr 08, 2009 at 03:42:46AM +0000, corvid wrote: > >>> Justus wrote: > >>>> corvid wrote: > >>>>>> * http digest can provide integrity protection for the request body > >>>>>> by computing a hash over the request body, but I have no pointer to > >>>>>> the request body, only the request URL. We might need to pass the > >>>>>> whole request object (is there such a thing?) to the auth code instead > >>>>>> of just the url. The code is there, just the pointer is missing. The > >>>>>> code in auth.c will select the method without integrity protection for > >>>>>> now, hoping that the server will accept both auth and auth-int. > >>> *snip* > > Does URL_DATA(url)->str have what you might expect for POST? > I think you are right. > > >> I think that we should abandon auth-int, as noone else supports it (apache > >> doesn't [0] and neither does mozilla [1]. libneon once supported it, but > >> the code in question was removed in 2005 [2]). > >> > >> I am gonna update my code to reflect that fact. Any more thoughts? > I commented out the code in question (in case anyone wants to implement > it) and left a comment explaining the situation. > > If corvid is right and url->data->str contains all the information we > need this should be trivial to implement. I also located one server side > implementation of http digest auth with auth-int support written in PHP > [0]. I am going to set it up next week and give it a try. > > I published my http digest feature branch at [1] for your (and my) > convenience. If you have access to a site that uses http digest > authentication please give it a try. I'd also appreciate any comments > regarding the inclusion of the bsd licensed md5 implementation. Is that > an acceptable practice? I've just one minor comment for now: It would be nice if the password dialog would show the authentication method used. Or can one already see what is going to happen? Cheers, Johannes

April 9, 2009

http authentication: http digest

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 corvid wrote: > Justus wrote: >> On Wed, Apr 08, 2009 at 03:42:46AM +0000, corvid wrote: >>> Justus wrote: >>>> corvid wrote: >>>>>> * http digest can provide integrity protection for the request body >>>>>> by computing a hash over the request body, but I have no pointer to >>>>>> the request body, only the request URL. We might need to pass the >>>>>> whole request object (is there such a thing?) to the auth code instead >>>>>> of just the url. The code is there, just the pointer is missing. The >>>>>> code in auth.c will select the method without integrity protection for >>>>>> now, hoping that the server will accept both auth and auth-int. >>> *snip* > Does URL_DATA(url)->str have what you might expect for POST? I think you are right. >> I think that we should abandon auth-int, as noone else supports it (apache >> doesn't [0] and neither does mozilla [1]. libneon once supported it, but >> the code in question was removed in 2005 [2]). >> >> I am gonna update my code to reflect that fact. Any more thoughts? I commented out the code in question (in case anyone wants to implement it) and left a comment explaining the situation. If corvid is right and url->data->str contains all the information we need this should be trivial to implement. I also located one server side implementation of http digest auth with auth-int support written in PHP [0]. I am going to set it up next week and give it a try. I published my http digest feature branch at [1] for your (and my) convenience. If you have access to a site that uses http digest authentication please give it a try. I'd also appreciate any comments regarding the inclusion of the bsd licensed md5 implementation. Is that an acceptable practice? Justus 0: http://www.xiven.com/sourcecode/digestauthentication.php 1: http://teythoon.cryptobitch.de/devel/dillo/http-digest -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkndqvgACgkQoPmwNWhsaZYNpQCgtClBdvKwhcIR2gw61K2kUWpj jEIAoJNVBmQtfEKt3WUSNSxqsKYMb++I =rmhj -----END PGP SIGNATURE-----

April 9, 2009

Dillo + Partial Javascript Support

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 alsa F wrote: > Rather than somebody trying to get full Javascript suport for Dillo, I was thinking along the lines of partial Javascript support. The bare minimum would be to access websites that use Javascript to allow logins to forums etc. If any more functionality could be added so that for example social network sites like facebook or bebo then that would be great.On a personal note, I don't mind the lack of CSS when displaying pages on Dillo due to the small screen size of the minibook so any Javascript concerning that is not necessary. There are several free ecmascript interpreters available, choosing one of them and putting it into a dillo plugin is the easy part. But in order to be useful the script needs the ability to manipulate the page content. And designing that part right is hard... Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkndo70ACgkQoPmwNWhsaZYfHgCeIIA+fSBS9AZJTk93OeAUpIiG OIAAn38AnWLOAm1BgrHjKWkLLkexgIvM =USWg -----END PGP SIGNATURE-----

April 9, 2009

http authentication: http digest

by corvid＠lavabit.com

Justus wrote: > On Wed, Apr 08, 2009 at 03:42:46AM +0000, corvid wrote: > > Justus wrote: > > > corvid wrote: > > > >> * http digest can provide integrity protection for the request body > > > >> by computing a hash over the request body, but I have no pointer to > > > >> the request body, only the request URL. We might need to pass the > > > >> whole request object (is there such a thing?) to the auth code instead > > > >> of just the url. The code is there, just the pointer is missing. The > > > >> code in auth.c will select the method without integrity protection for > > > >> now, hoping that the server will accept both auth and auth-int. > > > > > > > > It sounds like entity-body is what you get _after_ dealing with the > > > > transfer coding (chunked) but _before_ dealing with the content > > > > coding (gzip). How annoying. It sounds like it would be necessary to > > > > hack some special field into the cache entry to be used when we see > > > > a WWW-Authenticate header, at least if it was gzipped... > > > Any hints on that one? > > > > The ever-growing CacheEntry_t would need an EntityBody field, and > > in a_Cache_process_dbuf, it would go something like > > if (entry->TransferDecoder) { > > dstr1 = a_Decode_process(entry->TransferDecoder, str, len); > > str = dstr1->str; > > len = dstr1->len; > > } > > if (entry->Auth) > > Dstr_append_l(entry->EntityBody, str, len); > > > > if (entry->ContentDecoder) { > > dstr2 = a_Decode_process(entry->ContentDecoder, str, len); > > str = dstr2->str; > > len = dstr2->len; > > } > > > > And then your code will need to call something like > > a_Cache_get_entity_body(url). > > Maybe I am the one being completly wrong here, but we're talking about the > request body, right? I wouldn't expect to find that that one in the cache... Oh, oh the request... (I don't really know the mechanics of auth at all yet, having felt content to have Jeremy and Justus as the auth experts :) Does URL_DATA(url)->str have what you might expect for POST? > I think that we should abandon auth-int, as noone else supports it (apache > doesn't [0] and neither does mozilla [1]. libneon once supported it, but > the code in question was removed in 2005 [2]). > > I am gonna update my code to reflect that fact. Any more thoughts? > > Justus > > 0: http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html#authdigestqop > 1: https://bugzilla.mozilla.org/show_bug.cgi?id=168942 > 2: $ grep -A 3 r462 neon27-0.28.2/ChangeLog > r462 | joe | 2005-01-27 22:04:44 +0000 (Thu, 27 Jan 2005) | 7 lines > > * src/ne_auth.c: Drop qop=auth-int support, sice it is universally > unimplemented by servers and comes with too much baggage. (struct

April 8, 2009