Is there a straightforward way to set up Django to operate on a directory or set of directories that will also serve other kinds of content?
Right now I have a webserver that is mostly running ColdFusion pages, but I'd like to start moving some sections over to Django. However, due to the existing directory structure it's not ideal to put all of the Django stuff in just one web path. Ideally I'd like to be able to keep using the original directory structure rather than having to use a lot of redirects.
Is there any way to make Django play nice with other things, or does it pretty much need its own root to be happy? The only other solution I can think of is carefully configuring the web server with a lot of rules that purposefully sidestep Django when necessary (for example, instructing it to manually handle anything with a file extension, or to ignore certain directories).
This would be on IIS, if it happened.
You can configure URLs in Django anyway you like. Have a look at the URL dispatcher. So say for instance your site www.example.com, you decide to have /wiki and /blog be developed using Django. You can configure IIS to redirect those urls to Django, while the rest of www.example.com/everythingelse is served by Coldfusion or whatever.
Even a mixed url scheme say /store/mycoldfusion-product-view and /store/django-product-view would be possible though this would require some amount of fancy redirect code depending on your setup.
It sounds as if you have some control over what is being served when. If that's the case, could you use a reverse proxy to segment your namespace? I do this with a lot of different projects; I use nginx, and tell it "these paths are for Wordpress, these paths are for Django, and these paths are for images and other static content."
That's an excellent way of making Django "play nice," as long as you have a disciplined approach to converting some of the paths to one or the other.
An alternative way to set this up would be to daisy chain:
Webserver -> django -> response middleware -> subprocess/pipe/httplib -> coldfusion.
The response middleware would pseudo code something like this:
if response.code in [list of ok responses]:
return
else:
call coldfusion
The advantage of this method would be that you can transition at whatever rate you want. The disadvantage is that it isn't a simple configuration, daisy chains are brittle by nature, and the daisy chain might break.
Related
Forgive me if the wording here is a bit odd. I have a fair amount of experience with python, but I'm pretty new to Django and still trying to get my sea legs.
I've inherited a PHP site from the former System admin at my new job, and I want to rework it into a django app to simplify/cleanup the code.
The PHP site is using .htaccess file with Pubcookie apache module for authentication (as well as some basic checks in the php code to ensure the user checks out against a database of authorized users, but that part i'm less concerned with), and looks like this:
AuthType SecureID
require valid-user
PubcookieAppID "name of the app"
In my apache configs, I have various pubcookie definitions.
LoadModule pubcookie_module /usr/lib/apache2/modules/mod_pubcookie.so
PubcookieGrantingCertFile /usr/local/pubcookie/keys/pubcookie_granting.cert
PubcookieSessionKeyFile /etc/ssl/private/akey.pem
PubcookieSessionCertFile /etc/ssl/certs/acert.pem
PubcookieLogin https://weblogin.domain.com/
PubcookieLoginMethod POST
PubcookieDomain .domain.com
PubcookieKeyDir /usr/local/pubcookie/keys/
PubcookieAuthTypeNames ADUserID null SecurID
My question is...How do I implement this sort of thing on the python end? I have looked at using RemoteUserMiddleware, or PersistentRemoteUserMiddleware.
But most of the information I have found for that doesn't go into great detail about how to actually point your app at the correct login page. The official documentation seems to stop at adding the middleware under middleware in the settings.py file in the django project.
It also bare's mentioning that the weblogin.domain.com is handled by another group that I don't have direct access to, and is not one of my servers so I can't really poke around there.
I realize this is...extremely broad, but any information that could point me in the right direction would be appreciated.
In an ideal scenario, I would like to be able to restrict different views to different authtypes, but I'd be happy to get anything working sensibly.
So, For what it's worth. The answer was to use pubcookie with apache as normal. then use RemoteUserMiddleware or PersistentRemoteeUserMiddleware as expected. As it turns out you don't have to handle any outside configuration for the middleware, it just imports whats shoved at it.
Finally the piece I was really missing, information from apache/pubcookie authentication can be accessed with request.META library from inside django code
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.
I want to make more secure my django virtual host by disabling the access of files that do not belong to my project. So basically I'm looking for similiar like "php_admin_value open_basedir".
Is there a simple way to do this?
Thanks!
There's no need for a setting. As the Django docs state, your code should not be in the docroot anyway:
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.
The only thing that should be served is the wsgi file. So the rest of your files are safe.
Is there a way to setup mulitple sites to run using querystrings rather than domains/subdomains?
I am developing a site that has a Global site and multiple country specific sites (exact list of countries to be confirmed later). For development I have a Global and a Local site created and running on a temporary subdomain. If this works correctly we may run the entire application this way rather than on separate domains (similar to how apple.com appears to work)
I have successfully got the sites running locally as:
global.domain.com
a.domain.com
b.domain.com
but would like them to be able to run as:
www.domain.com/global
www.domain.com/a
www.domain.com/b
We will be implementing multiple languages on certain country sites aswell so locale will need to remain independant.
Could this be done using some sort of URL mapping rather than multiple sites or something? Where can I find information about URL mapping?
There are settings for using virtual folders (see web.config under sites node)
virtualFolder: The prefix to match for incoming URL's.
This value will be removed from the URL and the remainder will be treated as the item path.
How that works in practice I'm not sure - it's on a domain by domain basis, and all your sites will be operating from the same domain.
But I think you might want to reconsider your approach. Sub domains have several advantages. They're simple to configure in the web.config (just add a domain and point it at the right bit of the content tree).
They simplify search engine optimisation - e.g. telling google to target a specific subdomain to a geographical area in Google webmaster tools.
They're simple for visitors to understand.
Bear in mind that if you're going to use multiple languages per site then you will probably want to keep the language parameter in the URL as part of the (virtual) filepath (e.g. www.mysite.com/en-GB/products)
If you use both language and locale in the URL in that way you end up with something like www.mysite.com/UK/en-GB/products
I am farily new to the topic, but I am trying to combine both Django and Pyjamas. What would be the smart way to combine the two? I am not asking about communication, but rather about the logical part.
Should I just put all the Pyjamas generated JS in the base of the domain, say http://www.mysite.com/something and setup Django on a subdirectory, or even subdomain, so all the JSON calls will go for http://something.mysite.com/something ?
As far as I understand now in such combination theres not much point to create views in Django?
Is there some solution for clean urls in Pyjamas, or that should be solved on some other level? How? Is it a standard way to pass some arguments as GET parameteres in a clean url while calling a Pyjamas generated JS?
You should take a look at the good Django With Pyjamas Howto.
I've managed to get the following to work, but it's not ideal. Full disclosure: I haven't figured out how to use the django's template system to get stuff into the pyjamas UI elements, and I have not confirmed that this setup works with django's authentication system. The only thing I've confirmed is that this gets the pyjamas-generated page to show up. Here's what I did.
Put the main .html file generated by pyjamas in django's "templates" directory and serve it from your project the way you'd serve any other template.
Put everything else in django's "static" files directory.
Make the following changes to the main .html file generated by pyjamas: in the head section find the meta element with name="pygwt:module" and change the content="..." attribute to content="/static/..." where "/static/" is the static page URL path you've configured in django; in the body section find the script element with src="bootstrap.js" and replace the attribute with src="/static/bootstrap.js".
You need to make these edits manually each time you regenerate the files with pyjamas. There appears to be no way to tell pyjamas to use a specific URL prefix when generating together its output. Oh well, pyjamas' coolness makes up for a lot.
acid, I'm not sure this is as much an answer as you would hope but I've been looking for the same answers as you have.
As far as I can see the most practical way to do it is with an Apache server serving Pyjamas output and Django being used as simply a service API for JSONrpc calls and such.
On a side note I am starting to wonder if Django is even the best option for this considering using it simply for this feature is not utilizing most of it's functionality.
The issue so far as I have found with using Django to serve Pyjamas output as Django Views/Templates is that Pyjamas loads as such
Main html page loads "bootstrap.js" and depending on the browser used bootstrap.js will load the appropriate app page. Even if you appropriately setup the static file links using the Django templating language to reference and load "bootstrap.js", I can't seem to do the same for bootstrap.js referencing each individual app page.
This leaves me sad since I do so love the "cruftless URLS" feature of Django.