[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Revised Web UI for NPF as a GSoC project
> After feedback and some thought, I've come up with a revised plan.
> Mostly chosen some tools, namely purecss for front-end (I would like to
> nginx+Lapis for Lua framework, etc.
> I get the impression that we want something that offers the
> functionality of pfSense/dd-wrt, not just a UI for npf/blacklistd.
First question that comes to mind: do you know how to build test setup
to check functionality of PPPoE?
> New plan:
> Crude implementation (1-2 weeks):
> Implement a very basic router supporting DHCP client/server and PPPoE using
> a 'dumb' implementation, to experiment.
> Add a pile of features, refactor (1-2 months):
> Ordered by priority:
> - Add any feature supported by plain dd-wrt/pfSense.
pfSense supports a number of features, some of them are not useful
(any longer or to general public). Could you elaborate this item?
Perhaps you need prioritized list here.
> - NPF and blacklistd support
> - Refactor so each feature is its own extension, use Lua templates
> Optional things given remaining time:
> - Graphs that change in time.
> - Allow automatic updates of OS
This may be quite hard thing, actually, since you deal with embedded product.
Also, if you make hidden or explicit assumption of using removable medium
at some point, this becomes mostly useless.
> - UI for extensions
> - Add popular extensions (thinking of varnish, squid, clamav)
Support for P2P networking tools, VoIP and audio/video streaming seems
to be more relevant, given that originally the project is about NPF.
Or port forwarding back to internal services and/or DMZ.
Or traffic shaping, if possible.
> - Translate (should be easy given templates)
> - Test a wide array of browsers to ensure everything looks good.
> - If Lua templates removed most of our need for Lapis, take it out from
> all the other bits.
> - Switch to bozohttpd
> Feedback needed:
> It seems like there's a big need for security. I've learned of one
> attack called cross-site request forgery. Seems like the way to tackle
> it is an awkward dance with embedding tokens in forms.
> I can already see that Sailor (other Lua framework)'s authentication
> scheme doesn't handle this...
> Are there other such concerns?
I would try to avoid this. It is tricky thing that requires investing
a lot more time that you have. Not that you may write without any
thought about security, yet don't put too much effort into it.
One thing to consider: field experience shows that it is important
to provide mechanism for saving and restoring settings from some
external form. Whether it is single XML document, object in JSON
or ASN.1 PER/BER/XER, doesn't matter much. It may be binary bundle,
only you need to support compatibility between versions.
Main Index |
Thread Index |