
Introducing django-db-tools - A read-only mode for your Django app - craigkerstiens
http://craigkerstiens.com/2013/02/08/django-read-only-mode/
======
condiment
This is an elegant starting point for implementing read-only mode in a Django
app.

The appearance of buggy behavior can be expected if this is used on a site
that does not strictly implement a REST interface (ie. POST to /resource/new/
instead of /resource/), but that's a flaw resulting from the individual
implementation, not from your library, and even with an appropriately RESTful
interface you'll still need to display messaging to the logged-in user when
GET_ONLY_MODE is set to True.

You mention wanting to provide a generalized means of providing messaging in
the template, but I've found that library templates are almost always
inappropriate for inclusion into an existing application except in the most
trivial of cases. An alternative to generalized messaging might be to
implement some crazy logic in process_response() to disable all forms.

I also wonder whether environmental variables are appropriate for this type of
change, since administering environmental updates across multiple servers
requires a deploy strategy outside of the traditional Git schemes that people
set up.

That said, I'll be watching the project to see where it leads. Congrats on the
launch.

~~~
craigkerstiens
The buggy behavior can definitely occur for those that don't appropriately
follow a RESTful interface.

With regards to displaying messaging, this is something I'm very much looking
to add to both modes. In regards to templating the initial thought was some
HTML that the user could include or would be default that would float as an
overlay on a page to indicate the mode. Though I'm mostly curious as to what
users would most want to see here before implementing something that people
may not want.

As for the environment variables, I may be biased but being at Heroku we very
much enjoy this approach. It reduces risk of having config included with code
which can be hard to debug at times.

------
notaddicted
I like the general idea, if you want some "insurance", you could also set the
database user that the application uses to SELECT only permission.

Have you ruled out using a router? (like
[https://docs.djangoproject.com/en/dev/topics/db/multi-
db/#us...](https://docs.djangoproject.com/en/dev/topics/db/multi-db/#using-
routers) )

~~~
craigkerstiens
I did consider using the router and actually inspecting form data as well,
both felt far more convoluted and could result in tougher to bug situations
should issues arise. While I'd love to have something more robust and safe
this is currently just v0.1 and I generally am looking forward to more
conversation around what users see as acceptable.

------
raverbashing
If I'm not mistaken, making the site 'GET only' will also prevent logins,
since form data (login) is submitted using 'POST'

~~~
craigkerstiens
It will prevent new logins, but will not logout the currently logged in users.

------
michaelmior
Why not just block POSTs completely and return a 405 status? Even if your app
is adequately RESTful, I would expect the front end to start displaying user
actions as being successful when that is not the case (among other possible
oddities).

------
maciejgryka
Looks really good!

Just a thought - when using the GET_ONLY_MODE you should probably be careful
with your sessions if you're storing them in your database right?

------
drchaos
nice idea! A possible extension would be to allow POST to LOGIN_URL as an
option, so users could log on (but not edit anything).

