I have a a django application which is being served from apache/mod_wsgi under www.mysite.com/mysite
suppose I redirect url "myapp" -> myapp/urls.py
so to visit it from apache I will visit www.mysite.com/mysite/myapp/page1
to visit it from dev server I will need to visit www.mysite.com/myapp/page1
it also means absolute URLs wil be different in both cases
so what is the best way to handle this , so that app works same way in apache and dev server?
Don't embed absolute and/or non-computed URLs in your code or database. They will always come back and bite you on the ass.
Use either an alternate settings.py, or have some logic in settings.py to tweak differences between development/staging/production. We use settings.py as the production file and dev/staging use a local_settings.py which is tested for in settings.py and, if present, overrides production settings in settings.py. This prevents alternate development settings from creeping into staging/production.
Set a BASE_URL for the entire site and use it for everything else.
We go a bit further and have STATIC_MEDIA_URL and BIG_CONTENT_URL (for MP3s and Flash video) as the base URLs for other stuff.
All of this allows us to use whatever server is right for the moment. When I'm doing development I normally let the MEDIA come from the production servers (it's faster), but sometimes I'm doing a reorg of the media directories and I can't do it on production without breaking the world. So I just change my local_settings.py file to use my copy of the directories.
Related
We're hosting several dockerized web-apps on our webserver, let's call it group.example.com. Our subdomains are handled via nginx as suffixes though, which translates to something like group.example.com/app1/ group.example.com/app2/ as root urls.
When using Django, we run into problems though, as all its urls generated by url in the templates such as home will be relative links, so rendered to home. This relative link will not be interpreted correctly, leading to the main, non-app page group.example.com.
So the goal is to have an app based prefix such as /app1/ for all links. I can hardcode these for static links, but there has to be a more elegant way. Also this leads to problem for the used forms submitting to the wrong page - redirecting again back to the main, non-app page group.example.com.
I tried adding /app1/ to all registered urls as prefix, but that doesn't seem to work either - that way the app is running but user would need to visit group.example.com/app1/app1/ to get to the index, and the relative links still don't work correctly.
In the app docker-container we're running the web-app with nginx and uwsgi. It works fine when using correct subdomains such as app1.example2.com - but we don't have that capability on our new faster webserver we want to host the app on.
Is there a way to resolve this using the app containers nginx, uwsgi or django / middleware config to get the links to resolve to group.example.com/app1/ as root?
As far as I know, there is two ways to resolve it.
One use SCRIPT_NAME in the NGINX configuration. For example, based on this server fault answer:
location /app1/ {
SCRIPT_NAME /app1;
# rest of the config
}
Two You can add FORCE_SCRIPT_NAME in your settings.py:
FORCE_SCRIPT_NAME = '/app1'
FYI, I would prefer using first solution.
I've been developing a site with sensitive (i.e. proprietary) code on my local machine, testing it using apache2, and I'm finally going to be getting it setup with a web host. I'm a bit wary because of the "Where should this code live?" note here in the Django Tutorial:
Where should this code live?
If your background is in plain old PHP (with no use of modern frameworks), you’re probably used to putting code under the Web server’s document root (in a place such as /var/www). With Django, you don’t do that. It’s not a good idea to put any of this Python code within your Web server’s document root, because it risks the possibility that people may be able to view your code over the Web. That’s not good for security.
Put your code in some directory outside of the document root, such as /home/mycode.
My host told me that I'll be given a /home/ directory, and that the site will live in /home/www. I'm trying to emulate this directory structure on my end before I send everything to him to make sure it goes as smoothly as possible. My question is, if I want all my code to live outside of the /www directory (per the Django tutorial recommendation above), what actually goes inside the /www directory?
My development directory structure is basically this:
project
db
app1
app2
mysite (contains settings.py, wsgi.py, etc.)
static
templates (contains my base.html, and custom templates for admin, etc.)
Where app1 and app2 are Django apps I've developed to plug into mysite. So what folders / files need to go in the home/www directory, and what can safely live in home/mycode?
Your static and media (user-uploaded) folders, robots.txt etc. should be in the www directory. Basically any file that is directly served by your webserver and not through Django. Other files should live outside of this directory.
Your webserver should point all requests that are not found in the www directory towards your wsgi application, which doesn't need the code to be accessible by an url.
The reason for this is that your webserver does not execute the code in a python file, in contrast to php files. If your code lived in your web root, people could read your settings files by just going to example.com/src/settings.py. Images, plain html/text files and javascript should be read, but any code that should be executed should live outside your web root. Django will execute the files and generate the response that a user should actually see.
I just need some advice pointing me into the right direction using Django with multiple sites / clients.
Basically depending on the domain name I want to use multiple sites with only one Django instance.
For example a directory structure.
mysite/
manage.py
settings.py
client1/
url.py
client2/
url.py
So what I am thinking is, inside settings.py depending on the domain name I can change the
ROOT_URLCONF = 'mysite.clientx.urls'
The site will match about 95% so I don't see the point of changing all other settings as well.
How would I do this? I did go through site management in the Django documentation although it seems like an overkill for what I want to accomplish.
Also keep in mind I am using Apache with "django.wsgi".
I'm moving a project to new hosting and would like to set it up such that it sits at mysite.com/test/ (this is under mod_wsgi on an Apache server). This seems to do alright for the application itself, but when I use #login_required to enforce authentication Django redirects to mysite.com/accounts/login instead of mysite.com/test/accounts/login as I would like. I also have a mysite.com/prod that I want to do this same thing on so I don't want to hard code this anywhere in settings... it should figure out where the root of its URL is and act accordingly.
How do I set it up so that Django automagically redirects to what Apache considers that application's web root?
You need to set LOGIN_URL and LOGOUT_URL to full URL path in Django settings file. See:
http://docs.djangoproject.com/en/1.3/ref/settings/#login-url
Django doesn't automatically insert the mount point at the start of those as so have to be fully qualified.
The same problem can be solved in a more generic way for all project URLs. You could checkout an alternative solution at Running a Django site on my local machine, am I redirecting my URLs properly? for an environment based ROOT URL support.
I'm serving "sensitive" information in downloadable PDF's and Spreadsheets within a user registration section of a site.
Is there a way to allow the django authentication to secure this media without serving it (and not have to manually login using basic auth)?
I'm guessing theres (fingers crossed) not a way to do it with the psuedo code below, but it helps better illustrate the end goal.
#urls.py
(r'^protected_media/(?P<filename>.*)$', 'protected_media')
#views.py
from django.contrib.auth.decorators import login_required
#login_required
def protected_media(request, filename):
# #login_required bounces you out to the login url
# if logged in, serve "filename" from Apache
It seems to me that the method you outlined in your code should work. It's really no different than any other protected resource: your views can serve files from disks, records from databases, rendered templates or anything. Just as the login_required decorator prevents unauthorized access to other views, it will prevent such access to your view serving protected media.
Am I missing something from your question here? Please clarify if that's the case.
EDIT: With regard to the django doc link in your comment: that's the method for simply serving any request file from a particular directory. So, in that example URLS like /site_media/foo.jpg, /site_media/somefolder/bar.jpg will automatically look for files foo.jpg and somefolder/bar.jpg under document_root. Basically, every thing under document_root will be publicly available. That's obviously insecure. So you avoid that with your method.
It's also considered inefficient because django is just adding a lot of unnecessary overhead when all you need is something like Apache to take a URL request and map it to a file on the hard drive. (You don't need django sessions, request processing, etc.)
In your case, this may not be such a big concern. First, you've secured the view. Second, it depends on your usage patterns. How many requests do you anticipate for these files? You're only using django for authentication -- does that justify other overhead? If not, you can look into serving those files with Apache and using an authentication provider. For more on this, see the mod_wsgi documentation:
http://code.google.com/p/modwsgi/wiki/AccessControlMechanisms
see the section "Apache Authentication Provider" and search for django
There are similar mechanisms available under mod_python I believe. (Update: just noticed the other answer. Please see Andre's answer for the mod_python method.)
EDIT 2: With regard to the code for serving a file, please see this snippet:
http://www.djangosnippets.org/snippets/365/
The send_file method uses a FileWrapper which is good for sending large static files back (it doesn't read the entire file into memory). You would need to change the content_type depending on the type of file you're sending (pdf, jpg, etc).
Read this Django ticket for more info. Start at the bottom to save yourself some time. Looks like it just missed getting into Django 1.2, and I assume also isn't in 1.3.
For Nginx, I found this Django snippet that takes advantage of the X-Accel-Redirect header, but haven't tried it yet.
If I understand your question correctly you want to restrict access to files that are not being served by Django, for example, with an Apache server?
What you would then require is some way for this Apache server to use Django as an authentication source.
This django snippet describes such a method. It creates an access handler in Django which is used by Apache when a request for a static file comes in that needs to be protected:
<Location "/protected/location">
PythonPath "['/path/to/proj/'] + sys.path"
PythonOption DJANGO_SETTINGS_MODULE myproj.settings
PythonOption DjangoPermissionName '<permission.codename>'
PythonAccessHandler my_proj.modpython #this should point to accesshandler
SetHandler None
</Location>
Hope this helps, the snippet was posted a while ago, so things might have changed between Django versions :)
More efficient serving of static files through Django is being looked at currently as part of Google SOC project. For WSGI this will use wsgi.file_wrapper extensions for WSGI if available, as it is for mod_wsgi, and req.sendfile() if using mod_python. It will also support returning of headers such as 'Location', 'X-Accel-Redirect' and others, which different web hosting mechanisms and proxy front ends accept as a means of serving up static files where location is defined by a backend web application, which isn't as effecient as front end for serving static files.
I am not sure if there is a project page for this in Django wiki somewhere or not, but the code changes are being committed into the branches/soc2009/http-wsgi-improvements branch of Django source code repository.
You needn't strictly wait for that stuff. It is just putting a clean and portable interface in place across the different mechanisms. If using nginx as front end in front of Apache/mod_wsgi, you could use X-Accel-Redirect now. If using Apache/mod_wsgi 3.0 and daemon mode, you could use Location now, but do need to ensure you set up Apache correct. Alternatively, you could implement your own WSGI middleware wrapper around the Django application which looks for some response header of your own to indicate file to be returned and which uses wsgi.file_wrapper to return that instead of actual response returned from Django.
BTW, the authentication hook mechanisms listed for both mod_python and mod_wsgi by others would use HTTP basic authentication, which isn't what you wanted. This is presuming you want files to be protected by Django form based login mechanism using cookies and backend sessions.