Basic Authentication: what's happening here?
OK, after reviewing the links people sent in (thanks!) and the discussion at [1] I decided not to create a DPI. I've hit a strange problem with getting the page to reload after the user confirms the user/password dialog. I show the dialog in Cache_parse_header() by calling fltk::Window::exec() and set a new CA_Reload flag (which is just like CA_Redirect, but simpler) if the user confirms. Cache_process_queue() then handles the CA_Reload. *But* Cache_process_queue() runs before the window is closed, and therefore before the flag is set. It looks as though the rest of the data comes in asynchronously while the dialog is still showing. If I change a_Auth_do_auth() to return immediately instead of showing a dialog then Cache_process_queue() runs after the flag is set, as I would expect. Is there any way to stop this happening, or do I have to postpone showing the dialog until Cache_process_queue() runs? Patch attached if you wish to experiment (it doesn't do authentication but it demonstrates the problem with the dialog). Regards, Jeremy Henty [1] http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-October/005023.html
Jeremy wrote:
OK, after reviewing the links people sent in (thanks!) and the discussion at [1] I decided not to create a DPI.
I've hit a strange problem with getting the page to reload after the user confirms the user/password dialog. I show the dialog in Cache_parse_header() by calling fltk::Window::exec() and set a new CA_Reload flag (which is just like CA_Redirect, but simpler) if the user confirms. Cache_process_queue() then handles the CA_Reload. *But* Cache_process_queue() runs before the window is closed, and therefore before the flag is set. It looks as though the rest of the data comes in asynchronously while the dialog is still showing. If I change a_Auth_do_auth() to return immediately instead of showing a dialog then Cache_process_queue() runs after the flag is set, as I would expect.
Is there any way to stop this happening, or do I have to postpone showing the dialog until Cache_process_queue() runs?
Postponing it sounds right to me.
On Fri, Nov 28, 2008 at 01:30:05AM +0000, corvid wrote:
Jeremy wrote:
Is there any way to stop this happening, or do I have to postpone showing the dialog until Cache_process_queue() runs?
Postponing it sounds right to me.
Unfortunately, if I show the dialog from inside Cache_process_queue() just before it iterates over the clients then something *still* runs asynchronously while the dialog is up, which gets me a warning from the CCC about a call on a finished chain, followed by a segfault when I confirm the dialog and reload the browser window. If I delay the reload even further by doing it from inside a timeout then I still get the warning, but not the segfault. (Amended patch attached.) I don't understand the CCC well enough to know what I should be doing here. What now? When I was doing this from a DPI it all happened asynchronously and I ended up writing a a_Nav_reload_url() that reloaded all the browsers for a gicen URL. I thought that was pretty hacky but maybe it's the only way to make this work? Regards, Jeremy Henty
Jeremy wrote:
On Fri, Nov 28, 2008 at 01:30:05AM +0000, corvid wrote:
Jeremy wrote:
Is there any way to stop this happening, or do I have to postpone showing the dialog until Cache_process_queue() runs?
Postponing it sounds right to me.
Unfortunately, if I show the dialog from inside Cache_process_queue() just before it iterates over the clients then something *still* runs asynchronously while the dialog is up, which gets me a warning from the CCC about a call on a finished chain, followed by a segfault when I confirm the dialog and reload the browser window. If I delay the reload even further by doing it from inside a timeout then I still get the warning, but not the segfault. (Amended patch attached.) I don't understand the CCC well enough to know what I should be doing here. What now?
I don't know CCC either. I wonder whether the original patch gave that warning with 0.8.x.
When I was doing this from a DPI it all happened asynchronously and I ended up writing a a_Nav_reload_url() that reloaded all the browsers for a gicen URL. I thought that was pretty hacky but maybe it's the only way to make this work?
On Fri, Nov 28, 2008 at 06:51:48AM +0000, corvid wrote:
Jeremy wrote:
... if I show the dialog from inside Cache_process_queue() just before it iterates over the clients then something *still* runs asynchronously while the dialog is up, ... What now?
I don't know CCC either. I wonder whether the original patch gave that warning with 0.8.x.
The original patch was slightly different in that the dialog was part of the bw structure. Rather than port that approach I decided to go the way suggested by the earlier discussion between Jorge and Christian. Anyway, here's a version that seems to work. It defers both the dialog and the reload to a timeout. Unfortunately we no longer have a reference to the browser window so it calls a new function a_Nav_reload_url() that reloads all browsers displaying the URL. It removes CA_Reload and bw->reload_level since they're now unnecessary. It's actually quite straightforward, the only clunkiness is using the timeout and a_Nav_reload_url(), but that seems to be necessary. Now I just have do the actual authentication. Regards, Jeremy Henty
participants (2)
-
corvid＠lavabit.com -
onepoint＠starurchin.org