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.-