- Dillo-dev - lists.mailman3.com

Re: Herba.l Products of the year, 2003
by Roberto.assente Jan. 15, 2004

Jan. 15, 2004

1 0

Re: spam-safe and basic auth
by Jorge Arellano Cid Jan. 7, 2004

Jan. 7, 2004

On Wed, 7 Jan 2004, Francis Daly wrote: > On Fri, Dec 19, 2003 at 05:45:50PM +0000, Francis Daly wrote: > > On Fri, Dec 12, 2003 at 06:32:54PM -0300, Jorge Arellano Cid wrote: > > > [...] > > > On to another topic, have you had a look at the basic > > > authentication patch by Madis and Tor? > > I've spent a few evenings on this now, and have through the mzz auth > patch, and tried implementing something similar myself. I don't see how > mzz avoids the "redirect loop" problem which it seems to generate. I got > the full mzz-wtab.diff file which applies cleanly to the 0.7.3 code, and > it compiled and ran okay, but failed to even ask for authentication when > I tried it against a 401 page. And it gave the "redirect loop" warning. > > So "doesn't work for me" is the best I can report about it for now, > unfortunately. I'm moving this thread to dillo-dev, just in case Madis or somebody else is interested in helping the development of this feature. > I believe that a 401-handler could be broadly analogous to the 30x > handler, Cache_redirect(). Within Cache_parse_header(), I set a new > value CA_Unauthorized for entry->Flags for a 401 response; and then > within Cache_process_queue(), if that value is set, call the new > Cache_reload_auth() just after where Cache_redirect() is called. Interesting idea. > For adding the Authorization: header, I just edit Http_query to > include an appropriate header if URL_RealmAccess is set (it's not used > elsewhere, and looks like it was intended for 401 usage); and within > Cache_reload_auth(), I set URL_RealmAccess and URL_E2EReload and call > a_Nav_push(). It seems to work fine for authentication pages with no > images, and for authentication pages with images which don't require > authentication. But images that *do* require authentication cause > breakage. Yes, a_Nav_push is for root urls (WEB_RootUrl). > The difficulty is in how to handle non-WEB_RootUrl requests -- I > was following Cache_redirect() for inspiration, and it appears that > Cache_redirect() just ignores them, and I don't see a clean way to > manage them. > > Why are sub entity redirections ignored? Is it because of > security/privacy concerns, or because it was difficult to do them > right? Because the only sub-entity type that dillo handles is image, and near 99% of image redirections is advertising, so given the state of the web, it's a feature! What could be done: my first thought is to check whether an URL (root or not) requires authentication (a flag). If it requires it and we have the auth cached, load it, if not, ignore. > If the former, then whatever the original plan was (using > a_Cache_open_url() or similar) would be worth learning. If the latter, > then unfortunately, in order to handle authentication it's going to have > to be addressed some time :-( Unfortunately I have little time to devote to this design, as I'm given priority to pushing the next release, that is, stabilizing the dpi framework (hopefully done), making the HTML warnings go into a window (not stdout), and adding an HTML error counter together with a "combat mode" parsing feature (a way to try to render pages full of errors in a simplistic but viewable way). Ah, and also giving a check to Keyb-nav-4 if it comes my way... > As I see it, the ideal situation would be that when Cache_parse_header() > finds the 401, it would be useful to check whether we have suitable > authentication credentials, and if so, initiate a new http request which > will feed into (and replace) the same "entry". Doing that directly, > though, probably cuts across too many layers of abstraction. Funny, quite the same I described above! No not that many layers. As you noticed, it can be viewed as a redirection (that asks for credentials on root pages.). It should be possible to implement it this way without breaking the current model. > (I did all my testing on the 0.7.3 codebase; I've just had a look at > CVS and it doesn't appear significantly different.) > > I'm quite happy to keep working on getting authentication working > (Basic, initially, but with the possibility of adding Digest or > anything else in the future) -- if you have any known-dead-ends from > implementing Cache_redirect, or ideas of "safe" ways to intercept the > cache handling, I'd appreciate hearing them. Try to prototype the idea above. It should work. Sorry for not being of more help by now. Cheers Jorge.-

1 0

Re: dillo configuration on AIX
by Jorge Arellano Cid Jan. 7, 2004

Jan. 7, 2004

On Wed, 7 Jan 2004, Riccardo wrote: > Hello, Hi! > I have a question whichmight be a short configuration question. I'm > trying to build dillo 0.7.3 on AIX 4.2.1 using gcc. I already installed > and tested gtk and pth. Pth is different from pthread (POSIX threads). > > when configuring dillo it says it can't find pthreads. In fact it tries > -pthread. I'm sure that AIX has native threads, Yes, but our configure doesn't detect them yet. Although this should not be hard to do: Get the detected target system type string from the configure script. That is, near the third line of output, it says something like: checking target system type... i586-pc-linux-gnu Then add that option to "configure.in" inside the case statement for pthreads. Something like: [...] case $target in *-*-linux*|*-*-solaris*) AC_CHECK_LIB(pthread, pthread_create) ;; + *-*-aix*) + AC_CHECK_LIB(pthreads, pthread_create) + ;; [...] Then follow the directives at: http://home.t-online.de/home/Andreas.Steinmetz/unix/pthreads.html That is basically adding a call to pthread_init() somewhere in main() in dillo.c. Run autoreconf or autogen.sh, configure, make, tweak and send some feedback! :-) > but in any case -lpth > should be used to use libpth. I'm not an expert with AIX development, > I'm using version 4.2.1. > Can dillo be linked against lpth? other projects usually have a > configure option top select the threading model. Against Pth, no. Cheers Jorge.-

2 1

MINISTRY OF MINES AND NATURAL RESOURCES,SIERRA-LEONE
by BRIGEDIER EVANS GIWA Jan. 7, 2004

Jan. 7, 2004

Dear sir, I PRESUME THIS LETTER WILL NOT BE A SURPRISE TO YOU. I am Brigedier Evans Giwa, a soldier by profession, formerly a director with the ministry of Mines and Natural Resources in SIERRA-LEONE before the out - break of the civil war in Sierra-Leone. When I was the director with that ministry, I acted as a link between foreign buyers of Diamonds and the Sierra-Leonian government, but ae a result of the civil war, I diverted the sum of US$36.5 million meant for Sierra-Leone government to a security company in Europe. All I need from you.: (1)Coming up with a viable business that we can invest this fund in. (2)To act as the beneficiary of the said money, as I cannot act in this capacity as I`m still directly or indirect involved in the peace negotiations going on in my country now. (3)To clear the money with the security company in Europe and lodge the money into an account we shall both run. After acknowledging this letter,and indicating your interest and willingness in my proposals, we shall arrange for a meeting in Europe to discuss your areas of interest and investment. As a christain, I will like to invest 20%of the money to help the less priviledged in the society.You willget 25% of the total money for your assistance and 5% will be set aside to offset whatever expenses incurred during the duratation of this transaction. Do kindly contact me through the below email address for further discussion and forsecurity reasons,this business remains confidential. Your Sincerly Brigedier. Evans Giwa giwa(a)consultant.com or egiwa(a)lycos.com

1 0

Improved stability patch for dpi framework!
by Jorge Arellano Cid Jan. 5, 2004

Jan. 5, 2004

Hi Ferdi, (et all) After spending the last weeks hunting for some bugs in the dpi framework deeply, I've succeeded to track them down, and finally, to fix them! From time to time there were multiple dpid instances, this was due to a race condition while waiting for dpid to be "online"; if the process took around a second, dillo could end launching multiple instances of the daemon (I left a commented sleep in the dpid code that served to reliably reproduce it). Another nasty bug was that sometimes dillo crash-locked when requesting a dpi service, for instance: launch dillo -> ask for bm -> kill dpid -> ask for bm -> crash ...this was because of FD inheritance! The bm dpi survived, and kept its parent's FD open, so the connect-test succeeded but there was no server to answer. This couple was really hard to track. As a by-product, lsof showed a FD leak in dpi.c (one per dpi request) and another for dillorc. All of these bugs are fixed in CVS. The good news is that this is a big step towards 0.8.0 release because the stabilization of the dpi-framework is a necessity. There is still at least one pending thing to polish, but it is not a big problem to live with it in 0.8.0 because it causes little harm. This is: if dpid crashes (or is killed), the dpi servers will survive, but the new dpid will launch new processes for them (the old ones will last until their bore-time is reached). No crash, no locks. My first idea was to make a connection-test to dpi servers from dpid at start time, but unfortunately, the parent-child relationship would be lost for the second dpid, so we have to find another way to tell dpid that a dpi-server has finished. The "srs" may be used, although it may be a bit tricky to do when the dpi server has crashed; anyway, the connection test from dpid can detect the crash and bypass the old server with a new one. Cheers Jorge.-

1 0

Re: dillo 0.73 not compiling on slackware 3.9 ( libc5 )
by Jorge Arellano Cid Jan. 4, 2004

Jan. 4, 2004

On Sat, 3 Jan 2004, matti christensen wrote: > Hello ! Hi! > > In Your README You asked to email comments on compiling Dillo on libc5, > and here's some of mine. Good, the first in a long time. > - slackware 3.9 is the last one with libc5 ( glibc 2.0.7pre6 ) and ( gcc > 2.7.23 ) No problem, I use slackware, and have deployed dillo on it in much earlier versions. > - kernel is the latest of 2.0 -series ( 2.0.39 ) which i have compiled > according to attached config and dmesg > > - i also compiled following in for Dillo ;o) > > --- XFree 3.3.6 > --- glib 1.2.9 > --- gtk+ 1.2.9 > --- jpeg-6b > --- libpng 1.2.5 > --- libtiff 3.5.7 > --- zlib 1.1.4 > > - when i try to make Dillo after making the changes to dns.c as You kindly > adviced, compiling stops to src/IO/mime.c saying "mime.c:34: parse error > before `static'" OK. It seems to be the G_GNUC_UNUSED directive. Remove lines 31 to 40 in mime.c. It should stop complaining about mime.c. If this is true, as I do expect, do the same with html.c and IO/Url.c. Please report me how it goes to fix it in current CVS. Cheers Jorge.-

1 0

Best wishes for year 2004
by Jorge Arellano Cid Dec. 31, 2003

Dec. 31, 2003

Hi There, It's early in the morning here in Chile, and I know that in Europe the clock is around 4 to 6 hours ahead, hopefully still in time to send my greetings and best wishes to all the people scattered around the world that participate of dillo-dev. Somewhere inside this december the Dillo project completed four years of existence and continued development. Please excuse me for not displaying a birthday cake picture at the home page; I didn't have the time, but the will to share and celebrate the event still remains! I spent the last months of this year making the arrangements to be able to keep working on dillo the 2004, and hopefully more... It seems that these efforts will flourish and let me work through this new year with renewed energies and hope: let 2004 be a great year for the Dillo project! Cheers & Best wishes to all! Jorge.-

1 0

VRML support in Dillo
by Rich3800＠aol.com Dec. 30, 2003

Dec. 30, 2003

Does Dillo support display of VRML images?

2 1

WINNING NOTIFICATION/FINAL NOTICE
by MR. TOM VANAD Dec. 27, 2003

Dec. 27, 2003

RABOAS INTERNATIONAL LOTTERY NTERNATIONAL PROMOTION/PRIZE AWARD DEPT. HOLLAND REFF: OGS/7316786098/03 BATCH: 14/055/IPD /NL WINNING NOTIFICATION/FINAL NOTICE We are pleased to inform you of the result of the RABOAS Lottery International programs held on the 27st of Decbmer 2003. Your e-mail address attached to ticket number 4411465886-629 with serial number 3772-99 drew lucky numbers 7-14-17-23-31-44 which consequently won in the 2nd category, you have therefore been approved for a lump sum pay out of US$100,000.(One Hundred Thousand Dollars)CONGRATULATIONS!!! Due to mix up of some numbers and names, we ask that you keep your winning information confidential untill your claims has been processed and your money remitted into your accaunt. This is part of our security protocol to avoid double claiming and unwarranted abuse of this program by some participants All participants were selected through a computer ballot system drawn from over 100,000 company and 50,000,000 individual email addresses and names from all over the world. This promotional program take place every three years. We hope with part of your winning you will take part in our end of year 50 million Dollars international lottery. To file for your claim,please contact our fiduciary agent MR.DALE MELLOR, E.U.INTERNATIONAL B.V E.mail:dalemell@netscape.net TEL:31 641 684 576 Remember, all winning must be claimed not later than 11 th of January 2004. After this date all unclaimed funds will be included in the next take Please note in order to avoid unnecessary delays and complications please remember to quote your reference number and batch numbers in all correspondence. Furthermore,should there be any change of address do inform our agent as soon as possible.Congratulations once more! from our members of staff and thank you for being part of our promotional program. Note: Anybody under the age of 18 is automatically disqualified. Sincerely yours, MR. TOM VANAD (Winning Co-ordinator)

1 0

Re: spam-safe and basic auth
by Jorge Arellano Cid Dec. 26, 2003

Dec. 26, 2003

Hi Francis, > [...] > > I was just looking for the spam-safe image blocking patch and > > couldn't find it. Would you mind resending it to me? > > No problem at all. It's included below, updated for current CVS (the > earlier version applied cleanly with a 126-line offset). > > The same caveats as before apply -- there is no "right" answer, so the > choice between omitting the image entirely, faking a submit button, > including a default image, or something else, is pretty arbitrary. > > Faking a submit button is what I went for here, taking inspiration > from http://www.htmlhelp.com/reference/html40/forms/input.html#image > and http://ppewww.ph.gla.ac.uk/~flavell/alt/type-image.html > > If you prefer a different option, I'm sure you're well capable of > coding it ;-) I took the text-submit-button approach (it will also serve for when browsing in "text mode" with Dillo). It took me some time to review it (looks simple but it's not!), I also had to fix a bug... Cheers Jorge.- PS: further testing is welcome! ;)

1 0