- Dillo-dev - lists.mailman3.com

Basic authentication

by Christian.Kellermann＠nefkom.net

* corvid <corvid(a)lavabit.com> [081002 06:41]: > Christian wrote: > > Dear List, > > > > since I have not found any traces of discussion on this list about > > this topic I dare to ask where to place code handling basic > > authentication in dillo's source? As I see it the cache module is > > responsible for handling server responses. So I would at a first > > try add the code there. How can I connect to a UI dialog from here > > to get the necessary credentials? Maybe a possible solution looks > > like this: > > > > - react to 403 header and look for Authorization request > > - if there is one ask the user for username/pass > > + resend the request with the Authorisation header added > > + or display the 403 if the user aborts > > > > > > What do you think? I will come up with some example code to illustrate > > the idea in case this is not very clear. > > (We'll see what Jorge has to say, but...) > cache.c seems like the right place to me, with a dialog called by way of > uicmd.cc. The auth data would be stored away somewhere (a new file?), > which a_Http_make_query_str() could call like it calls a_Cookies_get_query(). > This sounds good. What I am thinking about at the moment is how to keep the user/password combination attached to a certain URL for future reference? As I see it the connection structure gets dropped as soon as the transfer of one entity is finished... To be more specific I have been trying something like this: Index: src/cache.c =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/src/cache.c,v retrieving revision 1.33 diff -b -u -p -r1.33 cache.c --- src/cache.c 14 Sep 2008 20:26:08 -0000 1.33 +++ src/cache.c 2 Oct 2008 07:13:11 -0000 @@ -617,7 +617,7 @@ static Dlist *Cache_parse_multiple_field static void Cache_parse_header(CacheEntry_t *entry) { char *header = entry->Header->str; - char *Length, *Type, *location_str, *encoding, *charset; + char *Length, *Type, *location_str, *encoding, *charset, *auth; #ifndef DISABLE_COOKIES Dlist *Cookies; #endif @@ -657,6 +657,23 @@ static void Cache_parse_header(CacheEntr } dFree(location_str); + } else if (strncmp(header + 9, "401", 3) == 0) { + auth = Cache_parse_field(header, "WWW-Authenticate"); + if ( auth ) { + if (strncmp(auth, "Basic", 5) == 0) { + entry->Flags |= CA_AuthNeeded; + entry->Flags |= CA_AuthBasic; + MSG_HTTP("Basic Authentication request\n"); + } else if (strncmp(auth, "Digest", 6) == 0) { + entry->Flags |= CA_AuthNeeded; + entry->Flags |= CA_AuthDigest; + MSG_HTTP("Digest Authentication request\n"); + } else { + MSG_ERR("Unknown authentication method in request " + "'%s'.\n", auth); + } + MSG_HTTP(" for %s!\n", URL_STR(entry->Url)); + } } else if (strncmp(header + 9, "404", 3) == 0) { entry->Flags |= CA_NotFound; } @@ -1037,6 +1054,11 @@ static void Cache_process_queue(CacheEnt entry->ExpectedSize / (1024*1024)); AbortEntry = OfferDownload = TRUE; } + if (entry->Flags & CA_AuthNeeded) { + if (!Client->Callback) { + Client->Callback = Cache_null_client; + } + } } else { /* For non root URLs, ignore redirections and 404 answers */ if (entry->Flags & CA_Redirect || entry->Flags & CA_NotFound) Index: src/cache.h =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/src/cache.h,v retrieving revision 1.5 diff -b -u -p -r1.5 cache.h --- src/cache.h 2 Jun 2008 02:27:43 -0000 1.5 +++ src/cache.h 2 Oct 2008 07:13:11 -0000 @@ -33,6 +33,9 @@ extern "C" { #define CA_InternalUrl 0x800 /* URL content is generated by dillo */ #define CA_HugeFile 0x1000 /* URL content is too big */ #define CA_IsEmpty 0x2000 /* True until a byte of content arrives */ +#define CA_AuthNeeded 0x4000 /* Set if server requests authentication */ +#define CA_AuthBasic 0x8000 /* Set if server requests basic authentication */ +#define CA_AuthDigest 0x10000 /* Set if server requests digest authentication */ /* * Callback type for cache clients The bit in Cache_process_queue should be the place where the handling is done, at least so I thought. Maybe that is not a good idea... Also I am a but uneasy with introducing new flags but it somehow fits the overall scheme. Any suggestions? Kind regards, Christian P.S.: This patch is a work in progress and more of an example than anything. -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Oct. 2, 2008

Basic authentication

by corvid＠lavabit.com

Christian wrote: > Dear List, > > since I have not found any traces of discussion on this list about > this topic I dare to ask where to place code handling basic > authentication in dillo's source? As I see it the cache module is > responsible for handling server responses. So I would at a first > try add the code there. How can I connect to a UI dialog from here > to get the necessary credentials? Maybe a possible solution looks > like this: > > - react to 403 header and look for Authorization request > - if there is one ask the user for username/pass > + resend the request with the Authorisation header added > + or display the 403 if the user aborts > > > What do you think? I will come up with some example code to illustrate > the idea in case this is not very clear. (We'll see what Jorge has to say, but...) cache.c seems like the right place to me, with a dialog called by way of uicmd.cc. The auth data would be stored away somewhere (a new file?), which a_Http_make_query_str() could call like it calls a_Cookies_get_query().

Oct. 2, 2008

what crashes remain?

by jcid＠dillo.org

On Wed, Oct 01, 2008 at 11:11:23PM +0200, Johannes Hofmann wrote: > On Wed, Oct 01, 2008 at 03:01:19PM -0400, Jorge Arellano Cid wrote: > > On Wed, Oct 01, 2008 at 06:14:47PM +0200, Johannes Hofmann wrote: > > > On Wed, Oct 01, 2008 at 11:45:53AM -0400, Jorge Arellano Cid wrote: > > > > On Wed, Oct 01, 2008 at 04:47:05PM +0200, Johannes Hofmann wrote: > > > > > Hi, > > > > > > > > > > On Wed, Oct 01, 2008 at 10:33:20AM -0400, Jorge Arellano Cid wrote: > > > > > > Hi, > > > > > > > > > > > > On Sat, Sep 27, 2008 at 05:38:03PM -0400, Jorge Arellano Cid wrote: > > > > > > > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > > > > > > > It's still possible to crash dillo if you click on a remote link and > > > > > > > > quickly click on some images to load them. Doesn't crash every time, > > > > > > > > but typically within four tries or so. I had assumed it was the same > > > > > > > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > > > > > > > > > > > > > If I stick > > > > > > > > a_Bw_stop_clients(bw, BW_Img); > > > > > > > > in the DilloHtml destructor, I can no longer get it to crash, but > > > > > > > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > > > > > > > earlier today, so there's something wrong with just doing that. > > > > > > > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > > > > > > > > > > > > > That message means big trouble: the event loop stepped over itself... > > > > > > > > > > > > > > I've tried several different ways but can't get to crash it. > > > > > > > > > > > > > > Does the attached patch help? > > > > > > > > > > > > > > -- > > > > > > > Cheers > > > > > > > Jorge.- > > > > > > > > > > > > > diff -pru dillo2/src/html.cc dillo2-cur/src/html.cc > > > > > > > --- dillo2/src/html.cc 2008-09-27 15:11:08.000000000 -0400 > > > > > > > +++ dillo2-cur/src/html.cc 2008-09-27 17:34:21.000000000 -0400 > > > > > > > @@ -711,6 +711,8 @@ bool_t DilloHtml::unloadedImages() > > > > > > > */ > > > > > > > void DilloHtml::loadImages (const DilloUrl *pattern) > > > > > > > { > > > > > > > + dReturn_if_fail (bw->nav_expecting == FALSE); > > > > > > > + > > > > > > > for (int i = 0; i < images->size(); i++) { > > > > > > > if (images->get(i)->image) { > > > > > > > if ((!pattern) || (!a_Url_cmp(images->get(i)->url, pattern))) { > > > > > > > > > > > > Can you still crash dillo this way, with the latest CVS? > > > > > > (i.e. without the above patch). > > > > > > > > > > I'm currently seeing all sorts of crashes and I suspect that they > > > > > are related to xpmImage from fltk. > > > > > Could someone with a linux machine please check current dillo with > > > > > valgrind especially when the new mini_bug_xpm is shown? > > > > > > > > > > Also changing mini_bug_xpm to 15x15 seems to fix things for me. > > > > > I don't understand all that completely, but other crashes might be > > > > > related to this. > > > > > > > > OK, I'll check with valgrind... > > > > Does changing mini_ok_xpm to 16x16 fix it too? > > > > > > No it doesn't, that's what I thought first too :-) > > > > > > But it really only happens when fltk was compiled with > > > --disable-xft > > > > I did that and FLTK's tests don't use xft, but my > > dillo-fltk still uses them! > > > > Did you call ./configure for dillo again? Yes. I forgot to make install FLTK, now it works. :) > > > > > > > BTW, does a: > > > > - new_w = strlen(str)*8 + 20; > > + new_w = strlen(str)*8 + 40; > > > > in ui.cc solve the problem for you? > > No, it doesn't. I think it's a fltk problem. Yes, valgrind reports an invalid write of size 1. See the attached file. It looks like unless FLTK2 is patched, we'll have a w=15 minibug as workaround. -- Cheers Jorge.-

Oct. 2, 2008

what crashes remain?

by corvid＠lavabit.com

Jorge wrote: > On Wed, Oct 01, 2008 at 09:46:06PM +0000, corvid wrote: > > Jorge wrote: > > > On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote: > > > > Also, I found out why loading was sometimes randomly disabled (as mentioned > > > > yesterday). You know how leaving the window sometimes causes an extra > > > > Nav_open_url()? > > > > > > No, I don't know. > > > How is it triggered? > > > > Really? I've gotten them often throughout this whole fltk era. > > Taking out my fix, here's a breakpoint on Nav_open_url, > > triggered by leaving the window: > > > > Breakpoint 1, Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > > 201 MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); > > #0 Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > > #1 0x0805cd4d in a_Nav_push (bw=0x81b18e8, url=0x81c3998) at nav.c:350 > > #2 0x080554ae in a_UIcmd_open_urlstr (vbw=0x81b18e8, urlstr=0x81c44b8 "http://www.dillo.org") at uicmd.cc:323 > > #3 0x08053c12 in location_cb (wid=0x816c6a8, data=0x815c2d8) at ui.cc:245 > > #4 0x08055fa7 in fltk::Widget::do_callback (this=0x816c6a8) at ../fltk/Widget.h:127 > > #5 0x080e093c in call_pending_if_not (i=0x0) at run.cxx:804 > > #6 0x080e124c in fltk::focus (o=0x0) at run.cxx:868 > > #7 0x080e56f4 in fix_focus () at run.cxx:108 > > #8 0x080e676f in fltk::handle () at x11/run.cxx:1603 > > #9 0x080e7520 in do_queued_events () at x11/run.cxx:399 > > #10 0x080e784c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 > > #11 0x080e78e7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 > > #12 0x080e79fe in fltk::run () at run.cxx:399 > > #13 0x0804efab in main (argc=1, argv=0xbffffb34) at dillo.cc:127 > > From the bt it's clear it happens, But how do I trigger/reproduce it. > I've tried moving the mouse pointer out of the window, focusing another > window, etc. With no luck. The reliable way that I'm using (haven't checked how many of these steps/precautions are strictly necessary) - type an url into the Location CustInput and press enter. - don't touch the mouse - when the page has finished loading completely - move the mouse out of the window In case there's some WM interaction, I have fvwm.

Oct. 2, 2008

what crashes remain?

by jcid＠dillo.org

On Wed, Oct 01, 2008 at 09:46:06PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote: > > > Also, I found out why loading was sometimes randomly disabled (as mentioned > > > yesterday). You know how leaving the window sometimes causes an extra > > > Nav_open_url()? > > > > No, I don't know. > > How is it triggered? > > Really? I've gotten them often throughout this whole fltk era. > Taking out my fix, here's a breakpoint on Nav_open_url, > triggered by leaving the window: > > Breakpoint 1, Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > 201 MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); > #0 Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > #1 0x0805cd4d in a_Nav_push (bw=0x81b18e8, url=0x81c3998) at nav.c:350 > #2 0x080554ae in a_UIcmd_open_urlstr (vbw=0x81b18e8, urlstr=0x81c44b8 "http://www.dillo.org") at uicmd.cc:323 > #3 0x08053c12 in location_cb (wid=0x816c6a8, data=0x815c2d8) at ui.cc:245 > #4 0x08055fa7 in fltk::Widget::do_callback (this=0x816c6a8) at ../fltk/Widget.h:127 > #5 0x080e093c in call_pending_if_not (i=0x0) at run.cxx:804 > #6 0x080e124c in fltk::focus (o=0x0) at run.cxx:868 > #7 0x080e56f4 in fix_focus () at run.cxx:108 > #8 0x080e676f in fltk::handle () at x11/run.cxx:1603 > #9 0x080e7520 in do_queued_events () at x11/run.cxx:399 > #10 0x080e784c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 > #11 0x080e78e7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 > #12 0x080e79fe in fltk::run () at run.cxx:399 > #13 0x0804efab in main (argc=1, argv=0xbffffb34) at dillo.cc:127 From the bt it's clear it happens, But how do I trigger/reproduce it. I've tried moving the mouse pointer out of the window, focusing another window, etc. With no luck. -- Cheers Jorge.-

Oct. 2, 2008

what crashes remain?

by corvid＠lavabit.com

Jorge wrote: > On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote: > > Also, I found out why loading was sometimes randomly disabled (as mentioned > > yesterday). You know how leaving the window sometimes causes an extra > > Nav_open_url()? > > No, I don't know. > How is it triggered? Really? I've gotten them often throughout this whole fltk era. Taking out my fix, here's a breakpoint on Nav_open_url, triggered by leaving the window: Breakpoint 1, Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 201 MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); #0 Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 #1 0x0805cd4d in a_Nav_push (bw=0x81b18e8, url=0x81c3998) at nav.c:350 #2 0x080554ae in a_UIcmd_open_urlstr (vbw=0x81b18e8, urlstr=0x81c44b8 "http://www.dillo.org") at uicmd.cc:323 #3 0x08053c12 in location_cb (wid=0x816c6a8, data=0x815c2d8) at ui.cc:245 #4 0x08055fa7 in fltk::Widget::do_callback (this=0x816c6a8) at ../fltk/Widget.h:127 #5 0x080e093c in call_pending_if_not (i=0x0) at run.cxx:804 #6 0x080e124c in fltk::focus (o=0x0) at run.cxx:868 #7 0x080e56f4 in fix_focus () at run.cxx:108 #8 0x080e676f in fltk::handle () at x11/run.cxx:1603 #9 0x080e7520 in do_queued_events () at x11/run.cxx:399 #10 0x080e784c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 #11 0x080e78e7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 #12 0x080e79fe in fltk::run () at run.cxx:399 #13 0x0804efab in main (argc=1, argv=0xbffffb34) at dillo.cc:127

Oct. 1, 2008

[patch] share button images between UIs

by jcid＠dillo.org

On Wed, Oct 01, 2008 at 10:54:41PM +0200, Johannes Hofmann wrote: > On Wed, Oct 01, 2008 at 04:38:42PM -0400, Jorge Arellano Cid wrote: > > On Wed, Oct 01, 2008 at 02:58:44PM -0400, Jorge Arellano Cid wrote: > > > On Wed, Oct 01, 2008 at 07:36:54PM +0200, Johannes Hofmann wrote: > > > > Hi, > > > > > > > > this is independent from the recent crashes. > > > > This patch shares the images between multiple UIs. > > > > > > > > What do you think? > > > > > > Committed! > > > > > > Except that "img on/off" doesn't switch the icon. > > > Please send me a patch for this. > > > > Don't worry, it's fixed in CVS now. > > > > Ah thanks. A similar fix is necessary for small icons. > Patch attached. Committed. -- Cheers Jorge.-

Oct. 1, 2008

an experiment regarding cross site request forgery

by corvid＠lavabit.com

Justus wrote: > Johannes Hofmann wrote: > > Perhaps we should be more careful when to send out a cookie. > > What about not sending cookies with image requests, if the host of > > the image url is different from the one in the main page? > > What do other browser do about this? > > Yes, I think this is the way to go. One need to decide when to send out > authentication credentials (legitimate session) and when to strip them > (CSRF attempt). Martin Johns and I developed a firefox extension [0] > that does exactly this. Please see [1] pages 29 - 37 or [2] for more > information. [1] is also a pretty good introduction to CSRF. Please note > that the browser independent proxy solution is deprecated (but should > work unless the twisted framework changed its api too much) and the > firefox extension is somewhat unmaintained at the moment... Having done some reading now: So for an HTTP redirect or an image request, A->B, I gather up the cookies that I would send when asking for B and discard those that I would not send if I were asking for A?

Oct. 1, 2008

what crashes remain?

by Johannes.Hofmann＠gmx.de

On Wed, Oct 01, 2008 at 03:01:19PM -0400, Jorge Arellano Cid wrote: > On Wed, Oct 01, 2008 at 06:14:47PM +0200, Johannes Hofmann wrote: > > On Wed, Oct 01, 2008 at 11:45:53AM -0400, Jorge Arellano Cid wrote: > > > On Wed, Oct 01, 2008 at 04:47:05PM +0200, Johannes Hofmann wrote: > > > > Hi, > > > > > > > > On Wed, Oct 01, 2008 at 10:33:20AM -0400, Jorge Arellano Cid wrote: > > > > > Hi, > > > > > > > > > > On Sat, Sep 27, 2008 at 05:38:03PM -0400, Jorge Arellano Cid wrote: > > > > > > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > > > > > > It's still possible to crash dillo if you click on a remote link and > > > > > > > quickly click on some images to load them. Doesn't crash every time, > > > > > > > but typically within four tries or so. I had assumed it was the same > > > > > > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > > > > > > > > > > > If I stick > > > > > > > a_Bw_stop_clients(bw, BW_Img); > > > > > > > in the DilloHtml destructor, I can no longer get it to crash, but > > > > > > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > > > > > > earlier today, so there's something wrong with just doing that. > > > > > > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > > > > > > > > > > > That message means big trouble: the event loop stepped over itself... > > > > > > > > > > > > I've tried several different ways but can't get to crash it. > > > > > > > > > > > > Does the attached patch help? > > > > > > > > > > > > -- > > > > > > Cheers > > > > > > Jorge.- > > > > > > > > > > > diff -pru dillo2/src/html.cc dillo2-cur/src/html.cc > > > > > > --- dillo2/src/html.cc 2008-09-27 15:11:08.000000000 -0400 > > > > > > +++ dillo2-cur/src/html.cc 2008-09-27 17:34:21.000000000 -0400 > > > > > > @@ -711,6 +711,8 @@ bool_t DilloHtml::unloadedImages() > > > > > > */ > > > > > > void DilloHtml::loadImages (const DilloUrl *pattern) > > > > > > { > > > > > > + dReturn_if_fail (bw->nav_expecting == FALSE); > > > > > > + > > > > > > for (int i = 0; i < images->size(); i++) { > > > > > > if (images->get(i)->image) { > > > > > > if ((!pattern) || (!a_Url_cmp(images->get(i)->url, pattern))) { > > > > > > > > > > Can you still crash dillo this way, with the latest CVS? > > > > > (i.e. without the above patch). > > > > > > > > I'm currently seeing all sorts of crashes and I suspect that they > > > > are related to xpmImage from fltk. > > > > Could someone with a linux machine please check current dillo with > > > > valgrind especially when the new mini_bug_xpm is shown? > > > > > > > > Also changing mini_bug_xpm to 15x15 seems to fix things for me. > > > > I don't understand all that completely, but other crashes might be > > > > related to this. > > > > > > OK, I'll check with valgrind... > > > Does changing mini_ok_xpm to 16x16 fix it too? > > > > No it doesn't, that's what I thought first too :-) > > > > But it really only happens when fltk was compiled with > > --disable-xft > > I did that and FLTK's tests don't use xft, but my > dillo-fltk still uses them! > Did you call ./configure for dillo again? > > > BTW, does a: > > - new_w = strlen(str)*8 + 20; > + new_w = strlen(str)*8 + 40; > > in ui.cc solve the problem for you? No, it doesn't. I think it's a fltk problem. Cheers, Johannes

Oct. 1, 2008

what crashes remain?

by jcid＠dillo.org

On Sat, Sep 27, 2008 at 11:15:42PM +0000, corvid wrote: > Jorge wrote: > > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > > It's still possible to crash dillo if you click on a remote link and > > > quickly click on some images to load them. Doesn't crash every time, > > > but typically within four tries or so. I had assumed it was the same > > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > > > If I stick > > > a_Bw_stop_clients(bw, BW_Img); > > > in the DilloHtml destructor, I can no longer get it to crash, but > > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > > earlier today, so there's something wrong with just doing that. > > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > > > That message means big trouble: the event loop stepped over itself... > > > > I've tried several different ways but can't get to crash it. > > > > Does the attached patch help? > > Seems to be working well so far. > Is there any danger in adding something like > a_Nav_cancel_expect to a_UIcmd_stop()? It looks safe to do. It even looks like the right thing to do. Just committed: - Disallowed loading images when expecting is set. - Added a cancel_expect call to the Stop button. -- Cheers Jorge.-

Oct. 1, 2008