Custom file storage

Django uses storage classes to determine how files are read and written. Normally, the data is just written as files to disk, but there are other possibilities such as storing on remote servers.

It’s easy to write a custom file storage class to override the behaviour of the default FileStorageSystem. In this case, we only need to change the delete method so it does not delete the file.

In custom.py

from django.core.files import storage

class NoDeleteFileStorage(storage.FileSystemStorage):
    def delete(self, name):
        pass

We can then use the custom file storage by making an instance and passing it to the ImageField.

In models.py

from custom import NoDeleteFileStorage

ndfs = NoDeleteFileStorage()

class ImageInstance(models.Model):
    image = models.ImageField(storage=ndfs, ...)

It’s as simple as that! Custom file storage has some interesting possibilities. With it you can handle how files are named or integrate with some caching or CDN.

Mobile phones have had the ability to use the internet in a primitive way for 15 years or so, but it wasn’t until Apple released the iPhone SDK in 2008 and the subsequent development frenzy that ensued, that the surge in mobile internet use really began.

Today’s smartphones transcend simply retrieving email, sending SMSs and making calls and instead enable users to transform their phone in to whatever they want: a gaming machine, a sat nav, or a sleep cycle alarm clock; all with the download of an application. This shift has fundamentally altered the way consumers think about what a phone is and how they use it, so much so, that often its function as a phone becomes secondary.

The current darling of this revolution is Apple’s iPhone which currently has about 140,000 applications on its App Store, and with over 3 billion downloads is easily the most developed marketplace for mobile applications. In fact, stats gathered at the end of 2009 showed Apple captured 99.4% of the mobile application market!

Apple aren’t the only ones driving this push in to mobile application use. Google, Nokia, Palm, RIM (with their Blackberry) and  Microsoft all have their own platform, all offering similar features, but all mostly incompatible.

So with apps being a hot (and potentially lucrative) market and a number of competing platforms to choose from, how do you go about developing and deploying mobile applications?

It boils down to two choices:

• A native application – A native application is one which is installed and runs on the device and is developed using the device’s SDK. Native applications only run on one platform so you need to develop a different application for each platform. Once built, the app can be sold on its respective marketplace such as the App Store, Android Marketplace or Nokia’s Ovi store.
• A mobile web app – A mobile app is a web-based application which runs in the browser of the device. There’s no special deployment necessary, it only requires a browser to use it. The goal is to build a web app which is usable by most, if not all, of the different types of device. However, in practice this isn’t particularity easy – yet.

Actually, if you just require a mobile version of your site, you have the option of doing nothing and hoping that your site is useable enough as it is for users browsing on their mobile device. This depends on how your site was built and the browser which is being used, so there could be a large number of users who may get a less than ideal experience.

Both web and native apps have their pros and cons and the choice often comes down to what you want the app to do, and what your users will expect.

Going Native

The Apple's App Store and Google's Android Marketplace are only two of a number of outlets for native applications

Developing a native application will provide benefits in its performance and tight integration with all the device’s features and APIs. A native application will give your users the best experience by taking full advantage of the full capabilities of the device.

Advantages like :

• They can use all of the device’s features such as its camera, GPS, compass, file system etc.
• They can be sold through a marketplace such as the App Store or Android Marketplace
• They have superior performance compared with a typical web app
• Don’t necessarily need to be connected to a 3G or WiFi network to function *
• They’re not running in a browser so there’s no restriction on the types of application that can be developed

*Improvements brought in with HTML5 will help web apps in some respect on this point.

Because a native app isn’t restricted to running in a browser they can do some pretty intensive things such as an augmented reality app to show you a data overlay on top of live video or full full 3D games. Neither of which would currently be possible with a web app.

But there are downsides, too:

• Typically higher development cost and longer lead time.
• Very little portability across platform – if you want your app to run on both the iPhone and Android it means building two separate versions.

So if you want to do anything that takes full advantage of a device’s capabilities, or do anything custom or unique, you’re likely looking at a native app. However, the issue of building and deploying to many different devices mean the overall cost can be high.

And this is where web-apps can really start to look like a great alternative: A web-based app should be able to run on any device with a browser, right?

Well, sort of.

The Mobile Web

Everything which you interact with on the internet (except the most basic of web pages) is a web app in one form or another: Facebook, Twitter, Flickr, your favourite blog – all in a broad sense are web apps.

The major advantage of web apps are that they can be used wherever you are, from any computer, via almost any browser. No downloading, no software updates and no uninstalling – just open a browser window, type the URL and hit Enter. Add that to fact that all devices have a web browser means that you have a potentially large number of users who are already familiar with how to get to and use your app.

However web development for mobile devices is still developing and it can be difficult to do things which would be straightforward in a native application. John Gruber has a great article on building iPhone Web Apps as an Alternative to the App Store which covers the topic nicely.

Even though currently it’s not possible to build a web app that will do everything a native app does, for some situations a mobile app is perfect. There’s some great work going in with jQTouch which is a tool that makes it easier to build  mobile web apps for both the iPhone and Android, that look and feel more like a native application. There’s also PhoneGap, which enables a web app to be packaged up and deployed as a native application for the iPhone, Blackberry and Android and sold on their respective marketplace / store.

With these types of tools emerging, and the devices themselves becoming more powerful, it’s not long before web apps become the choice for a larger proportion of mobile applications. The fact that Apple (iPhone), Google (Android), Palm (Pre), Nokia and just announced RIM (Blackberry) are all backing the open source WebKit engine to power their web browsers, it’s a major step in getting a consistent experience across multiple devices. Knowing that an app will look and perform the same manner on all these devices is the Holy Grail of web development: write once, run anywhere.

The Webkit browser engine which powers a lot of modern smartphone browsers

Add to this HTML5 and the rapid development of browser technology and we’re closely approaching the point where we can use standard web technologies to build advanced mobile applications. In the next couple of years most, if not all, mobile platforms will have support for the following advanced features all of which will drasticly change both what web apps are capable of and what users will expect from them:

• Pure web-based 3D graphics via WebGL – enabling 3D games and modelling
• Standardised 2D graphics and animation – slick animation and graphics are trademarks of native applications’ rich interfaces
• Standardised video and audio support – no more plugins to watch movies or listen to streaming music
• Communication improvements
• Geolocation support – enable the browser to access your location
• Local storage and SQL databases – meaning data can be stored within the web application itself so you don’t always require an internet connection to use it. Google Apps provide this features already using Google Gears.
• Manifests and offline resource caching – movies and photos are still accessible even if you go offline

The future is looking bright for mobile web app development, and as the tools and browser technology get better, development will shift from native to web-based applications. The overall trend is that the “Internet is the platform” that all applications rely on – and not just the mobile ones.

“…development for a platform is a distraction. It’s taking our eyes off the ball, and ignoring the bigger shift that’s happening beneath our feet.”

Chris Messina – Referring to the fact that we should be developing for the web rather than for a single platform.

These types of device and the market for mobile applications in general is still young and it’s going to take a while for the game to play out. Native mobile applications, with their superior performance, slickness and better capabilities are going to be the choice for demanding or cutting edge applications – at least for the forseable future – but one thing you can bank on is that the web isn’t going anywhere. The web is the inevitable platform, and that means that we’ll see huge growth in web-based apps in the coming years.

Andrew Gleave is the lead developer of iPhone and mobile apps at Red Robot Studios. Considering developing a mobile app? Contact Red Robot Studios to see how we can help.

We’re still going to be building and releasing our own projects but have also decided to offer our development service to clients as well. We have some excellent clients already and will be accepting work from new clients.

Our aim is not just to provide a normal development service but to help our clients achieve their goals. We want to help and advise based on our experience and go the extra mile to provide really great development services to all our clients.

Our main focus is Django development, iPhone and mobile development, but we are well experienced in many other areas including things as diverse as WordPress plugins, Facebook apps and Firefox extensions. We’d love to hear about your great idea, so get in touch!

Some paths need https

If you’re using SSL it makes sense for certain parts of the site to require a secure connection. For example, the admin section.

Previously I shared the secure_required decorator which forces requests to use https for specific views. This works ok, but if you know an entire section of the site under a given path (e.g. /admin/) should be secure, it’s hassle to have to add the decorator to each view.

You can require secure connections over https using webserver config or using Django itself.

Requiring https using Nginx

In your Nginx config file under the section for the unsecure http/port 80 server you can specify a location path and redirect all requests to it to https instead.

server {
    listen 10.10.10.10:80;
    server_name example.com;
...
    location /admin {
        # force admin to use https
        rewrite (.*) https://example.com/$1 permanent;
    }
...
}

Apache and other web servers can have a similar configuration.

If you can configure it in the web server, that’s more efficient because the request can be redirected by the server, without having to contact your Django project. However, it should be fairly rare for requests to be redirected like this so it’s not a big performance issue and sometimes it’s easier to handle things in Django.

Requiring https using Django middleware

In Django it’s easy to write custom middleware which gets called before each request reaches a view.

Here’s a small piece of middleware which checks if the request is over http to a path we want to be secure and if so redirects to the same path but over https.

from django.http import HttpResponsePermanentRedirect
from django.conf import settings

class SecureRequiredMiddleware(object):
    def __init__(self):
        self.paths = getattr(settings, 'SECURE_REQUIRED_PATHS')
        self.enabled = self.paths and getattr(settings, 'HTTPS_SUPPORT')

    def process_request(self, request):
        if self.enabled and not request.is_secure():
            for path in self.paths:
                if request.get_full_path().startswith(path):
                    request_url = request.build_absolute_uri(request.get_full_path())
                    secure_url = request_url.replace('http://', 'https://')
                    return HttpResponsePermanentRedirect(secure_url)
        return None

In settings.py

MIDDLEWARE_CLASSES = (
...
    'myproject.middleware.SecureRequiredMiddleware',
)

HTTPS_SUPPORT = True
SECURE_REQUIRED_PATHS = (
    '/admin/',
    '/accounts/',
    '/management/',
)

SECURE_REQUIRED_PATHS is a list or tuple of paths that should be secure. Any request to a path which starts with one of these will be required to use https.

HTTPS_SUPPORT is a custom setting to make it easier to use this on your dev server without SSL support. Set it to True in the settings for the live server and False in the settings for the dev server.

So there we go, an easy way to require secure https requests for certain parts of your Django site.

Finding Django Developers

As the number of developers increases, it becomes harder to find the person you are looking for. A while ago we added filtering by country, but for large countries such as the US, there are still way too many developer profiles to look through. We now have nearly 700 Django developers on the site and needed to find a better way.

The solution we chose was geocoding the location of each developer so that we can find developers who are close to a given location. Ignoring the technical stuff, it’s very easy to use. Just type in the name of your town or city and get back a list of developers who are nearby.

We’re confident this will make it much easier to find Django developers and may add other search options in future. As always, we’re happy to hear your feedback.

Follow us on Twitter

We’ve also added a Djangogigs Twitter account which you can follow to see the latest gigs as they are added.

We wanted to make it as simple as possible for people to create a job board, and that means doing something about the need for you to already have an account before being able to try out the service.

We considered integrating OpenID with our registration system – which we may implement at some point – but decided that it would be far nicer if we could do away with the user having to provide any details at all.

You can now just go straight to the create a job board page, give your board a name, and that’s it – your own job board created in record time, and you haven’t even needed to give your email address!

If you decide that you want to give your job board a proper spin and publish your board and its jobs live on the internet, you can then create an account and start a 14-day free trial.

Hopefully, by leaving the requirement to register until the last moment, it helps newcomers get a feel for their job board quickly, and with minimum fuss.

• Custom Themes and Styles and user-defined job roles – Enabling users to choose custom colours and themes for their board and to add custom job roles so jobs can be categorized for easy browsing and filtering.
• Custom domain support – You can now specify a custom domain for a job board so if you own newyorkaccountancyjobs.com, you can now run a job board directly from that address. Or, if you already have a company website, you can use a jobs subdomain like jobs.mycompany.com

To keep up to date with the changes and improvements we’re making to Easy Job Boards, check out the Easy Job Boards blog.

This article covers some tips and tricks we discovered while building the app, and how you can use Django to get fine-grained control as to which resources are available securely.

Why bother with security?

We all know that data sent over http is cleartext and can potentially be read on any network between the client and server. But the risk feels pretty minimal and many sites don’t bother using SSL to encrypt sensitive traffic. For online banking and ecommerce, you’d be crazy not to use it, but for other sites, why bother?

The chances of your http requests being snooped upon by an ISP, intermediate networks or your hosting company seem minimal. But one potentially big risk is users accessing your website on an open wireless network.

For example, perhaps your user has an unsecured wireless home or office network or maybe they use wireless networks in coffee shops and airports: It’s really easy in this situation for sensitive requests to be snooped upon.

The data on your website may not be sensitive, but if you use Django’s admin or authentication frameworks, two important bits of information are passed as cleartext.

When a user logs in, their username and password is posted in cleartext. Assuming login is successful, each subsequent request includes a cookie containing the sessionid. The sessionid is just a random string, but if you know the sessionid of a user, it is trivial to hijack the session and have the same access to the website as that user does until they log out.

Encrypting login sessions

If you want to be sure user credentials and sessions cannot be compromised by eavesdroppers, you need to use SSL encryption. Install an SSL certificate on the server so that traffic is encrypted end-to-end between client and server.

You probably don’t want the whole site to be secure because it will be a lot slower and significantly increase the load on your servers. Instead, you can be selective about which parts of the site should use https instead of http. If you want user sessions to be secure, you should make sure that logging in and all parts of the site that require a logged-in user use https.

SSL

Standard SSL certificates are pretty cheap these days – under $20 per year. We go some from RapidSSLOnline. Each secure site needs its own IP address, so if you’re hosting multiple sites using virtual hosting, you’ll need to look in to getting some dedicated IPs.

There are lots of guides to installing SSL certificates and configuring web servers such as Apache, Lighttpd and Nginx, so I won’t cover that here.

Making Django sessions secure

Django uses cookies for its sessions. When a cookie is set, you can specify that it be a secure cookie, meaning it is only ever passed over https and not in http requests. We can tell Django to use secure cookies for sessions by adding a setting to settings.py

SESSION_COOKIE_SECURE = True

If you set Django to use secure cookies then try to log in over http you will get the error

“Looks like your browser isn’t configured to accept cookies. Please enable cookies, reload this page, and try again.”

This happens because Django sets the cookie, but it’s a secure cookie, so when the page loads over http, Django can’t see the cookie and so assumes cookies are disabled in your browser.

Requiring https for admin

To avoid this cookie warning and make sure you only ever pass your admin credentials over https, you can configure your web server so that any http requests are redirected to https.

For example, in Nginx it would look like:

server {
    server_name example.com;
    location /admin {
        # force admin to use https
        rewrite (.*) https://example.com/$1 permanent;
    }
...
}

In Apache, something like:

<Location /admin>
    RewriteRule (.*) https://example.com/$1 [L,R=301]
    ...
</Location>

Of course, these bits of config should go in the http config, not the https config or you will cause infinite redirects!

Requiring https for certain views

If all the logged-in parts of your site are in a certain path (e.g. /accounts/ and /members/) you can configure your web server in the same way to require https for these locations.

If certain views require https (e.g. /members/bert/ is public but /members/bert/edit/ requires login), you may want to check request.is_secure() in those views. A neat way to do it is with a decorator which can also redirect any http requests to https.

from django.conf import settings
from django.http import HttpResponseRedirect

def secure_required(view_func):
    """Decorator makes sure URL is accessed over https."""
    def _wrapped_view_func(request, *args, **kwargs):
        if not request.is_secure():
            if getattr(settings, 'HTTPS_SUPPORT', True):
                request_url = request.build_absolute_uri(request.get_full_path())
                secure_url = request_url.replace('http://', 'https://')
                return HttpResponseRedirect(secure_url)
        return view_func(request, *args, **kwargs)
    return _wrapped_view_func

Then on your view:

@secure_required
@login_required
def edit_member(request, slug):
    ...

Moving between http and https pages

It’s normal to use full path URLs like /accounts/login/ and /blog/. Bear in mind that if you are accessing the site over https and follow one of these links, you will also access them over https. If you want to be explicit, you need to specify the protocol and domain in the links, e.g. https://example.com/accounts/login/ and http://example.co/blog/ .

For $20 and a bit of config, you can secure logged-in sessions on your site and protect yourself and your users from being compromised by eavesdroppers. There are still plenty of sites where this is overkill, but you can see now how easy it is to secure your Django site with SSL.

It was launched in September 2007 and was designed to give employers and developers a central location to list and respond to job listings, and quickly became popular within the Django community.

Since then, we’ve had about 550 gigs and nearly 800 developers submitted to the site. And even during the downturn in the job market, we’re still getting a similar number of gig submissions as last year – good news for django developers.

Since Scott and I formed Red Robot Studios last year, we wanted to take Djangogigs under the Red Robot Studios banner and take some time to add long-awaited features. Between setting up the company and releasing easyjobboards, this is the first chance we’ve had to dedicate some time to djangogigs and add some much-requested features. This is only the tip of the iceberg and we want to grow and improve the site to help fulfil the community’s needs and make it more useful to all.

New Features

• Gigs can now be edited and removed
• We’ve given the interface a refreshed and made it clearer and more consistent
• You can now use Markdown syntax to structure gig and developer descriptions
• Added dynamic address and location lookup by integrating with Google maps
• Lots of internal improvements to how gigs and developers are approved and managed

We’ve also moved to a faster server and added a feedback widget to help and encourage people to get in touch.

Since we’ve integrated with the Google Maps API, the location details of gigs and developers is now in a common format which will allow us to split, cluster, map and filter listings, making it easier to find what you’re looking for. For example, we will be able to provide fine-grain control: just jobs in San Francisco, and conversely filter by continent or country.

We’ve only added initial support for this (at the country level), but we’d love to hear what you would find useful.

We have lots planned for the future, and intend to integrate parts of our easy-to-use job board application in to djangogigs in the future.

We’d especially like to hear your feedback as to what you think needs to be improved upon to make the site more useful to both developers and employers.

You can send all feedback, issues or suggestions to us at our support page along with anything else you’d like us to address.

Thanks for your support.

Andrew and Scott
The guys from Red Robot Studios

Today we changed to easyjobboards.com with a fresh new logo and more obvious domain name. We hope this will be much clearer to people who are looking for a hosted job board solution. We chose “easy” to emphasise one of our key goals: make it easy for non-technical folks to start and run a job board.

We have many improvements in the pipeline and we’d love to hear your suggestions.