4 ms·

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

48 points by craigkerstiens 14y ago

notaddicted 14y ago
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/#using-routers https://docs.djangoproject.com/en/dev/topics/db/multi-db/#us... )
- craigkerstiens 14y ago
  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.
condiment 14y ago
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 14y ago
  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.
raverbashing 14y ago
If I'm not mistaken, making the site 'GET only' will also prevent logins, since form data (login) is submitted using 'POST'
- craigkerstiens 14y ago
  It will prevent new logins, but will not logout the currently logged in users.
maciejgryka 14y ago
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 14y ago
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).
deleted 14y ago
[deleted]
michaelmior 14y ago
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).

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/#using-routers https://docs.djangoproject.com/en/dev/topics/db/multi-db/#us... )

craigkerstiens 14y ago
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.

condiment 14y ago

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 14y ago
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.

raverbashing 14y ago

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

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

maciejgryka 14y ago

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 14y ago

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

deleted 14y ago

[deleted]

michaelmior 14y ago

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