October 2008 - Dillo-dev - lists.mailman3.com

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

[patch] share button images between UIs

by Johannes.Hofmann＠gmx.de

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. Cheers, Johannes

Oct. 1, 2008