I have a large codebase in a homebrew python framework. I'm going to be gradually moving the code to Django, but in the meantime need to support logging in via the old system. The old system uses a cookie to identify the user after they have logged in.
I don't want users to log in via Django, but I do want to be able to use #login_required as well as several apps that rely on Django's auth system, such as the admin, django-tagging and django-comments.
What's the best way to integrate the two auth systems? Both codebases are running within the same python process (via a wsgi middleware that switches apps per-request) and can load modules from each other as needed.
The easiest way to get it working is probably to use a custom authentication middleware in Django.
There are a couple of example authentication middlewares in Django: http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/middleware.py
Related
I have read a couple of articles about using new JS frameworks like Backbone.js or Ember.js
I have come up to this statement:
If I use a JS framework like Backbone.js/Ember.js, I then move the logic from the back-end (Django) to the front-end.
Therefore, will Django actually be used only for its Models?
Does that mean that Django Views and Django Template are not needed anymore and the Django back-end is kinda turn into a "basic" REST API that will be consumed by the front end.
Do you agree? Is it then the purpose of Django in this case?
Is turning the django backend into a REST API one of the most suitable use case when using a framework like Backbone.js/Ember.js for the front-end?
Thanks.
Django is perfectly fine to be used this way, you still get the admin, the models, the orm and all the third-party plugins. However, it isn't blazingly fast, so if you're doing simple document level, non-relational REST mapping, you might wan't to look into node.js and mongoDB for instance.
If you're sticking with django (like we are, we like the structure it gives us), you can use one of the REST plugins:
Django Rest Framework A perfect match since DRF 2.0, under very active development!
Django Tastypie (checkout backbone-tastypie.js for integration)
Django Piston (might be a bit stale or has development picked up lately?)
If you only want to work with frontend development, checkout the Backend-as-a-Service places like cloudmine.me or firebase.com that handle all backend stuff for you, for a price of course.
Django may seem unnecessary once you start thinking about single page solutions and Javascript applications, but if you want your site to be 'fail proof' it wouldn't be impossible to develop both a client side Javascript version of the site as well as a backend django side incase the user, or your site's javascript, fails at some level. Of course this requires creating your site twice, and probably isn't needed in the age of modern browsers, but such would be one of the few instances where you would mix the two for a complete solution.
Yes, that's about it. You can use it to manage authentication to resources and such and maybe use a main view for your application but you won't need to use the server side templating since these frameworks are made to work with json/xml response.
That's why a lot of people are moving to lighter backend/backbone or ember combo instead of a complete solution like django. You can also use your django for caching json response which makes your application appears faster.
We are doing that and use django-piston to make it easier on you.
Normally you make your entire website under Django and only one page will be a "single app page" using backbone.js, usually that page is a very interactive page, with lots of small updates that occur frequently and need to be shown very fast to the user. This page, because of the large number of changes and user interactions is constructed on the client-side so that you are using his PC resources and not the server's, the rest of the pages can use django because it offers you a very stable and secure framework for the server-side
I understand that full django can be used out of the box with CloudSQL. But I'm interested in using HRD. I'd like to learn more about what percentage of django can be used with nonrel. Does middleware work? How about other features of the framework like i18n, forms, etc. Also does nonrel work with NDB?
The background here is that I've even using webapp2 and before that webapp and find them great until your project gets bigger. So for this project I'm interested to reevaluate other options.
The big limitation is that the datastore doesn't do JOINs, so anything that uses JOINS, like many-to-many relations won't work.
Any packages/middleware that uses many-to-many won't work, but others will.
For example, the sessions/auth middleware will work. But if you use permissions with auth, it won't. If you use the admin pages for auth, they use permissions, so you'll have some trouble with those too.
i8n works.
forms work.
nonrel does not work with ndb.
I don't know what you mean by "until your project gets bigger". django-nonrel won't help with the size of your app.
In my opinion there's two big reasons to use nonrel:
You're non-committal about App Engine. Nonrel potentially allows you to move to MongoDB as a backend.
You want to use django packages for "free". For example, I used tastypie for a REST API, and django-social-auth to get OAuth for FB/Twitter logins with very little effort. (On the flip side, with 1.7.0, they've addressed the REST API with endpoints)
According to the documentation, an app is a module which deals a well defined operation.
Is it correct to think about an app as a REST-based service? or is it mandatory to use some framework like piston or tastypie to create a RESTful web service around an app?
Generally, no. Django app is really just a python module, with some interfaces to django internals like models, urls, admin discovery etc.
To implement REST, you still have to manage network communications via views, and this is where you either write your own code or use the help of tastypie/piston/etc.
Please do have a look at django-rest-framework, I just stepped over from tastypie to this new framework, works great!
http://django-rest-framework.org/
Especially the class based views and the browsable api! and may other advantages (e..g. to upload images)
And to answer your question:
The rest-base service is an extra entry to your webapp.
I made some api's for some projects using the django-rest-framework, most project members were surprised they got a webapp as an extra, while it was actually the other way around. You make a django app (with views models and urls) and on top off that you make the api.
I would like to build a new application using node.js but it requires quite a bit of backend management that I would rather not have to build. I have some existing code in django and really like the built in Admin interface for handling the backend management.
Is it possible for me to use something like nginx to direct all traffic to my node.js application except when the url path starts with /admin in which case it would direct the traffic to django?
Alternatively is there something like the admin interface for any of the node.js frameworks for certain databases?
Thanks.
Yes, you can do that.
It might be easier to just put your django admin app on a subdomain, django.example.com.
I'm using Django admin interface with a legacy PHP application. I found out I could build a nicer admin in just a few hours, than the special built one. The frontend is still obviously using PHP and the old code, but I just swapped out the entire admin backend which is now run on django against the database.
It's very nice indeed.
If you are already using Node.js, you might want to look into node-http-proxy which can redirect requests to different places based on the route. It's very easy to setup and runs very fast from my experience.
I wanted to check the status of running Django on the Google App Engine currently and what the benefits of running django on GAE over simply using Webapp.
Django main killer feature, IMHO, is the reuseable apps and middleware. Unfortunately, most current Django apps use models or model forms (django-tags, django-reviews, django-profiles, Pinax apps).
So what are the remaining features or benefits that django has that can still run in Google App Engine (other than what's disabled: the popular django apps, session and authentication middleware, users and admin, models, etc).
Also, is there a list of the Django apps that work in App Engine as well?
app-engine-patch currently has the most of django functional, including sessions, contrib.auth, sites, and some other standard django apps. However, its main drawback (my opinion) is that it uses a zip file of a modified version of django to achieve this functionality and the current maintainers don't seem to have kept pace with current django releases. Currently it seems to be the consensus of the past and present maintainers that this approach is too cumbersome to maintain and therefore no one is currently maintaining it.
google-app-engine-django, uses a monkey patch approach of the latest django version included in the production GAE runtime, so as long as google continues to track django releases you'll be kept up to date regarding django. However, it currently has not fully ported contrib.auth, so you can only authenticate with google accounts - which can be a big drawback depending on whether you want contrib.auth User models to work as you know them on sql backends. There is also no django admin support in the helper as there is in app-engine-patch. A fork of django-app-engine-django exists which adds in some of the contrib apps, such as flatpages, sites, and sitemaps. Also note, it only works on django versions up to 1.1, until issue #3230 Django 1.2 is added to use_library, unless you upload django as a zip file.
On the horizon, the original developer of app-engine-patch has been working on the django-nonrel branch, but this may be pretty far away from being included in a django release. This django developers thread has a lot of information about these efforts.
Separately, there is a google summer of code project working on integrating some aspects of nonrel db's.
app-engine-patch gets most of those things working inside AppEngine - so you can (mostly) use straight Modelforms, use the Django users and admin, etc.
I've only used it for fairly simple projects (being quite new to django), but they claim that most Django apps will work with (at most) minor modifications on appengine. For instance, app-engine-patch uses the AppEngine Model classes rather than the Django classes; and there are some of the basic views that are too inefficient to run on Appengine.
added: google-app-engine-django is similar; but provides a BaseModel that appears identical to Django's BaseModel. My understand is that google-app-engine-django was released by Google, then forked to create app-engine-patch. The maintainers of app-engine-patch seem to have some different goals from the creators of google-app-engine-django, so you may find that one of the two suits your needs better than the other.
Google have provided some articles on running Django apps on appengine; the most recent is actually a guest post from the authors of app-engine-patch.
I've had the best success by simply picking and choosing the Django features that I need and patching them into webapp myself. In my latest project I actually just cut out the webapp stuff entirely. I still import and call several webapp utility functions, but it is mostly a hand rolled application built from the good parts of GAE and Django.
You might be interested to check out web2py, another Python framework that supposedly has less friction between GAE and a "normal" web server.
It is now quite easy to use full Django on GAE:
https://developers.google.com/appengine/articles/django-nonrel#ps
The Django version provided with App Engine has been updated to 1.2.5 with the latest SDK release (1.4.2, changelog). This version is available through the use_library() declaration, so you no longer need to mess around with monkey patching to the same extent.
The GoogleAppEngine (GAE) Python 2.7 runtime provides several third-party libraries that your application can use, in addition to the Python standard library, GAE tools, and GAE Python runtime environment. One of them is Django. The below is copied from the GAE docs page on third-party libraries:
To use Django in Python 2.7, specify the WSGI application and Django library in app.yaml:
...
handlers:
- url: /.*
script: main.app # a WSGI application in the main module's global scope
libraries:
- name: django
version: "1.2"