I have a backbone.js single-page app that is all set up with the router (well, actually a Backbone.Marionette app with a Backbone.Marionette AppRouter, but nevertheless). However, the backend is based in Django, where I do not have the URL conf directing to views for all URLs that are already in the backbone.js routes.
Based on the existing URLs in the Django URL conf, Backbone.js will serve the backbone routes regardless of what is listed in the Django conf - it seems something, anything just needs to be there.
Do I need to have proper Django views in order to offer a fallback for older browsers/SEO?
What are the best practices to coordinate the Django URL conf and the Backbone.js Router?
I've found a post that addresses this issue quite well:
http://duganchen.ca/single-page-web-app-architecture-done-right/
Briefly, my reasoning for including a fallback is for non-javascript browsers and SEO reasons. At the time of this post, non-javascript browsers account for ~1.4% (less than 2% from everything I've read) of users, making SEO The major consideration. Again, SEO may not be relevant for everyone reading this post, in which case, this can be skipped.
I found Thomas Davis' tutorial using phantom.js quite helpful. http://backbonetutorials.com/seo-for-single-page-apps/
However, another issue that I needed to account for was the history API, which has been neglected by all but the latest IE browsers. Given my client's users, about 15% of which are using IE <= 9, this was also a problem.
In the end, I also needed to use history.js. All in all, this was a lot of work to update an otherwise very simple website. However, I learned a lot from this ordeal.
In my opinion if your backbone app is truly a single page then you don't need any django views whatsoever. You can serve your index.html as a static file (in production, not even by django) and then let backbone's router take care of your url configuration, as you're doing already. You can use backbone's history and navigate to fake urls, add urls parameters etc, for resources in your app.
Related
Folks,
I am pretty sure I am not the first one to stumble on this problem. But somehow I am unable to find any relevant resources out there.
Here is my issue, I have a backend in Django and my front completely written in Reactjs- React Router - Redux (nice combo right).
when entering the url webhost.com/, django provides me with a page with links to a bundle that is my whole react application and different stylesheets
The problem arise when I want to refresh a page, the browser still tries to query the server even though a route exists in my react-router configuration.
I had a look at the answer here (catch-all option) React-router urls don't work when refreshing or writting manually , but I don't quite understand it and I am afraid to have a new redux state everytime Django will provide the user with a new page.
You can setup up a wildcard url pattern that will render the same view that gets rendered when a request is sent to webhost.com. I don't know if that's going to retain your store though.
Meteor concatenates, minifies and compiles all html, css and javascript and sends them all to the client. But as I noticed, it's not useful for some cases.
For example, for most users we have app which works on myapp.com and another big part of app - admin dashboard works on myapp.com/admin. The size of admin part is compatible to the size of a main app part, but it's used only by hundreds of users or so. As a result most of the users load 2x size on client, half of which is useless and can't be used.
Does Meteor have solutions of this problem or maybe someone can suggest any hacks to solve it?
if you made your whole /admin/ section a separate package you could deploy two builds, with and without, and then route any clicks on "/admin/" URLs to "admin.APP.com/admin". both apps would of course need to talk to the same database.
Some people are using nginx proxy to decide what to serve, but this is not so much based on URLs as on some property of the userAgent, eg for mobile devices. this is nicer than having separate subdomains. the user doesn't see "admin.APP.com", the different backends are masked from them. But, you may not care so much about that. Having admin.* be explicit is a good thing.
Im still fairly new to Django, so please explain things with that in
mind.
I'm trying to create three websites using 2 subdomains and 1 domain:
for the blog, blog.mysite.com
for the forums, forums.mysite.com
for the custom web app, mysite.com
When building the custom web app, I used contrib.auth to make use of
the built-in django provided user models and functionality.
For the forums, I am planning on using SNAPboard (http://
code.google.com/p/snapboard/) with minimal, if any, modifications. On
initial inspection, it looks like it also uses contrib.auth users.
For the blog, I will probably be rolling my own lightweight blogging
app (since that seems to be the Django way and, also, b/c as Bennet
mentions, there is no killer Django Blog app)
Currently, I am considering two features that require some integration
between the three sites. First, I want to have the users of the custom
web app to use the same account to also log into the forums. Second, I
also (but I haven't figured out how I'm going to do this yet) would
like my blog posts to automatically become a topic for discussion in
the forums (this is just an idea I had, I might end up dropping it).
Ok, so to my questions:
1) Again, I'm new to Django, but this integration leads me to believe
the three websites need to be all under one project. Is this correct?
2) How would I accomplish the url structure for the websites that I
described above (blog.mysite.com, etc)? In the project's urls.py, I
don't know how to filter off of subdomains. If it was mysite.com/
forums/, that would be easy, but I don't know how to to catch
forums.mysite.com and forward it to the appropriate Django app.
3) Would I have to make use of the django.contrib.sites framework? I
don't understand that framework fully, but it seems like it's used
when two different websites are using the same django app in the
background. Whereas my three websites are all using different django
apps, but I want them to share a little bit of data.
Thanks for your help.
1) Yes, it's only true way for that
2) Use middleware
3) No, you don't need it.
I have a website done with Django, that was previously done with PHP and CodeIgniter. I've moved the website to Webfaction, changed the DNS and all other configurations, but now my email is full of errors like this:
Error (EXTERNAL IP): /index.php/main/leer/7497
I don't know why the Django app is looking for pages from the PHP app, specially since the PHP app was in another host.
Are those URLs from your old site? That's probably a case of people having stale bookmarks, trying to navigate to them, and getting 404s. You might want to consider catching those, and redirecting to the new URL with response code 302.
I can't imagine those errors are caused by Django (except in the sense that the reports are from Django reporting 404s, which it does for free).
I agree with above. Just want to add you should use django.contrib.redirects to move the redirects.
You can read more about it here
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.