Introducing django-db-tools - A read-only mode for your Django app | Hacker News Reader

Introducing django-db-tools - A read-only mode for your Django app

craigkerstiens.com

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.

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.

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... )

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.

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

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

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).

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?

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).

Reply on news.ycombinator.com