- Dillo-dev - lists.mailman3.com

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

CSS @import

by Johannes.Hofmann＠gmx.de

On Sun, Apr 05, 2009 at 04:49:16PM +0000, corvid wrote: > Johannes wrote: > > But first I'd like to fix the cyclic dependency. Maybe we can move > > a_Html_load_stylesheet() from html.cc to some other place? > > Perhaps some code could move to the bw. I've just committed my CSS @import work. It seems to work reliably here. The cyclic dependency is still unsolved. But I came to the conclusion that the whole concept of @import is somewhat cyclic :) Nevertheless I will try to move some code to bw as corvid suggested. Cheers, Johannes PS: Thanks for the reviews, corvid!

April 8, 2009

http authentication: http digest

by 4winter＠informatik.uni-hamburg.de

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

http authentication: http digest

by corvid＠lavabit.com

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). > corvid wrote: > > Oh, also...somewhere in there I noticed that an int was > > being set from a test for equality, with the result assumed > > to be 0 or 1. I might be wrong here, but I think C only > > specifies that you get 0 or nonzero. > Auth_unquote_value contained that assumption which I fixed. Was that the > part in question? Probably. > Any more comments on my patch? Just that I asked the search engine for "digest authentication 'entity-body'" and it gave me a bunch of people wondering what's supposed to happen when the entity-body is empty. So there's a weird test case for you.

April 8, 2009

Dillo + Partial Javascript Support

by matopoftheworld＠live.co.uk

Hi I have a cnm minibook which is part of a little Linux laptop family of mini laptops that use low powered Mipsel processors running Lnux. An unofficial site is here: http://linuxlaptopforum.ark2webdesign.co.uk/index.php One of the users has come up with a Linux distro called 3MX which uses IceWeseal but has also Dillo. The reason for this is because IceWeasel is a bit slow due to the low spec processor. Dillo runs far better than IceWeasel and would be an ideal replacement if it had the functionality of Javascript. 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. It is theoritcally possible as I use the noscript plugin on Firefox on my home PC which blocks javascript from certain 3rd party sites from running. I was wondering if anybody had any thoughts if the above is achievable and if so what would be the best Javascript engine to use with Dillo to achive this? Thanks in advance alsaf. _________________________________________________________________ Share your photos with Windows Live Photos ? Free. http://clk.atdmt.com/UKM/go/134665338/direct/01/

April 7, 2009

http authentication: http digest

by 4winter＠informatik.uni-hamburg.de

Skipped content of type multipart/mixed

April 7, 2009