django-crequest - New app announcement

[Alireza Savand]

Hi

Yesterday i released an app for django.

Basically it's just a middleware to access current request of your django application from anywhere in your code.

Other information described in the README and pypi page.

pypi:

    http://pypi.python.org/pypi/django-crequest

github repo:

    https://github.com/Alir3z4/django-crequest

That's it ;)

[Daniel Roseman]

Aargh. This is extremely dangerous. You're setting state on the middleware object, but middleware objects are shared between multiple requests. Have you actually tried it in a production environment? The likelihood is that you'll get leakage between the different requests. Please don't do this.

(If you really must do this, you could try the `threadlocals` trick - it's still a horrible hack, but less so than this.)

--

DR.

[Alireza Savand]

Hi Daniel

Thank you for the feedback.

But at the process_exception, process_response, i deleted the request, I thought by deleting the request information there will be no risk.

As you said, using `threadlocals` trick will be horrible hack.

I found a couple of tut and snippets\gist that do the same thing in different ways, but and nobody mentioned that risk issues.

If all of this [trick|hack|snippet]s are dangerous and risky, what should be done to get that request. And no i hadn't tried on the production env, 

--
You received this message because you are subscribed to the Google Groups "Django users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/GOs1MSRJE8QJ.

To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

--

+++++++

[bruno desthuilliers]

On May 24, 12:35 pm, Alireza Savand <alireza.sav...@gmail.com> wrote:
> Hi
> Yesterday i released an app for django.

> *Basically it's just a middleware to access current request of your django
> application from anywhere in your code.*

Uhu... What if I'm running my code from the shell or a command ?

From experience with some other frameworks / technos, (PHP, Zope /
Plone, etc), it's a pretty bad idea to depend too much on a "current
request" - it leads to way to much coupling in parts of the code that
should be able to work in any environment. Trying to do anything
commandline with Plone is just a major PITA, when not bordering on
impossible.

[Alireza Savand]

So what about logging stuff.

To doing some logging at strange places that i need that request object. specially in deeper and deeper methods/functions. i have to pass the request object to alot of functions which i don't need it in there exaclty but i will need it in inner method, classes.

But with this middleware i have it already :|

--
You received this message because you are subscribed to the Google Groups "Django users" group.

[Alireza Savand]

On Thursday, May 24, 2012 4:46:34 PM UTC+4, bruno desthuilliers wrote:

On May 24, 12:35 pm, Alireza Savand <alireza.sav...@gmail.com> wrote:
> Hi
> Yesterday i released an app for django.
> *Basically it's just a middleware to access current request of your django
> application from anywhere in your code.*

Uhu... What if I'm running my code from the shell or a command ?

By the way, there is also set_request(request) for that situation. 

[bruno desthuilliers]

On May 24, 2:57 pm, Alireza Savand <alireza.sav...@gmail.com> wrote:
> On Thursday, May 24, 2012 4:46:34 PM UTC+4, bruno desthuilliers wrote:
>
>
> > Uhu... What if I'm running my code from the shell or a command ?
>

> By the way, there is also *set_request*(*request*) for that situation.

Yes. In Zope/Plone too, and then you have to setup a fake request for
each and every "no-web" interaction, and then it still manage to fail
one way or another. Been here, done that, have the tee-shirt.

Logging... Well, you know you do have a whole traceback in your logs
using logger.exception in a try/except block ? You can as well let
exceptions propagate up until your view (or exception handling
middleware) and log relevant request data from there.

I don't mean you don't have a use case, but your solution leads to
other problems that from experience are possibly worse. FWIW, I wonder
if you couldn't just hack the root logger from a middleware to inject
relevant request data from the logging itself instead.