How to prevent HTTP 304 in Django test server - django

I have a couple of projects in Django and alternate between one and another every now and then. All of them have a /media/ path, which is served by django.views.static.serve, and they all have a /media/css/base.css file.
The problem is, whenever I run one project, the requests to base.css return an HTTP 304 (not modified), probably because the timestamp hasn't changed. But when I run the other project, the same 304 is returned, making the browser use the file cached by the previous project (and therefore, using the wrong stylesheet).
Just for the record, here are the middleware classes:
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.transaction.TransactionMiddleware',
)
I always use the default address http://localhost:8000.
Is there another solution (other than using different ports - 8001, 8002, etc.)?

You can roll your own middleware for that:
class NoIfModifiedSinceMiddleware(object):
def process_request(self, request):
request.META.pop('HTTP_IF_MODIFIED_SINCE', None)
Basically, it just removes HTTP_IF_MODIFIED_SINCE header from the request.
Afterthought: Or you can monkeypatch django.views.static.serve and replace was_modified_since function by the one, that always returns True.

Related

CORS header not working for Django backend- Angular frontend

I implemented CORS on my Django backend by installing django-cors-headers and following the steps mentioned in- https://github.com/OttoYiu/django-cors-headers. Essentially, I performed the following steps-
pip install django-cors-headers
INSTALLED_APPS = (
...
'corsheaders',
...
)
MIDDLEWARE = [
'corsheaders.middleware.CorsMiddleware',
'django.middleware.common.CommonMiddleware',
...
]
CORS_ORIGIN_WHITELIST = (
'localhost:8000',
#LB
'10.254.138.226:443'
)
I still can not make it work when I use my angular front-end. For example, my POST request becomes OPTIONS.
zone.js:2935 OPTIONS https://10.254.138.226/api/users 0 ()
error is ProgressEvent {isTrusted: true, lengthComputable: false, loaded: 0, total: 0, type: "error", …}
I don't have this problem when I use postman. Could someone help?
To provide more context- I have the front end and the back end (DRF) running on two different machines. In fact, I have 2 instances of the back end running in two different machines and I have a load balancer mapping the requests from <LB IP>:443 to one of the <Backend IP>:8000 base-url.
I will possibly never find out the exact issue as to why it was happening. I just deleted and recreated the LB and everything started working automagically.

Admin redirects to /login although REMOTE_USER is provided

I configured Authentication using REMOTE_USER in a Django project, replacing the default ModelBackend. However, when I call an admin page it still redirects to the login page. I tested with:
curl -i -H 'REMOTE_USER: ruser1' http://localhost:8765/admin/myapp/mytable/
Location: http://localhost:8765/admin/login/?next=/admin/myapp/mytable/
[edit: this is wrong - I tested as well with
REMOTE_USER=ruser1 ./manage.py runserver]
The remote user has been added to the auth_user table.
My related config snippets are:
MIDDLEWARE_CLASSES = (
...
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.auth.middleware.RemoteUserMiddleware',
'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
...
)
AUTHENTICATION_BACKENDS = (
'django.contrib.auth.backends.RemoteUserBackend',
)
You can't set REMOTE_USER as an HTTP header, otherwise users would be able to spoof the header and log in as any user they wanted.
In production, the REMOTE_USER environment variable is set by the server, e.g. Apache or Nginx. If you are testing using the development server, you can set the remote user with
REMOTE_USER=ruser1 ./manage.py runserver
Any requests to the dev server will be processed with ruser1 as the logged in user.

Setting up local django environment for multiple domains

I'm trying to set up a Django application that will accept multiple subdomain URLs. I'd like to test this locally. Since I can't nail this first step of passing in a url that has a subdomain, I can't get to the second part (figuring out if the URLconf I've set up for django-subdomains is working). The middleware checks for a subdomain, and chooses a URLconf file based on that subdomain.
I've set the following configs in /etc/hosts. When I've got the server running, and I hit these URLs, I go to the real test.com.
127.0.0.1 payments.test.com
127.0.0.1 rampup.test.com
(in case it matters) django-subdomains middleware settings from settings.py:
SUBDOMAIN_URLCONFS = {
'payments': 'main.urls',
'rampup': 'rampup.urls'
}
MIDDLEWARE_CLASSES = (
'subdomains.middleware.SubdomainURLRoutingMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
# Uncomment the next line for simple clickjacking protection:
# 'django.middleware.clickjacking.XFrameOptionsMiddleware',
)
Try this:
0.0.0.0 payments.test.com
0.0.0.0 rampup.test.com

Django middleware: Isn't a middleware module error

I am using the middleware provided in https://gist.github.com/426829 to do cross site scripting.
However, when I add the middleware to MIDDLEWARE_CLASSES, I get the error:
ImproperlyConfigured: isn't a middleware module.
My MIDDLEWARE_CLASSES looks like this:
MIDDLEWARE_CLASSES = ('django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'TempMiddleware',)
I have not changed any code in the gist. process_request and process_response methods are there. I am on Ubuntu running the latest versions of Python and Django.
What's TempMiddleware? The name of the module, or the name of the class? As you can see with the other entries, you need the fully-qualified Python path of the actual class. If TempMiddleware is the name of the module, you need TempMiddleware.MyMiddlewareClass (and you should really follow PEP8 naming conventions) - and if it's the name of the class, you need my_module.TempMiddleware.
Edit:
TempMiddleware is not importable. It's the name of the class, you must put the entire import path.
E.g:
'django.contrib.auth.middleware.AuthenticationMiddleware'
and not
'AuthenticationMiddleware'
So if your class is in app_name/middleware.py, it should be
app_name.middlaware.TempMiddleware
It just mean that in your settings file, the variable MIDDLEWARE_CLASSES contains a list of modules in which one of the listed module is not a middleware.
Possible causes:
you added a middleware that doesn't declare middleware methods: fix that by removing the last middleware you added
you added a correct middleware but forget to put a coma at the end of the name, so strings are concatenated and it make django thinks 2 middlewares are in fact one: fix that by adding the missing coma

Django Per-site caching using memcached

So I'm using per-site caching on a project and I've observed the following, which is kind of confusing. When I load a flat page in my browser then change it through admin and then do a refresh (within the cache timeout) there is no change in the page--as expected. However when I stat a new session in a different browser and load the page (still within the timeout) the app is hit instead of the cache, with the
Isn't the cache key generated from the URL? it seems that the session state is getting in there somewhere, which is causing a cache miss.
MIDDLEWARE_CLASSES = (
'django.middleware.cache.UpdateCacheMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.gzip.GZipMiddleware',
'django.middleware.http.ConditionalGetMiddleware',
'django.middleware.doc.XViewMiddleware',
'ittybitty.middleware.IttyBittyURLMiddleware',
'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware',
'maintenancemode.middleware.MaintenanceModeMiddleware',
'djangodblog.middleware.DBLogMiddleware',
'SSL.middleware.SSLRedirect', #SSL middleware to handle SSL
'django.middleware.cache.FetchFromCacheMiddleware',
)