Q: Thoughts on a user/password dialog for an HTTP AUTH dpi?
I'm implementing an HTTP AUTH dpi (based on the cookies dpi) and I'd appreciate comments on how I'm doing it. (Motivation: (a) I'm tired of the irony of having to use Firefox to log on to the FLTK Trac Wiki to update the Dillo page, (b) this will be a useful primer for hacking on the https dpi.) The problem is that the dpi must prompt the user for a username and password but src/dialog.cc only supports dialogs that present a choice of buttons. I think I'll have to add a_Dialog_user_passwd() to src/dialog.cc to create a modal dialog, return the clicked button and write the contents of the dialog entries into a struct. Then I can add a wrapper for it to src/dpiapi.c and hook it into a_Capi_ccc(). That will let the dpi query the user. Is this a good way to do it or is there a smarter way? All comments and advice are welcome. Regards, Jeremy Henty
On Thu, Nov 20, 2008 at 02:42:19AM +0000, Jeremy Henty wrote:
I'm implementing an HTTP AUTH dpi (based on the cookies dpi) and I'd appreciate comments on how I'm doing it.
(Motivation: (a) I'm tired of the irony of having to use Firefox to log on to the FLTK Trac Wiki to update the Dillo page, (b) this will be a useful primer for hacking on the https dpi.)
The problem is that the dpi must prompt the user for a username and password but src/dialog.cc only supports dialogs that present a choice of buttons.
I think I'll have to add a_Dialog_user_passwd() to src/dialog.cc to create a modal dialog, return the clicked button and write the contents of the dialog entries into a struct. Then I can add a wrapper for it to src/dpiapi.c and hook it into a_Capi_ccc(). That will let the dpi query the user.
Is this a good way to do it or is there a smarter way? All comments and advice are welcome.
It looks OK. I wonder why a dpi is deemed necessary for this. Isn't an implementation of a_Dialog_user_passwd() enough to solve it? -- Cheers Jorge.-
On Thu, Nov 20, 2008 at 09:14:56AM -0300, Jorge Arellano Cid wrote:
On Thu, Nov 20, 2008 at 02:42:19AM +0000, Jeremy Henty wrote:
Is this a good way to do it or is there a smarter way? All comments and advice are welcome.
It looks OK.
Good!
I wonder why a dpi is deemed necessary for this.
I don't know whether it is necessary. That's why I asked for comments. I just thought that HTTP authentication looked rather "cookie-ish" and decided to copy and modify the cookies implementation. I'm new to this part of Dillo so I am following established practice. I already have a dummy auth dpi running and hooked into the main Dillo program, so I think that the dpi part of things is by far the easiest bit. The most work is actually implementing authentication!
Isn't an implementation of a_Dialog_user_passwd() enough to solve it?
It certainly appears to be the missing link, in the sense that everything else that authentication needs is the kind of thing that the cookies dpi already does and therefore counts as a solved problem already. I plan to continue with the dpi-based implementation on the grounds that the biggest part of the task is implementing authentication and a_Dialog_user_passwd(), and that code will not depend on whether we do authentication in the dillo main program or a dpi. If we decide to move authentication out of the dpi and into dillo itself then I will just move the authentication code around and delete some dpi wrapper code, which won't be much work. At least that's how I expect it will work. Stay tuned, and please comment further. Jeremy Henty
Hi, On Thu, Nov 20, 2008 at 04:08:21PM +0000, Jeremy Henty wrote:
On Thu, Nov 20, 2008 at 09:14:56AM -0300, Jorge Arellano Cid wrote:
On Thu, Nov 20, 2008 at 02:42:19AM +0000, Jeremy Henty wrote:
Is this a good way to do it or is there a smarter way? All comments and advice are welcome.
It looks OK.
Good!
I wonder why a dpi is deemed necessary for this.
I don't know whether it is necessary. That's why I asked for comments. I just thought that HTTP authentication looked rather "cookie-ish" and decided to copy and modify the cookies implementation. I'm new to this part of Dillo so I am following established practice. I already have a dummy auth dpi running and hooked into the main Dillo program, so I think that the dpi part of things is by far the easiest bit. The most work is actually implementing authentication!
Debian seems to ship dillo with a patch for basic authentication: http://patch-tracking.debian.net/patch/series/dl/dillo/0.8.5-4.1/01_i18n Might be worth looking at. Cheers, Johannes
On Sat, Nov 22, 2008 at 03:39:06PM +0100, Johannes Hofmann wrote:
Debian seems to ship dillo with a patch for basic authentication: http://patch-tracking.debian.net/patch/series/dl/dillo/0.8.5-4.1/01_i18n
Thanks for the link but, yikes, it's a 1.5M patch that does i18n, tabs, auth and the kitchen sink too! It also does a fair amount of reorganisation, eg. factoring a lot of stuff into a DilloDoc struct. I'll dig into it when I start doing the auth stuff but it's a lot to wade through. (Unfortunately the auth.[ch] files in this patch are just wrappers: the actual auth implementation is elsewhere and I haven't tracked it down yet.) Regards, Jeremy Henty
Hi, This page (http://linux.ee/~mzz/dillo/0.8.0/dillo-0.8.0-mzz.html) contains the original BASIC auth path (http://linux.ee/~mzz/dillo/0.8.0/dillo-0.8.0-mzz-auth.diff.gz). i18n patch contains lots of small patches there and it's not easy to pick up one of them. Regards, furaisanjin
On Wed, Nov 26, 2008 at 06:39:56AM +0900, furaisanjin wrote:
This page (http://linux.ee/~mzz/dillo/0.8.0/dillo-0.8.0-mzz.html) contains the original BASIC auth path
Thanks, that's very useful. Jeremy Henty
participants (4)
-
furaisanjin＠gmail.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org