Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permissions? #52

Open
trolando opened this issue Oct 11, 2015 · 3 comments
Open

Permissions? #52

trolando opened this issue Oct 11, 2015 · 3 comments

Comments

@trolando
Copy link

Currently there is no way to control who is allowed to upload/replace/rename/delete files.

It would be nice to add Permissions. There is a simple way to add the permissions to filebrowser_safe, as in trolando@fbec0b2

This commit is based on how django.contrib.auth adds permissions for the models, using the post_migrate signal introduced in Django 1.7. (earlier versions use the post_syncdb signal).

The above commit simply adds some permissions, it does not enforce them. This would require adding decorators to the correct functions (mkdir, _upload_files, rename, delete), correctly handling overwriting files, and correctly hiding functions that are not allowed in the UI. I do not know filebrowser_safe well enough to be able to correctly protect files from being overwritten.

Another thing to consider is whether browsing the Media Library is always allowed or not. There could be reasons to introduce a permission for this as well, for example if someone is allowed to perform certain actions on another app in the website that is not related to the Media Library. Enforcing a browse permission would require additional changes in Mezzanine, since the Media Library is not connected to Mezzanine via an app, but via the 'fb_browse' reverse URL.

@stephenmcd
Copy link
Owner

Thanks Tom - I think this is a good idea, can you go ahead and set up a complete pull request?

I think browsing should always be allowed - restricting that would cause many problems, particularly when it's integrated with file fields in other apps/models.

@trolando
Copy link
Author

For a complete pull request, including actual permission enforcement, I need to know how to really prevent overwriting.

Is my assumption correct that Django does not actually store the file on disk, but keeps it in memory in the request.FILES object? And that the actual "possible overwriting" occurs on line 333 in views.py when default_storage.save() is called? I am unsure what happens in lines 334--335 with the file move.

Then, I'd have to figure out how to integrate this with the UI. For example, instead of a warning "This will overwrite XXX" there should be an error message, and so on.

@stephenmcd
Copy link
Owner

Can you post these questions to the mailing list? You'll hopefully get more interaction there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants