[Wifidog] incorporate_libhttpd branch merged

[Mina Naguib]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Philippe April wrote:
> I tested it and I can't seem to make it work right now.
> 
> However, I found what's not working and it's simple.
> 
> The auth page on the auth server is (configurable)
> authserver.com/wifidog/auth and the login page is
> authserver.com/wifidog/login
> 
> The page my http functions were answering to were just /auth (not
> /wifidog/auth) but your hooks are now handling /wifidog/auth/.
> 
> So basically, the central server code (PHP) has to know the path wifidog
> will answer to, and same for the reverse (auth forwarding to gw has to
> know the path on the gw).
> 
> I suppose we could keep the central server at /wifidog/auth and
> /wifidog/login, since the server might handle other things other than
> wifidog stuff. We could leave the admin of the central server decide that.
> 
> But for the gateway part, I think we should make it just /auth, /about,
> and the rest goes to 404 (which is supposed to be redirected to the
> central server...?)
> What do you guys think? Ideas?

The reason I changed it from /auth to /wifidog/auth on the gateway side is:

1. libhttpd doesn't allow for custom 404 pages.  So what I did was tell 
it capture /* and do the re-direct to the central server.  I'm 
contemplating hacking libhttpd to allow for a custom 404 handler.

2. Because of the above, /* was taking preference over /auth. In essence 
it was no longer possible to reach the "auth" hook since the catch-all 
was more authoritative.  That is why I had to move it 1 level deeper, 
hence /wifidog/auth

3. If someone happens to be going to http://www.anywebsite.com/auth we 
don't want confusion or the auth handler to kick in when it shouldn't have.

I think the ideal solution is to hack libhttpd to add custom 404 
handler, that way we support initial requests that are 2+ levels deep 
(www.blah.com/firstlevel/secondlevel/filename.html).  But I think we 
should keep the handlers as /wifidog/FOO or /wifidog_handler/FOO for 
clarity.

> Other than that, I think libhttpd makes it super clean. If it's possible
> to use it to forge clean HTTP GET requests and parse the responses, it'd
> be good to use it for that too!

No you can't.  For that we'd need libcurl or something similar.

At the meeting tonight I'll propose we DON'T use HTTP when the gateway 
is talking to the central server.  A much simpler text protocol without 
all the HTTP hoopla would be much simpler to code gateway-side.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAWGKveS99pGMif6wRAiKIAKCZHCAg5UrvjupfiTfm45zAliKxYgCg33RN
JCOgfr31bylWRo4tXSI0/+w=
=8mqK
-----END PGP SIGNATURE-----

-------------- next part --------------
_______________________________________________
Wifidog mailing list
Wifidog at isf.waglo.com
http://isf.waglo.com/mailman/listinfo/wifidog_isf.waglo.com