Need to get user_id outside of a view

[Victor Porton]

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?

[Victor Porton]

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.

[Aron Podrigal]

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

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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.
For more options, visit https://groups.google.com/d/optout.