I've had similar use cases where I needed access to the request in a number of places. I've come to the conclusion that any code that is expected to operate under wsgi (and only under wsgi, and not via management commands) to use thread locals.
see https://github.com/nebstrebor/django-threadlocals On Sun, Jan 29, 2017, 1:22 PM Victor Porton <por...@narod.ru> wrote: > Probably a good way to solve this problem is to add `request` (with > default `None`) argument to `Model.save` method, which could then be passed > to the storage used for file fields. > > Let us discuss if this is a good solution or can we invent something > better. > > > On Sunday, January 29, 2017 at 8:12:10 PM UTC+2, Victor Porton wrote: > > See also > https://code.djangoproject.com/ticket/27786 > > I attempt to make file storage behavior dependent on the current user. > (In fact, I attempted to store the ID of the uploader of a given file > into the database, so that other users could not list or delete this > file. Also I tried to store the file in a secret directory (directory > with a secret hash as its name) so that other users could not read it > without receiving an explicit link from the uploader.) I wrote code > like this: > > class MyStorage(FileSystemStorage): > # ... > > def get_user(self): > SessionStore = > import_module(settings.SESSION_ENGINE).SessionStore > s = SessionStore() > s.load() > # print({id: s[id] for id in s.keys()}) # FIXME > # user = apps.get_model('User').objects.get(id=s['user_id']) > return s['user_id'] > > This is set as > > DEFAULT_FILE_STORAGE = 'xxx_storage_app.storage.MyStorage' > > So I expect every form with a file to upload using MyStorage (and so > the upload algorithm depends on the current user). > > But s behaves as an empty hash (without user_id element), as revealed > by the commented "FIXME" line. > > We need either to make SessionStore to support this use case or > massively rewrite API to pass `request` to the form and ultimately to > the storage. I think we can do this without losing backward > compatibility using default function arguments. > > It is a big API change, but it is necessary to support storage > dependent on the current user. It is a real and important use case for > our project. > > Let us discuss the details, what is the best way to implement this in > future versions of Django. > > Sorry for an offtopic, but can you advise me how to do it without > rewriting Django core? > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/6db56f76-6ac0-4e24-b42b-3c5b800a749d%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/6db56f76-6ac0-4e24-b42b-3c5b800a749d%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANJp-yjo5zT9eh4JtPW7aA%3DPXjXGX0xSpHQUA75CSVU%2BhWpMYw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
