Thanks to the quality of this list, my experience with FreedomBox as a potential platform has been superb. I'm eager to engineer as much of HIE of One as possible around FreedomBox and Plinth because it would complement the current FreedomBox application suite and because adoption of both FreedomBox and HIE of One is likely to be improved. The timing also seems to work as FreedomBox is now stable enough to be a net plus as a platform for a new community like HIE of One.
I've read the Manual, and it's quite good as a starting point for using or hacking. However, I think I need a bit of advice around FreedomBox-Plinth-HIE of One architecture. Briefly, HIE of One, like Plinth, is designed around Django and a sqlite DB to manage all of the various OAuth-related tokens and associated policies. There will be 4 tables: Resource Servers, Clients, Users, and OpenID Providers accessed by the Django admin UI and connected to a handful of OAuth and UMA standard HTTPS endpoints. From a UI design perspective, the goal of HIE of One is to be as invisible and automated as a well-designed ad-blocker: it's at its best when users don't need to know how it works, it comes from a trusted source, installs with no questions, don't have to configure anything, and it's always easy to manage exceptions. So the question is: how do I treat FreedomBox and Plinth as a platform for development purposes? This may seem like a simple RTFM issue until you realize that I have no Django experience myself. The Developer Manual seems to assume that the app being added already mostly exists rather than my situation where I'm hoping to hack FreedomBox without breaking it. Any and all thoughts are most welcome as I plow ahead. Thanks, and Happy New Year! Adrian On Thu, Dec 31, 2015 at 7:17 AM, Petter Reinholdtsen <[email protected]> wrote: > [James Valleroy] > > The Plinth apache2 configuration, in > > /etc/apache2/sites-available/plinth.conf, restricts access to the > > following IPs by default: > > > > 127.0.0.0/8 > > 169.254.0.0/16 > > 10.0.0.0/8 > > 172.16.0.0/12 > > 192.168.0.0/16 > > ::1 > > fe80::/10 > > fc00::/7 > > > > Easiest workaround for now is to add the public IP of wherever you are > > trying to connect from, with a "Require ip" statement. > > Perhaps we could avoid user confusion if we conviced apache2 to show a > page stating that the admin interface is only available for the IPs > listed above, when it is rejecting access? > -- > Happy hacking > Petter Reinholdtsen > > _______________________________________________ > Freedombox-discuss mailing list > [email protected] > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss > -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
_______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
