I am interested in using Django for a side project, and was wondering how well it would align with the following goals. Any helpful resources and tips would be much appreciated

* Authentication of users
* Drag and drop of files into "quarantine" server filesystem where they can be scanned for malware
* Download of said files once virus check has completed

Thanks in advance

This post seems useful to me: https://iq.opengenus.org/file-hosting-service-in-django/

django.contrib.auth will cover most of your authentication needs, though if you want to do some kind of SSO based on another system it will be a little more involved.

To handle quarantining files, I'd probably go for a task queue (like Celery) where you have a Django model with a FileField for each file and an additional "safe" field that starts out set to "unsafe." On upload you can queue a task to scan a file which sets the flag to "safe" on success.

To limit access to scanned files, then you'd want a view that only permits access to a file (by primary key to the database row corresponding to the file in a filesystem) if it's marked as safe. Something like django-downloadview would be useful for doing so efficiently, or if you were using some kind of object storage system (S3 or similar) you could take advantage of signed URLs or other ACLs to only provide access to the resources only once they've been marked as safe.

Thanks Tari, I was able to successfully do all of that. I ended up using django-tables2 for limiting access as it was really easy to tie the model into the table view.

The next problem I am having is this: I am using an apache2 server for production, and am wondering how to properly manage uploading/downloading of non-static files. Just wondering if anyone had any experience with this

As described in the Managing Files section of the Django documentation, uploads are handled by a Storage implementation where the default one uses the local filesystem. It stores files in the path specified by your MEDIA_ROOT setting and generates URLs referring to them at MEDIA_URL.

It's up to you to ensure the things stored in your Storage are available at MEDIA_URL, which usually works in the same sort of way as static files (that are part of your application). That usually means setting up a subdomain or path on the same domain in your frontend server that serves files from your MEDIA_ROOT- security best practices would usually say that should be on another domain that doesn't share cookies with your main one (so malicious uploads can't steal secrets from your clients) but that may or may not be very important for your application.

I have gotten everything working using an apache server + mod_wsgi in order to host the django application and everything seems to be working as intended. However, I am running into the issue where when a large file is being uploaded, the view blocks causing other users to be unable to access the site. Is there an easy solution to this, or do I have to do something like chunked uploads?

You probably need to run more workers; you might even only have one, in which case the server would be able to handle exactly one connection at a time.

As noted in the django deployment documentation for mod_wsgi, you probably want to be using WSGIDaemonprocess with a few threads per process and multiple processes. Since CPython's GIL makes concurrency difficult when CPU-bound tasks run in the same process, you need to fork off multiple processes to effectively take advantage of multiple CPUs.

I note that the mod_wsgi documentation seems pretty dated and suggests you might be using the prefork MPM, where you should really be using event these days, especially if you want your server to support HTTP2. Running mod_wsgi in daemon mode means it doesn't really matter what MPM you're using, though at that point it's basically also just running an external server.

Personally I prefer to use gunicorn to serve applications and simply reverse proxy non-static content through to the application server, since I prefer to separate the frontend server from the application. It also allows doing things like running multiple different application servers and routing to them differently based on request parameters (like cookies) so you can do things like opt some users into hitting the backend that's running a newer version of the application in order to verify it doesn't seem broken (in some kind of staged rollout).