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

[patch]: Basic Authentication

by onepoint＠starurchin.org

On Thu, Dec 04, 2008 at 01:36:39PM +0100, Joerg Sonnenberger wrote: > Have you thought about how other protocols can be integrated with > this? No, except that I've deliberately made the User/Password dialog generic so that any other code can reuse it with a different callback. Other than that I think that all of my code is entirely specific to HTTP Basic authentication. I can't see how other protocols could be integrated with it in any useful sense. But my opinion doesn't count for much since I know next to nothing about how those other protocols work! > Examples are: > - TLS with client side authentication or verification for the server > certificate I have no idea how this works. Every time I try to study certificates and authentication my head starts spinning and I have to lie down. Does anyone know of some gentle introductions? > - non-anonymous FTP The FTP DPI could check the output of wget. If wget complained that the FTP server needed authentication than it could pop up the user/password dialog with a callback that retries the wget. The download DPI would have to be modified to receive the user and password. (Or we could stuff them into the download URL, but that's insecure since the password would appear in the process listing.) We would have to extend the DPI API to let DPIs use the user/password dialog but that is straightforward (I already implemented it when I thought authentication was going to be a DPI). Regards, Jeremy Henty

Dec. 4, 2008

css progress

by Johannes.Hofmann＠gmx.de

On Thu, Dec 04, 2008 at 08:13:49AM +0900, furaisanjin wrote: > Hi, > > > For now you could set force_my_colors=YES in dillorc. > > That wold be one way to avoid the problem but another issue is we > can't change dillo config on the fly, so I have to start dillo up if I > want to do so. If I keep force_my_colors=YES, dillo appearance looks > bad. That's true. I just checked your example page and it seems to look better with the current CSS prototype. The letters are visible - but still not readable for me ;-) Regards, Johannes

Dec. 4, 2008

[patch]: Basic Authentication

by joerg.sonnenberger＠web.de

On Thu, Dec 04, 2008 at 11:11:03AM +0000, Jeremy Henty wrote: > Opening the authentication dialog runs the FLTK event loop, which > means that incoming data can call the cache again, triggering CCC > warnings. We work around it by deferring the dialog to a timeout so > that the cache finishes iterating over the clients before the dialog > appears. This is annoying but I don't see a better way at the moment. Have you thought about how other protocols can be integrated with this? Examples are: - TLS with client side authentication or verification for the server certificate - non-anonymous FTP Joerg

Dec. 4, 2008

[patch]: Basic Authentication

by onepoint＠starurchin.org

OK, here it is. Please comment. Some observations: When the cache parses the HTTP header we just attach any authentication headers to the cache entry. Nothing else happens until we process the clients. Just before iterating over the clients we check if all the data is in. If it is then we do any necessary authentication. Opening the authentication dialog runs the FLTK event loop, which means that incoming data can call the cache again, triggering CCC warnings. We work around it by deferring the dialog to a timeout so that the cache finishes iterating over the clients before the dialog appears. This is annoying but I don't see a better way at the moment. The authentication dialog does not know which browser window opened the URL so it can't call a_Nav_reload(). Instead I implemented a_Nav_reload_url(). There's an interesting case when the server demands authentication for a realm that we have already authenticated ourselves to. It could be that we didn't send authentication because we didn't know the path was in the realm, or it could be that the authentication we sent was wrong. This requires the code to deduce what it did last time it saw this URL and rely on what it will do the next time. It works, but it feels fragile to me. I would prefer the URL to explicitly record authentication attempts so that the code doesn't have to second-guess itself. Thoughts? I implemented a full token-value list parser as per the RFC. Maybe this is overkill for Basic authentication, but it will be necessary for Digest authentication. Yes, it has gotos; I began by setting flags but decided that gotos were actually cleaner. Maybe it should be rewritten in state-machine style? If the user opens several pages in a realm in a very short time then it is conceivable that multiple authentication dialogs for the same realm could pop up (just like the https DPI sometimes does with certificate dialogs). I don't address this at the moment because I think it won't be a problem in practice. If it needs fixing then we will have to monitor the list of currently open dialogs to avoid duplicates. Regards, Jeremy Henty

Dec. 4, 2008

css progress

by furaisanjin＠gmail.com

Hi, > For now you could set force_my_colors=YES in dillorc. That wold be one way to avoid the problem but another issue is we can't change dillo config on the fly, so I have to start dillo up if I want to do so. If I keep force_my_colors=YES, dillo appearance looks bad. Regards, furaisanjin

Dec. 4, 2008

css progress

by Johannes.Hofmann＠gmx.de

On Wed, Dec 03, 2008 at 11:20:53AM +0900, furaisanjin wrote: > Hi, > > One strong demand is that there are pages whose font color and > background color are same in plain HTML but are changed in CSS. In > this case we can't see any text at all. > > This is one example page. http://www.nhk.or.jp/archives/radiodrama/ For now you could set force_my_colors=YES in dillorc. Regards, Johannes

Dec. 3, 2008

css progress

by furaisanjin＠gmail.com

Hi, One strong demand is that there are pages whose font color and background color are same in plain HTML but are changed in CSS. In this case we can't see any text at all. This is one example page. http://www.nhk.or.jp/archives/radiodrama/ Regards, furaisanjin

Dec. 3, 2008

dialog to change charset

by joerg.sonnenberger＠web.de

On Tue, Dec 02, 2008 at 07:12:45PM +0000, corvid wrote: > > You don't have to hard-code it -- read it on startup, it is not more > > than a mapping between user-visible name (hierachical?) and system > > string. That approach also has the advantage of making it easily > > tweakable for admins/packagers/users. > > You're saying a new file in .dillo/ ? Global configuration file referenced in .dillorc, if you want to override the default: copy & adjust link. Joerg

Dec. 2, 2008

dialog to change charset

by corvid＠lavabit.com

Joerg wrote: > On Tue, Dec 02, 2008 at 04:50:06PM +0000, corvid wrote: > > I hadn't bothered to look at the list in Firefox because I thought > > it would certainly be eight miles -- sorry, kilometres -- long, > > but actually it's not so bad. A list that size could fit into dillo. > > I'll try making one that does as you suggest. > > You don't have to hard-code it -- read it on startup, it is not more > than a mapping between user-visible name (hierachical?) and system > string. That approach also has the advantage of making it easily > tweakable for admins/packagers/users. You're saying a new file in .dillo/ ?

Dec. 2, 2008

dialog to change charset

by joerg.sonnenberger＠web.de

On Tue, Dec 02, 2008 at 04:50:06PM +0000, corvid wrote: > I hadn't bothered to look at the list in Firefox because I thought > it would certainly be eight miles -- sorry, kilometres -- long, > but actually it's not so bad. A list that size could fit into dillo. > I'll try making one that does as you suggest. You don't have to hard-code it -- read it on startup, it is not more than a mapping between user-visible name (hierachical?) and system string. That approach also has the advantage of making it easily tweakable for admins/packagers/users. Joerg

Dec. 2, 2008