It is a security issue not to include the Django CSRF middle. Also, since we
don't have a reason to alter the Django middleware list and order, we should
use the same list.
- Store users using Django user/group/permission model
- Database is data/plinth.sqlite3 instead of data/user.sqlite3
- Use Django auth context processors in templates
This commit is big because anything small breaks the code.
- Django dispatcher is based on regular expressions and does not need a tree structure
- Reduces a lot of unnecessary dependencies among modules
- Use Django sessions middlewear instead of CherryPy sessions
- Introduce dependency based modules instead of numeric load order
- Remove PagePlugin and simply use Django views
- Eliminate page rendering wrappers in favor of Django context processors
- Use custom auth for now until replaced by Django auth middlewear
- Use Django templated 404 and 500 error pages
Twitter Bootstrap provides good styling for forms. Our current
theme does not ouput forms in bootstrap styles although for
everything else, it does. The python-bootstrap from is a simple
Django helper application to render Django forms into bootstrap
theme.
Django forms themselves provide numerous advantages over the
current incomplete homegrown solution. It also has solutions for
problems such as CSRF attacks which the current application is
vulnerable to.
Compiled templates are an unnecessary pain in maintance and
packaging. If each module is to bring its own templates, compiling
them in the build process becomes unnecessarily more complex. The
current state of template mess can somewhat be attributed to this.
Cheetah only partially supports dynamic templates. It does not support
inheritence of dynamic templates. From its documentation: "There is no
support for extending from a class that is not imported; e.g., from a
template dynamically created from a string. Since the most practical
way to get a parent template into a module is to precompile it, all
parent templates essentially have to be precompiled."
- Basic information about each service is available for consumers
- Information about whether service is enabled or disabled is available
- Interested parties may listen to enabling/disabling of a service
- Information about some core services are made available
This issue was easy to solve once I started using the Live HTTP
Headers Firefox extension to debug it:
https://addons.mozilla.org/en-US/firefox/addon/live-http-headers/
With this particular InternalRedirect, CherryPy inexplicably responds
with a 301 ("Moved Permanently") unless we manually tell it to use a
307 ("Moved Temporarily") response code. I don't know why CherryPy
does this, and it may be indicative of a deeper problem that I don't
currently have time to debug, as the request-response process for
redirecting from http://(server)/plinth to
https://(server)/plinth/firstboot is ridiculous and contains about
twice as many requests as I would've expected.
Plinth has been moved from plinth.(server).local to (server)/plinth.
*plinth.py* has been updated to take a new *--server_dir* argument,
which *share/init.d/plinth* now provides. *plinth.sample.config* has
also been updated.
Actually, the whole package has been moved to a more Debian-friendly
configuration. *share/apache2/plinth.conf* has been updated to
reflect the standard Debian directories. It seems to make more sense
this way, as (other than FreedomMaker, which now uses this package
anyway) no other tools or derivatives use this system. The
configuration can be patched out by other distributions easily enough.
Author: Tzafrir Cohen <tzafrir@debian.org>
Description: These things are easier to install with dh
* Python modules: fighting with dh_python2 is tough
(it changes the /etc/ symlink, for isntance)
* Let's just install man pages ourselves for now.
* symlinks: with dh_link
