The other day, I finally accomplished one of my long-standing goals: to go from one of those “Wouldn’t it be cool…” ideas to a working, live app in less than 1 hour. 45 minutes, actually.

It all started with a design meet-up in San Francisco. I can honestly say this was the best meet-up I’ve ever been to: Even though it was announced only two days in advance, more than 200 people RSVPed, and a good number of them showed up. It was a great chance to put faces to familiar names, as well as to make new friends.

But I got to talking with so many people that I didn’t have a chance to get contact info for everybody. So, the next day, I asked the organizers about it and they suggested that everyone who attended leave a link to their Twitter account in a shared Google Doc.

That would work, but I was afraid it would prove to be too much effort. If I’ve learned one thing in my years as a designer, it’s that people are lazy. Instead, what if I built an app that lets the user add their Twitter account to a list in a single click?

The app would work something like this:

1. The user signs into Twitter,
2. A link to their Twitter profile appears on the page,
3. That’s pretty much it!

With my list of requirements complete, I set to work to see how fast I could build this, and I thought it’d be interesting to walk you through the process.

At first, take a peek at how the final app looked like:

Our final bare-bones (but working!) app.

You can also see a demo of the finished product, and find the code on GitHub. (Note: Give it some time to load. Apps hosted on Meteor’s free hosting service often slow down under a lot of traffic.)

A word of warning: This won’t be a traditional tutorial. Instead, it will be a play-by-play walkthrough of how I coded the app in one hour, including the usual dumb mistakes and wrong turns.

Introducing Meteor

I decided to build the app with Meteor. Meteor is a fairly young JavaScript framework that works on top of Node and has a few interesting characteristics.

Meteor’s home page

First, it’s all JavaScript, so you don’t need to deal with one language in the browser and another on the server. That’s right: the same language you use to set up jQuery slider plugins can also be used to query your app’s database! The added benefit of this is that your app now has only a single code base — meaning you can make the same code accessible from both the client and server if you need to.

Meteor is also reactive, meaning that any change to your data is automatically reflected everywhere throughout the app (including the user interface) without the need for callbacks. This is a powerful feature. Imagine adding a task to a to-do list. With reactivity, you don’t need a callback to insert the new HTML element into the list. As soon as Meteor receives the new item, it automatically propagates the change to the user interface, without any intervention on your part!

What’s more, Meteor is real time, so both your changes and the changes made by other users are instantly reflected in the UI.

Like many other modern frameworks, Meteor also speeds up your Web app by transforming it into a single-page Web app. This means that instead of refreshing the whole browser window every time the user changes the page or performs an action, Meteor modifies only the part of the app that actually changes without reloading the rest, and then it uses the HTML5 pushState API to change the URL appropriately and make the back button work.

Not having to update the whole page enables another very powerful feature. Instead of sending HTML code over the network, Meteor sends the raw data and lets the client decide how to render it.

Finally, one of my favorite features of Meteor is simply that it automates a lot of boring tasks, such as linking up and minifying style sheets and JavaScript code. It also takes care of routine stuff for you on the back end, letting you add user accounts to the app with a single line of code.

I’ve been experimenting with Meteor for the past six months, using it first to build Telescope (an open-source social news app), and then in turn using Telescope as a base to create Sidebar (a design links website), and I’ve just released a book about it. I believe that, more than any other framework, Meteor helps you get from idea to app in the shortest possible amount of time. So, if all of this has made you curious, I recommend you give it a try and follow along this short walkthrough.

Step 0: Install Meteor (5 Minutes)

First, let’s install Meteor. If you’re on Mac or Linux, simply open a Terminal window and type:

    curl https://install.meteor.com | /bin/sh
    

Installing Meteor on Windows is a little trickier; you can refer to this handy guide to get started.

Step 1: Create The App (1 Minute)

Creating a Meteor app is pretty easy. Once you’ve installed Meteor, all you need to do is go back to the Terminal and type this:

    meteor create myApp
    

You’ll then be able to run your brand new app locally with this:

    cd myApp
    meteor myApp
    

In my case, I decided to call my app twitterList, but you can call yours whatever you want!

Once you run the app, it will be accessible at http://localhost:3000/ in your browser.

Step 2: Add Packages (1 Minute)

Because I want users to be able to log in with Twitter, the first step is to set up user accounts. Thankfully, Meteor makes this trivially easy as well. First, add the required Meteor packages, accounts-ui and (since we want users to log in with Twitter) accounts-twitter.

Open up a new Terminal window (since your app is already running in the first one) and enter:

    meteor add accounts-ui
    meteor add accounts-twitter

You’ll now be able to display a log-in button just by inserting {{loginButtons}} anywhere in your Handlebars code.

A more complex version of the accounts-ui widget, as seen in Telescope.

I didn’t want to have to bother with styling, so I decided to also include Twitter Bootstrap with my app.

I went to the Twitter Bootstrap website, downloaded the framework, extracted the ZIP file, copied it to my app’s Meteor directory, and then hooked up the required CSS files in the head of my app’s main file.

Ha ha, not really. What is this, 2012? That’s not how it works with Meteor. Instead, we just go back to the Terminal and type:

    meteor add bootstrap
    

Client Vs. Server

I guess at this point I should briefly tell you more about how Meteor apps work. First, we’ve already established that a Meteor app’s code is all JavaScript. This JavaScript can be executed in the browser like regular JavaScript code (think a jQuery plugin or an alert() message), but can additionally be executed on the server (like PHP or Ruby code). What’s more, the same code can even be executed in both environments!

So, how do you keep track of all this? It turns out Meteor has two mechanisms to keep client and server code separate: the Meteor.isClient and Meteor.isServer booleans, and the /client and /server directories.

I like to keep things clean; so, unlike the default Meteor app that gets generated with meteor create (which uses the booleans), I’d rather use separate directories.

Also, note that anything that isn’t in the /client or /server directories will be executed in both environments by default.

Since our app is pretty simple, we won’t actually have any custom server-side code (meaning that Meteor will take care of that part for us). So you can go ahead and create a new /client directory, and  move twitterList.html and twitterList.js (or however your files are called) to it now.

Step 3: Create the Markup (10 Minutes)

I like to start from a static template and then fill in the holes with dynamic data, so that’s what I did. Just write your template as if it were static HTML, except replace every “moving part” with Handlebars tags. So, something like this…

     <a href="http://twitter.com/SachaGreif">Sacha Greif</a></p>
    

… becomes this:

     <a href="http://twitter.com/{{userName}}">{{fullName}}</a&gt;
    

Of course, those tags won’t do anything yet and will appear blank. But we’ll match them up with real data pretty soon. Next, I deleted the contents of twitterlist.html and got to work on my HTML. This is the code I had after this step:

    <head>
      <title>Who Was There?</title>
    </head>
    <body>
      <div class="container">
        <div class="row">
        <div class="span6">
          <div class="well">
            <h4>Did you go to the <a href="http://www.meetup.com/Meteor-SFBay/events/115875132/">Designer Potluck</a>? Sign in with Twitter to add your name.</h4>
            {{loginButtons}}
          </div>
          <table class="table">
             <tr>
    <td>
      <a target="_blank" href="http://twitter.com/{{userName}}"><img src="{{image}}"/> {{fullName}}</a>
    
    </td>
    </tr> 
          </table>
        </div>
      </div>
    </div>
    </body>
    

Step 4: Configure Twitter Sign-In (3 Minutes)

You’ll have noticed the {{loginButtons}} Handlebars tag, which inserts a log-in button on your page. If you try to click it right now, it won’t work, and Meteor will ask you for additional information.

You’ll need to fill in your app’s Twitter credentials. Larger view.

To get this information, we first need to tell Twitter about our app. Follow the steps on the screen and create a new Twitter app; once you’re done, try logging in. If everything has worked right, you should now have a user account in the app!

Creating a new Twitter app. Larger view.

To test this out, open your browser’s console (in the WebKit inspector or in Firebug) and type this:

    Meteor.user()
    

This will retrieve the currently logged-in user, and, if everything has gone right, it will give you your own user object in return (something like Object {_id: "8ijhgK5icGrLjYTS7", profile: Object, services: Object}).

Step 5: Split It Into Templates (5 Minutes)

You’ll have noticed that our HTML has room to display only a single user. We’ll need some kind of loop to iterate over the whole list. Thankfully, Handlebars provides us with the {{#each xyz}} … {{/each}} helper (where xyz are the objects you want to iterate on, usually an array), which does just that.

We’ll also split the code into a few templates to keep things organized. The result is something like this:

    <head>
      <title>Who Was There?</title>
    </head>
    
    <body>
      <div class="container">
        {{> content}}
      </div>
    </div>
    </body>
    
    <template name="content">
      <div class="row">
        <div class="span6">
          <div class="well">
            {{loginButtons}}
          </div>
          <table class="table">
          {{#each users}}
            {{> user}}
          {{/each}}
          </table>
        </div>
    </template>
    
    <template name="user">
     <tr>
    <td>
      <a target="_blank" href="http://twitter.com/{{userName}}"><img src="{{image}}"/> {{fullName}}</a>
    </td>
    </tr> 
    </template>
    

Step 6: Hook Up Our Template (5 Minutes)

Our template is all set up, but it’s iterating over empty air. We need to tell it what exactly this users variable in the {{#each users}} block is. This block is contained in the content template, so we’ll give that template a template helper.

Delete the contents of twitterlist.js, and write this instead:

    Template.content.users = function () {
      return Meteor.users.find();
    };
    

What we’re doing here is defining Template.content.users as a function that returns Meteor.users.find().

Meteor.users is a special collection created for us by Meteor. Collections are Meteor’s equivalent of MySQL tables. In other words, they’re a list of items of the same type (such as users, blog posts or invoices). And find() simply returns all documents in the collection.

We’ve now told Meteor where to find that list of users, but nothing’s happening yet. What’s going on?

Step 7: Fix Our Tags (5 Minutes)

Remember when we typed this?

    <a target="_blank" href="http://twitter.com/{{userName}}"><img src="{{image}}"/> {{fullName}}</a>
    

The {{userName}}, {{image}} and {{fullName}} are just random placeholders that I picked for the sake of convenience. We’d be pretty lucky if they corresponded to actual properties of our user object! (Hint: they don’t.)

Let’s find out the “real” properties with the help of our friend, the browser console. Open it up, and once more type this:

    Meteor.user()
    

The object returned has all of the fields we need. By exploring it, we can quickly find out that the real properties are actually these:

• {{services.twitter.screenName}}
• {{services.twitter.profile_image_url}}
• {{profile.name}}

Let’s make the substitutions in our template and see what happens.

It works! Our first and only user (you!) should now appear in the list. We’re still missing some fields, though, and only the user’s full name appears. We need to dig deeper into Meteor to understand why.

A Database On The Client

We haven’t really touched on what Meteor does behind the scenes yet. Unlike, say, PHP and MySQL, with which your data lives only on the server (and stays there unless you extract it from the database), Meteor replicates your server-side data in the client and automatically syncs both copies.

This accomplishes two things. First, reading data becomes very fast because you’re reading from the browser’s own memory, and not from a database somewhere in a data center.

Secondly, modifying data is extremely fast as well, because you can just modify the local copy of the data, and Meteor will replicate the changes for you server-side in the background. But this new paradigm comes with a caveat: We have to be more careful with data security.

Step 8: Make the App Secure (1 Minute)

We’ll address data security in terms of both writing and reading. First, let’s prevent people from writing whatever they want to our database. This is simple enough because all we need to do is remove Meteor’s insecure package:

    meteor remove insecure
    

This package comes bundled with every new Meteor app to speed up development (letting you insert data client-side without having to set up all of the necessary checks and balances first), but it is obviously not meant for production. And because our app won’t need to write to the database at all (except for creating new users — but that’s a special case that Meteor already takes care of), we’re pretty much done!

More On Security

While we’re on the topic of security, Meteor apps also come with a second default package, autopublish, which takes care of sending all of the data contained in your server-side collections to the client.

Of course, for a larger app, you probably won’t want to do that. After all, some of the information in your database is supposed to remain private, and even if all your data is public, sending all of it to the client might not be good for performance.

In our case, this doesn’t really matter because we do want to “publish” (i.e. send from the server to the client) all of our users. Don’t worry, though — Meteor is still smart enough not to publish sensitive information, such as passwords and authentication tokens, even with autopublish on.

Step 9: Add Follow Buttons (8 Minutes)

While visitors can now click on a name to go to their Twitter profile, simply displaying follow buttons for each user would be much better. This step took a little tinkering to get right. It turns out that Twitter’s default follow button code doesn’t play nice with Meteor.

After 15 minutes of unsuccessful attempts, I turned to the Google and quickly found that for single-page apps, Twitter suggests using an iframe instead.

This worked great:

    <iframe style="width: 300px; height: 20px;" src="//platform.twitter.com/widgets/follow_button.html?screen_name={{services.twitter.screenName}}" height="240" width="320" frameborder="0" scrolling="no"></iframe>

Step 10: Deploy (1 Minute)

The last step is to deploy our app and test it in production. Once again, Meteor makes this easy. No need to find a hosting service, register, launch an instance, and do a Git push. All you need to do is go back to the Terminal and type this:

    meteor deploy myApp
    

Here, myApp is a unique subdomain that you pick (it doesn’t have to be the same as the app’s name). Once you’ve deployed, your app will live at http://myapp.meteor.com. Go ahead and ask a few people to register: You’ll see their Twitter profiles added to the list in real time!

Going Further

Of course, I had to gloss over a lot of key Meteor concepts to keep this tutorial light. I barely mentioned collections and publications, and I didn’t even really talk about Meteor’s most important concept, reactivity. To learn more about Meteor, here are a few good resources:

• Documentation, Meteor
  This is a required reference for any Meteor developer. And it’s cached, meaning you can even access it offline.
• EventedMind
  Chris Mather puts out two Meteor screencasts every Friday. They’re a great help when you want to tackle Meteor’s more advanced features.
• Discover Meteor
  I’m obviously biased, but I think our book is one of the best resources to get started with Meteor. It takes you through building a real-time social news app (think Reddit or Hacker News) step by step.
• Blog, Discover Meteor
  We also make a lot of information available for free on our blog. We suggest looking at “Getting Started With Meteor” and “Useful Meteor Resources.”
• “Prototyping With Meteor”
  A tutorial we wrote for NetTuts that takes you through building a simple chat app.

I truly believe Meteor is one of the best frameworks out there for quickly building apps, and it’s only going to get better. Personally, I’m really excited to see how the framework evolves in the next couple of months. I hope this short tutorial has given you a taste of what Meteor’s all about and has made you curious to learn more!

(il) (ea) (al)

© Sacha G for Smashing Magazine, 2013.

Responsive design is a relatively new term in web design. It was only coined three years ago in May of 2010, when web designer Ethan Marcotte used the term in his article for A List Apart.

Today, there’s even a mini debate going on regarding whether responsive design is here to stay or whether it’s just a flash in the pan. Only time will tell, but for now, it’s clear that responsive design strives to make the user experience as comfortable as possible.

Responsive design is a web design philosophy that focuses on creating sites that give users an enhanced viewing experience. This includes features such as effortless navigation and reading, and a minimum of browser resizing, scrolling and panning. All of this takes place across a range of different devices, from desktops to smartphones.

Since this web design approach is still in a fledgling state, you may not be totally clear on what responsive design is all about. Is it more about seamlessly displaying content across multiple platforms, or is it mainly about helping businesses build more attractive sites to increase their sales through a better user experience?

Mashable has already gone out on a limb and called 2013 the year of responsive design. While that remains to be seen, some basic aspects of responsive design are standards that will never go away. Here are the most important responsive design facts to familiarize yourself with.

There’s a difference between responsive design and mobile design

You’d be forgiven for thinking that responsive design and mobile design are one and the same — but they’re not. Sure, responsive design does create websites so that they both respond to a browser’s size and are mobile-friendly, but responsive design really is whole web design. The problem with referring to this web design approach as mobile design is that it’s inherently limiting, which does a disservice to the approach itself.

The most effective responsive websites may be viewed as they were meant to be, across a range of resolutions. This includes everything from the usual 1024×768 pixels to the 1920×1080 displays and everything in between. Sites like these also look splendid on tablets (both retina and standard displays), as well as on smartphones. If a web designer looks at responsive design solely through the context of mobile, then he’s potentially missing out on a broader user experience. 

At the same time, mobile is a really opportune starting point for the entire responsive design discussion. It’s been the norm to begin with a mobile scheme and then expand this design to additional sizes as a responsive website is developed. Lots of designers believe it’s simpler to grow visuals rather than to minimize them.

Quality and image size are priorities 

If there’s a rule that web designers ought to follow, it’s that image quality is a whole lot more vital than the actual number of images. The reason is that a low-quality image simply doesn’t look attractive in any size. The time it takes a site to load an image is almost as important as the size. Mobile users will agree with this because they have limited bandwidth with which to contend.

What’s a web designer to do? Simply reach a smart balance between load time and quality. This includes scaling images with CSS height and width properties, steering clear of loading full-size images, and optimizing images for the Internet. Prior to uploading, it’s highly advised to crop any images and save each picture at the smallest size possible, as long as it still maintains sharp, visual quality.

Check out Sony USA’s website. Note how all the images are super sharp in quality, no matter what size they are. Once you visit the site or refresh the homepage, also note how fast the images load. You don’t have to wait more than a second for everything to come into focus extremely sharply.

Designers have many choices when incorporating images in a responsive setting. They can use only a few images; lessen the use of images within mobile-sized schemes; permit images to mask themselves in mobile surroundings; or utilize various file sizes and versions. These choices will work effectively, although some developers are against hiding images, because the user will still have to load the images in spite of them being unseen.

Let’s talk about responsive type

Type shouldn’t be one size fits all. One kind of font that looks appealing to the eye on your desktop may be horrid on your smartphone. Typography must follow the same rules as other aspects of responsive design.

The most important aspect of responsive typography is the line length. For smooth readability, type ought to be optimized based on the width of the screen. The rule of thumb, for desktop websites, is that between 50 and 75 characters a line is ideal; for mobile devices, just between 35 to 50 characters is ideal.

Type must also be easily read vertically. Lots of sites utilize a line space that’s up to 140 percent of the screen’s point size for bigger blocks of text. If the screen is smaller, more space should be added.

Even the specific typeface that’s utilized is significant. Fancy fonts and novelty typefaces have the ability to look visually appealing on bigger screens, yet they’re hard to read if the point size is small. These sorts of fonts should have lots of space between them. When you work with smaller sizes, it’s easiest to utilize normal sans serif styles and even strokes.

On Hardboiled Web Design’s site, you can see a lot of these principles being followed, making for good responsiveness. Note how its line length of text on a desktop — while on average greater than the ideal recommendation of 50 to 75 characters — is comprised of a typeface that’s clean and easy to read. In addition, the line space is also greater than the point size of the font. On mobile devices, the site’s responsiveness performs even better: On an iPhone 5 display, the number of characters per line was approximately 67, which is just a bit over the ideal rule of between 35 and 50 characters.

Don’t forget about navigation

When it comes to the user experience — which is one of the most important factors that web designers should think about — navigation is right at the top of priorities. Navigation has to be smooth and efficient to ensure a comfortable user experience.

Effective responsive design must ensure this by paying extra attention to the specific width of a given browser. A site that uses responsive design well will lay out its site navigation in different areas, all dependent on the browser’s width. One of the best examples of this is Food Sense’s site navigation.

It would be a mistake for responsive design to scale the site navigation to larger proportions on devices with bigger screens.

The takeaway of responsive design

So now, when you hear web designers talking about responsive design, you’ll know that it isn’t just about making a website look good and run smoothly on smaller, mobile screens. You’ll know that this design approach is based on the principle of making websites of all sizes provide the most optimal experience to the user — no matter what they’re using to view the site.

Responsive design is still a relatively new concept, at least to most people who just view websites on the internet. That’s why so many people still can’t agree on what makes responsive design…responsive design. Is it about seeing everything properly on mobile screens? Is it just about load times and high-quality images that will please the eye? Is it about a clean design and easy-to-read typefaces? 

It’s all of that and more. Those are just the fundamentals of this web design approach, but responsive design is still evolving and changing, so chances are good that additional elements will be considered, too. In the end, it’s about enhancing the user experience, because no one wants to deal with a website that’s slow, blurry, hard to read, cluttered or difficult to navigate.

Is responsive design just a trend? What are the key aspects of responsive design? Let us know your thoughts in the comments.

Featured image/thumbnail, via s58y

The Ultimate Mobile Design Resource Bundle – only $29!

In this review we look at WPTouch Pro 3, a WordPress plugin which allows you to create a customized mobile site from within WordPress, using your existing layout as the source material.

Cosentry expands their cloud based offerings to now include application migration services, cloud deployment and HTML5 mobile enablement with the help of their new partnership with AppShark.

Many web applications require users to sign in and out in order to perform important tasks (like administration duties). In this article, we’ll create an authentication system for our application.

In the previous article, we built a contact page using the Flask-WTF and Flask-Mail extensions. We’ll use Flask-WTF, once again, this time to validate a user’s username and password. We’ll save these credentials into a database using yet another extension called Flask-SQLAlchemy.

You can find the source code for this tutorial on GitHub. While following along with this tutorial, when you see a caption, such as Checkpoint: 13_packaged_app, it means that you can switch to the GIT branch named “13_packaged_app” and review the code at that point in the article.

Growing the Application

So far, our Flask app is a fairly simple application. It consists of mostly static pages; so, we’ve been able to organize it as a Python module. But now, we need to reorganize our application to make it easier to maintain and grow. The Flask documentation recommends that we reorganize the app as a Python package, so let’s start there.

Our app is currently organized like this:

flaskapp/
    └── app/
            ├── static/
            ├── templates/
            ├── forms.py
            ├── routes.py
            └── README.md

To restructure it as a package, let’s first create a new folder inside app/ named intro_to_flask/. Then move static/, templates/, forms.py and routes.py into intro_to_flask/. Also, delete any .pyc files that are hanging around.

flaskapp/
    └── app/
            ├── intro_to_flask/
            │      ├── static/
            │      ├── templates/
            │      ├── forms.py
            │      ├── routes.py
            └── README.md

Next, create a new file named __init__.py and place it inside intro_to_flask/. This file is required to make Python treat the intro_to_flask/ folder as a package.

flaskapp/
    └── app/
            ├── intro_to_flask/
            │      ├── __init__.py
            │      ├── static/
            │      ├── templates/
            │      ├── forms.py
            │      ├── routes.py
            └── README.md

When our app was a Python module, the application-wide imports and configurations were specified in routes.py. Now that the app is a Python package, we’ll move these settings from routes.py into __init__.py.

app/intro_to_flask/__init__.py

from flask import Flask
    
    app = Flask(__name__)
    
    app.secret_key = 'development key'
    
    app.config["MAIL_SERVER"] = "smtp.gmail.com"
    app.config["MAIL_PORT"] = 465
    app.config["MAIL_USE_SSL"] = True
    app.config["MAIL_USERNAME"] = 'contact@example.com'
    app.config["MAIL_PASSWORD"] = 'your-password'
    
    from routes import mail
    mail.init_app(app)
    
    import intro_to_flask.routes

The top of routes.py now looks like this:

app/intro_to_flask/routes.py

from intro_to_flask import app
    from flask import render_template, request, flash
    from forms import ContactForm
    from flask.ext.mail import Message, Mail
    
    mail = Mail()
    .
    .
    .
    # @app.route() mappings start here

We previously had app.run() inside of routes.py, which allowed us to type $ python routes.py to run the application. Since the app is now organized as a package, we need to employ a different strategy. The Flask docs recommend adding a new file named runserver.py and placing it inside app/. Let’s do that now:

flaskapp/
    └── app/
            ├── intro_to_flask/
            │      ├── __init__.py
            │      ├── static/
            │      ├── templates/
            │      ├── forms.py
            │      ├── routes.py
            ├── runserver.py        
            └── README.md

Now take the app.run() call from routes.py and place it inside of runserver.py.

app/runserver.py

from intro_to_flask import app
    
    app.run(debug=True)

Now you can type $ python runserver.py and view the app in the browser. From the top, here’s how you’ll enter your development environment and run the app:

$ cd flaskapp/
    $ . bin/activate
    $ cd app/
    $ python runserver.py

The app is now organized as a package, we’re ready to move on and install a database to manage user credentials.

— Checkpoint: 13_packaged_app —

Flask-SQLAlchemy

We’ll use MySQL for our database engine and the Flask-SQLAlchemy extension to manage all of the database interaction.

Flask-SQLAlchemy uses Python objects instead of SQL statements to query the database. For example, instead of writing SELECT * FROM users WHERE firstname = "lalith", you would write User.query.filter_by(username="lalith").first().

The moral of this aside is to not completely rely on, or abandon a database abstraction layer like Flask-SQLAlchemy, but to be aware of it, so that you can determine when it’s useful for your needs.

But why can’t we just write raw SQL statements? What’s the point of using this weird syntax? As with most things, using Flask-SQLAlchemy, or any database abstraction layer, depends on your needs and preferences. Using Flask-SQLAlchemy allows you to work with your database by writing Python code instead of SQL. This way you don’t have SQL statements scattered amidst your Python code, and that’s a good thing, from a code quality perspective.

Also, if implemented correctly, using Flask-SQLAlchemy will help make your application to be database-agnostic. If you start building your app on top of MySQL and then decide to switch to another database engine, you shouldn’t have to rewrite massive chunks of sensitive database code. You could simply switch out Flask-SQLAlchemy with your new database abstraction layer without much of an issue. Being able to easily replace components is called modularity, and it’s a sign of a well designed application.

On the other hand, it might be more intuitive and readable if you write raw SQL statements instead of learning how to translate it into Flask-SQLAlchemy’s Expression Language. Fortunately, it’s possible to write raw SQL statements in Flask-SQLAlchemy too, if that’s what you need.

The moral of this aside is to not completely rely on, or abandon a database abstraction layer like Flask-SQLAlchemy, but to be aware of it, so that you can determine when it’s useful for your needs. For the database queries in this article, I’ll show you both the Expression Language version and the equivalent SQL statement.

Installing MySQL

Check to see if your system already has MySQL by running the following command in your terminal:

$ mysql --version

If you see a version number, you can skip to the “Creating a Database” section. If the command was not found, you’ll need to install MySQL. With the large variety of different operating systems out there, I’ll defer to Google to provide installation instructions that work for your OS. The installation usually consists of running a command or an executable. For example, the Linux command is:

$ sudo apt-get install mysql-server mysql-client

Creating a Database

Once MySQL is installed, create a database for your app called ‘development‘. You can do this from a web interface like phpMyAdmin or from the command line, as shown below:

$ mysql -u username -p
    Enter password:
    
    mysql> CREATE DATABASE development;

Installing Flask-SQLAlchemy

Inside the isolated development environment, install Flask-SQLAlchemy.

$ pip install flask-sqlalchemy

When I tried to install Flask-SQLAlchemy, I received an error stating that the installation had failed. I searched the error and found that others had resolved the problem by installing libmysqlclient15-dev, which installs MySQL’s development files. If your Flask-SQLAlchemy installation fails, Google the error for solutions or leave a comment and we’ll try to help you figure it out.

Configuring Flask-SQLAlchemy

Just as we did with Flask-Mail, we need to configure Flask-SQLAlchemy so that it knows where the development database lives. First, create a new file named models.py, along with adding in the following code

app/intro_to_flask/models.py

from flask.ext.sqlalchemy import SQLAlchemy
    
    db = SQLAlchemy()

Here we import the SQLAlchemy class from Flask-SQLAlchemy (line one) and create a variable named db, containing a usable instance of the SQLAlchemy class (line three).

Next, open __init__.py and add the following lines after mail.init_app(app) and before import intro_to_flask.routes.

app/intro_to_flask/__init__.py

app.config['SQLALCHEMY_DATABASE_URI'] = 'mysql://your-username:your-password@localhost/development'
    
    from models import db
    db.init_app(app)

Let’s go over this:

1. Line one tells the Flask app to use the ‘development‘ database. We specify this through a data URI which follows the pattern of: mysql://username:password@server/database. The server is ‘localhost’ because we’re developing locally. Make sure to fill in your MySQL username and password.
2. db, the usable instance of the SQLAlchemy class we created in models.py, still doesn’t know what database to use. So we import it from models.py (line three) and bind it to our app (line four), so that it also knows to use the ‘development‘ database. We can now query the ‘development‘ database through our db object.

Now that our configuration is complete, let’s ensure that everything works. Open routes.py and create a temporary URL mapping so that we can perform a test query.

app/intro-to-flask/routes.py

from intro_to_flask import app
    from flask import Flask, render_template, request, flash, session, redirect, url_for
    from forms import ContactForm, SignupForm, SigninForm
    from flask.ext.mail import Message, Mail
    from models import db
    .
    .
    .
    @app.route('/testdb')
    def testdb():
      if db.session.query("1").from_statement("SELECT 1").all():
        return 'It works.'
      else:
        return 'Something is broken.'

First we import the database object (db) from models.py (line five). We then create a temporary URL mapping (lines 9-14) wherein we issue a test query to ensure that the Flask app is connected to the ‘development‘ database. Now when we visit the URL /testdb, a test query will be issued (line 11); this is equivalent to the SQL statement SELECT 1;. If all goes well, we’ll see “It works” in the browser. Otherwise, we’ll see an error message stating what went wrong.

I received an error when I visited the /testdb URL: ImportError: No module named MySQLdb. This meant that I didn’t have the mysql-python library installed, so I tried to install it by typing the following:

$ pip install mysql-python

That installation failed, too. The new error message suggested that I first run easy_install -U distribute and then try the mysql-python installation again. So I did, just like below:

$ easy_install -U distribute
    $ pip install mysql-python

This time the mysql-python installation succeeded, and then I received the “It works” success message in the browser. Now the reason I’m recounting the errors I’ve received and what I did to solve them is because installing and connecting to databases can be a tricky process. If you get an error message, please don’t get discouraged. Google the error message or leave a comment, and we’ll figure it out.

Once the test query works, delete the temporary URL mapping from routes.py. Make sure to retain the “from models import db“” part, because we’ll need it next.

— Checkpoint: 14_db_config —

Create a User Model

It’s not a good idea to store passwords in plain text, for security reasons.

Inside the ‘development‘ database, we need to create a users table where we can store each user’s information. The information we want to collect and store are the user’s first name, last name, email, and password.

It’s not a good idea to store passwords in plain text, for security reasons. If an attacker gains access to your database, they would be able to see each user’s login credentials. One way to defend against such an attack is to encrypt passwords with a hash function and a salt (some random data), and store that encrypted value in the database instead of the plain text password. When a user signs in again, we’ll collect the password that was submitted, hash it, and check if it matches the hash in the database. Werkzeug, the utility library on which Flask is built, provides the functions generate_password_hash and check_password_hash for these two tasks, respectively.

With this in mind, here are the columns we’ll need for the users table:

Just like before, you can create this table from a web interface such as phpMyAdmin or from the command line, as shown below:

mysql> CREATE TABLE users (
    uid INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
    firstname VARCHAR(100) NOT NULL,
    lastname VARCHAR(100) NOT NULL,
    email VARCHAR(120) NOT NULL UNIQUE,
    pwdhash VARCHAR(100) NOT NULL
    );

Next, in models.py, let’s create a class to model a user with attributes for a user’s first name, last name, email, and password.

app/intro_to_flask/models.py

from flask.ext.sqlalchemy import SQLAlchemy
    from werkzeug import generate_password_hash, check_password_hash
    
    db = SQLAlchemy()
    
    class User(db.Model):
      __tablename__ = 'users'
      uid = db.Column(db.Integer, primary_key = True)
      firstname = db.Column(db.String(100))
      lastname = db.Column(db.String(100))
      email = db.Column(db.String(120), unique=True)
      pwdhash = db.Column(db.String(54))
      
      def __init__(self, firstname, lastname, email, password):
        self.firstname = firstname.title()
        self.lastname = lastname.title()
        self.email = email.lower()
        self.set_password(password)
        
      def set_password(self, password):
        self.pwdhash = generate_password_hash(password)
      
      def check_password(self, password):
        return check_password_hash(self.pwdhash, password)

We use the set_password() function to set a salted hash of the password, instead of using the plain text password itself.

Lines one and four already existed in models.py, so we’ll start on line two by importing the generate_password_hash and check_password_hash security functions from Werkzeug. Next, we create a new class named User, inheriting from the database object db‘s Model class (line six.)

Inside of our User class, we create attributes for the table’s name, primary key, and the user’s first name, last name, email, and password (lines 10-14). We then write a constructor which sets the class attributes (lines 17-20). We save names in title case and email addresses in lowercase to ensure a match regardless of how a user types in his credentials on subsequent sign ins.

We use the set_password function (lines 22-23) to set a salted hash of the password, instead of using the plain text password itself. Lastly, we have a function named check_password that uses check_password_hash, to check a user’s credentials on any subsequent sign ins (lines 25-26).

— Checkpoint: 15_user_model —

Sweet! We’ve created a users table and a user model, thereby laying down the foundation of our authentication system. Now let’s build the first user-facing component of the authentication system: the signup page.

Building a Signup Page

Planning

Take a look at Fig. 1 below, to see how everything will fit together.

Fig. 1

Implement SSL site-wide so that passwords and session tokens cannot be intercepted.

Let’s go over the figure from above:

1. A user visits the URL /signup to create a new account. The page is retrieved through an HTTP GET request and loads in the browser.
2. The user fills in the form fields with his first name, last name, email, and password.
3. The user clicks the “Create account” button, and the form submits to the server with an HTTP POST request.
4. On the server, a function validates the form data.
5. If one or more fields do not pass validation, the signup page reloads with a helpful error message, prompting the the user to try again.
6. If all fields are valid, a new User object will be created and saved into the database. The user will then be signed in and redirected to a profile page.

This sequence of steps should look familiar, as it’s identical to the sequence of steps we took to create a contact form. Here, instead of sending an email at the end, we save a user’s credentials to the database. The previous article already explained creating a form in detail, I’ll move more quickly in this section so that we can get to the more exciting parts, faster.

Creating a Signup Form

We installed Flask-WTF in the previous article, so let’s proceed with creating a new form inside forms.py.

app/intro_to_flask/forms.py

from flask.ext.wtf import Form, TextField, TextAreaField, SubmitField, validators, ValidationError, PasswordField
    from models import db, User
    .
    .
    .
    class SignupForm(Form):
      firstname = TextField("First name",  [validators.Required("Please enter your first name.")])
      lastname = TextField("Last name",  [validators.Required("Please enter your last name.")])
      email = TextField("Email",  [validators.Required("Please enter your email address."), validators.Email("Please enter your email address.")])
      password = PasswordField('Password', [validators.Required("Please enter a password.")])
      submit = SubmitField("Create account")
    
      def __init__(self, *args, **kwargs):
        Form.__init__(self, *args, **kwargs)
    
      def validate(self):
        if not Form.validate(self):
          return False
        
        user = User.query.filter_by(email = self.email.data.lower()).first()
        if user:
          self.email.errors.append("That email is already taken")
          return False
        else:
          return True

We start by importing one more Flask-WTF class named PasswordField (line one), which is like TextField except that it generates a password textbox. We’ll need the db database object and the User model to handle some custom validation logic inside the SignupForm class; so we import them too (line two).

Then we create a new class named SignupForm containing a field for each piece of user information we wish to collect (lines 7-11). There’s a presence validator on each field to ensure it’s filled in, and a format validator which requires that email addresses match the pattern: user@example.com.

Next, we write a simple constructor for the class that just calls the base class’ constructor (lines 13-14).

So we’ve added some presence and format validators to our form fields, but we need an additional validator that ensures an account does not already exist with the user’s email address. To do this we hook into Flask-WTF’s validation process (lines 16-25).

Now inside of the validate() function, we first ensure the presence and format validators run by calling the base class’ validate() method; if the form is not filled in properly, validate() returns False (lines 16-17).

Next we define the custom validator. We start by querying the database with the email that the user submitted (line 18). If you remember from our models.py file, the email address is converted to lowercase to ensure a match regardless of how it was typed in. This Flask-SQLAlchemy expression corresponds to the following SQL statement:

SELECT * FROM users 
      WHERE email = self.email.data.lower() 
      LIMIT 1

If a user record already exists with the submitted email, validation fails giving the following error message: “That email is already taken” (lines 21-22).

Using the Signup Form

Let’s now create a new URL mapping and a new web template for the signup form. Open routes.py and import the newly created signup form so that we can use it.

app/intro_to_flask/routes.py

from intro_to_flask import app
    from flask import render_template, request, flash
    from forms import ContactForm, SignupForm

Next, create a new URL mapping.

app/intro_to_flask/routes.py

@app.route('/signup', methods=['GET', 'POST'])
    def signup():
      form = SignupForm()
      
      if request.method == 'POST':
        if form.validate() == False:
          return render_template('signup.html', form=form)
        else:   
          return "[1] Create a new user [2] sign in the user [3] redirect to the user's profile"
      
      elif request.method == 'GET':
        return render_template('signup.html', form=form)

Inside the signup() function, we create a variable named form that contains a usable instance of the SignupForm class. If a GET request has been issued, we’ll return the signup.html web template containing the signup form for the user to fill out.

Otherwise, we’ll see just a temporary placeholder string. For now, the temp string lists the three actions that should take place when the form has been successfully submitted. We’ll come back and replace this string with real code in “The First Signup” section below.

Now that we’ve created a URL mapping, the next step is to create the web template signup.html and place it inside the templates/ folder.

app/intro_to_flask/templates/signup.html

{% extends "layout.html" %}
    
    {% block content %}
      <h2>Sign up</h2>
    
      {% for message in form.firstname.errors %}
        <div class="flash">{{ message }}</div>
      {% endfor %}
      
      {% for message in form.lastname.errors %}
        <div class="flash">{{ message }}</div>
      {% endfor %}
      
      {% for message in form.email.errors %}
        <div class="flash">{{ message }}</div>
      {% endfor %}
      
      {% for message in form.password.errors %}
        <div class="flash">{{ message }}</div>
      {% endfor %}
      
      <form action="{{ url_for('signup') }}" method=post>
        {{ form.hidden_tag() }}
        
        {{ form.firstname.label }}
        {{ form.firstname }}
        
        {{ form.lastname.label }}
        {{ form.lastname }}
        
        {{ form.email.label }}
        {{ form.email }}
        
        {{ form.password.label }}
        {{ form.password }}
        
        {{ form.submit }}
      </form>
        
    {% endblock %}

This template looks just like contact.html. We first loop through and display any error messages if necessary. We then let Jinja2 generate most of the HTML form for us. Remember how in the Signup form class we appended the error message “That email is already taken” to self.email.errors? That’s the same object that Jinja2 loops through in this template.

The one difference from the contact.html template is the omission of the if...else logic.

In this template, we want to register and sign in the user on a successful form submission. This takes place on the back-end, so the if...else statement is not needed here.

Finally, add in these CSS rules to your main.css file so that the signup form looks nice and pretty.

app/intro_to_flask/static/css/main.css

/* Signup form */
    form input#firstname,
    form input#lastname,
    form input#password {
      width: 400px;
      background-color: #fafafa;
      -webkit-border-radius: 3px;
         -moz-border-radius: 3px;
              border-radius: 3px;
      border: 1px solid #cccccc;
      padding: 5px;
      font-size: 1.1em;
    }
    
    form input#password {
      margin-bottom: 10px;
    }

Let’s check out the newly created signup page by typing:

$ cd app/
    $ python runserver.py

And browse to http://localhost:5000/signup in your favorite web browser.

Excellent! We just created a signup form from scratch, handled complex validation, and created a good looking signup page with helpful error messages.

— Checkpoint: 16_signup_form —

If any of these steps were unclear, please take a moment to review the previous article. It covers each step in greater detail, and I followed the same steps from that article, to create this signup form.

The First Signup

Let’s start by replacing the temporary placeholder string in routes.py‘s signup() function with some real code. Upon a successful form submission, we need to create a new User object, save it to the database, sign the user in, and redirect to the user’s profile page. Let’s take this step by step, starting with creating a new User object and saving it to the database.

Saving a New User Object

Add in lines five and 17-19 to

routes.py.

app/intro_to_flask/routes.py

from intro_to_flask import app
    from flask import render_template, request, flash, session, url_for, redirect
    from forms import ContactForm, SignupForm
    from flask.ext.mail import Message, Mail
    from models import db, User
    .
    .
    .
    @app.route('/signup', methods=['GET', 'POST'])
    def signup():
      form = SignupForm()
      
      if request.method == 'POST':
        if form.validate() == False:
          return render_template('signup.html', form=form)
        else:
          newuser = User(form.firstname.data, form.lastname.data, form.email.data, form.password.data)
          db.session.add(newuser)
          db.session.commit()
          
          return "[1] Create a new user [2] sign in the user [3] redirect to the user's profile"
      
      elif request.method == 'GET':
        return render_template('signup.html', form=form)

First, we import the User class from models.py so that we can use it in the signup() function (line five). Then we create a new User object called newuser and populate it with the signup form's field data (line 17).

Next, we add newuser to the database object's session (line 18), which is Flask-SQLAlchemy's version of a regular database transaction. The add() function generates an INSERT statement using the User object's attributes. The equivalent SQL for this Flask-SQLAlchemy expression is:

  INSERT INTO users (firstname, lastname, email, pwdhash)
      VALUES (form.firstname.data, form.lastname.data, form.email.data, form.password.data)  

Lastly, we update the database with the new user record by committing the transaction (line 19).

Signing in the User

Next, we need to sign in the user. The Flask app needs to know that subsequent page requests are coming from the browser of the user who has successfully signed up. We can accomplish this by setting a cookie in the user's browser containing some sort of ID and associating that key with the user's credentials in the Flask app.

This way, the ID in the browser's cookie will be passed to the app on each subsequent page request, and the app will look up the ID to determine whether it maps to valid user credentials.

If it does, the app allows access to the parts of the website that you need to be signed in for. This combination of having a key stored on the client and a value stored on the server is called a session.

Flask has a session object that accomplishes this functionality. It stores the session key in a secure cookie on the client and the session value in the app. Let's use it in our signup() function.

app/intro_to_flask/routes.py

from flask import render_template, request, flash, session
    .
    .
    .
    @app.route('/signup', methods=['GET', 'POST'])
    def signup():
      form = SignupForm()
      
      if request.method == 'POST':
        if form.validate() == False:
          return render_template('signup.html', form=form)
        else:
          newuser = User(form.firstname.data, form.lastname.data, form.email.data, form.password.data)
          db.session.add(newuser)
          db.session.commit()
          
          session['email'] = newuser.email
          
          return "[1] Create a new user [2] sign in the user [3] redirect to the user's profile"
      
      elif request.method == 'GET':
        return render_template('signup.html', form=form)

We start by importing Flask's session object on line one. Next, we associate the key 'email' with the value of the newly registered user's email (line 17). The session object will take care of hashing 'email' into an excrypted ID and storing it in a cookie on the user's browser. At this point, the user is signed in to our app.

Redirecting to a Profile page

The last step is to redirect the user to a Profile page after signing in. We'll use the url_for function (which we've seen in layout.html and contact.html) in conjunction with Flask's redirect() function.

app/intro_to_flask/routes.py

from intro_to_flask import app
    from flask import render_template, request, flash, session, url_for, redirect
    .
    .
    .
    @app.route('/signup', methods=['GET', 'POST'])
    def signup():
      form = SignupForm()
      
      if request.method == 'POST':
        if form.validate() == False:
          return render_template('signup.html', form=form)
        else:
          newuser = User(form.firstname.data, form.lastname.data, form.email.data, form.password.data)
          db.session.add(newuser)
          db.session.commit()
          
          session['email'] = newuser.email
          return redirect(url_for('profile'))
      
      elif request.method == 'GET':
        return render_template('signup.html', form=form)
    

on line two, we import Flask's url_for() and redirect() functions. Then on line 19, we replace our temporary placeholder string with a redirect to the URL /profile. We don't have a URL mapping for /profile yet, so let's create that next.

app/intro_to_flask/routes.py

@app.route('/profile')
    def profile():
    
      if 'email' not in session:
        return redirect(url_for('signin'))
    
      user = User.query.filter_by(email = session['email']).first()
    
      if user is None:
        return redirect(url_for('signin'))
      else:
        return render_template('profile.html')
    

Here we can finally see sessions in action. We start on line four by fetching the browser's cookie and checking if it contains a key named 'email'. If it doesn't exist, that means the user is not authenticated, so we redirect the user to a signin page (we'll create this in the next section).

If the 'email' key does exist, we look up the server-side user email value associated with the key using session['email'], and then query the database for a registered user with this same email address (line seven). The equivalent SQL for this Flask-SQLAlchemy expression is:

SELECT * FROM users WHERE email = session['email'];

If no registered user exists, we'll redirect to the signup page. Otherwise, we render the profile.html template. Let's create profile.html now.

app/intro_to_flask/templates/profile.html

{% extends "layout.html" %}
    {% block content %}
      <div class="jumbo">
        <h2>Profile<h2>
        <h3>This is {{ session['email'] }}'s profile page<h3>
      </div>
    {% endblock %}

I've kept this profile template simple. If we focus in on line five — you'll see that we can use Flask's session object inside Jinja2 templates. Here, I've used it to create a user-specific string, but you could use this ability to pull other types of user-specific information instead.

We're finally ready to see the result of all our hard work. Type the following into your terminal:

$ python runserver.py

Go to http://localhost:5000/ in your favorite web browser, and complete the sign up process. You should be greeted with a profile page that looks like the following screenshot:

Signing up users is a huge milestone for our app. We can adapt the code in our /signup() function and round out our authentication system by allowing users to sign in and out of the app.

— Checkpoint: 17_profile_page —

Building a Signin Page

Creating a signin page is similar to creating a signup page — we'll need to create a signin form, a URL mapping, and a web template. Let's start by creating the SigninForm class in forms.py.

app/intro_to_flask/forms.py

class SigninForm(Form):
      email = TextField("Email",  [validators.Required("Please enter your email address."), validators.Email("Please enter your email address.")])
      password = PasswordField('Password', [validators.Required("Please enter a password.")])
      submit = SubmitField("Sign In")
      
      def __init__(self, *args, **kwargs):
        Form.__init__(self, *args, **kwargs)
    
      def validate(self):
        if not Form.validate(self):
          return False
        
        user = User.query.filter_by(email = self.email.data.lower()).first()
        if user and user.check_password(self.password.data):
          return True
        else:
          self.email.errors.append("Invalid e-mail or password")
          return False

The SigninForm class is similar to the SignupForm class. To sign a user in, we need to capture their email and password, so we create those two fields with presence and format validators (lines 2-3). Then we define our custom validator inside the validate() function (lines 10-15). This time the validator needs to make sure the user exists in the database and has the correct password. If a record does exist with the supplied information, we check to see if the password matches (line 14). If it does, the validation check passes (line 15), otherwise they get an error message.

Next, let's create a URL mapping in routes.py.

app/intro_to_flask/routes.py

...
    from forms import ContactForm, SignupForm, SigninForm
    .
    .
    .
    @app.route('/signin', methods=['GET', 'POST'])
    def signin():
      form = SigninForm()
      
      if request.method == 'POST':
        if form.validate() == False:
          return render_template('signin.html', form=form)
        else:
          session['email'] = form.email.data
          return redirect(url_for('profile'))
                    
      elif request.method == 'GET':
        return render_template('signin.html', form=form) 
    

Once again, the signin() function is similar to the signup() function. We import SigninForm (line two), so that we can use it in the signin() function. Then in signin(), we return the signin.html template for GET requests (lines 17-18).

If the form has been POSTed and any validation check fails, the signin form reloads with a helpful error message (lines 11-12). Otherwise, we sign in the user by creating a new session and redirecting to their profile page (lines 14-15).

Lastly, let's create the web template signin.html.

app/intro_to_flask/templates/signin.html

{% extends "layout.html" %}
    
    {% block content %}
      <h2>Sign In</h2>
    
      {% for message in form.email.errors %}
        <div class="flash">{{ message }}</div>
      {% endfor %}
      
      {% for message in form.password.errors %}
        <div class="flash">{{ message }}</div>
      {% endfor %}
      
      <form action="{{ url_for('signin') }}" method=post>
        {{ form.hidden_tag() }}
        
        {{ form.email.label }}
        {{ form.email }}
        
        {{ form.password.label }}
        {{ form.password }}
        
        {{ form.submit }}
      </form>
        
    {% endblock %}

Similar to signup.html template, we first loop through and display any error messages, then we let Jinja2 generate the form for us.

And that does it for the signin page. Visit http://localhost:5000/signin to check it out. Go ahead and sign in, you should get redirected to your profile page.

— Checkpoint: 18_signin_form —

Signing Out

In "The First Signup" section above, we saw that "signing in" meant setting a cookie in the user's browser containing an ID and associating that ID with the user's data in the Flask app. Therefore, "signing out" means clearing the cookie in the browser and dissociating the user data.

This can be accomplished in one line: session.pop('email', None).

We don't need a form or even a web template to sign out. All we need is a URL mapping in routes.py, which terminates the session and redirects to the Home page. The mapping, therefore, is short and sweet:

app/intro_to_flask/routes.py

@app.route('/signout')
    def signout():
    
      if 'email' not in session:
        return redirect(url_for('signin'))
        
      session.pop('email', None)
      return redirect(url_for('home'))

The user is not authenticated if the browser's cookie does not contain a key named 'email', in that case, we just redirect to the signin page (lines 4-5). Otherwise, we terminate the session (line seven) and redirect back to the home page (line eight).

You can test the sign out functionality by visiting http://localhost:5000/signout. If you're signed in, the app will sign you out and redirect to http://localhost:5000/. Once you've signed out, try visiting the profile page http://localhost:5000/profile. You shouldn't be allowed to see the profile page if you're not signed in, and the app should redirect you back to the Signin page.

— Checkpoint: 19_signout —

Tidying Up

Now we need to update the site header with navigation links for "Sign Up", "Sign In", "Profile", and "Sign Out". The links should change based on whether the user is signed in or not. If the user is signed out, links for "Sign Up" and "Sign In" should be visible. When the user is signed in, we want links for "Profile" and "Sign Out" to appear, while hiding the "Sign Up" and "Sign In" links.

So how can we do this? Think back to the profile.html template where we used Flask's session object. We can use the session object to show navigation links based on the user's authentication status. Let's open layout.html and make the following changes:

app/intro_to_flask/templates/layout.html

<!DOCTYPE html>
    <html>
      <head>
        <title>Flask App</title>
        <link rel="stylesheet" href="{{ url_for('static', filename='css/main.css') }}">
      </head>
      <body>
    
      <header>
        <div class="container">
          <h1 class="logo">Flask App</h1>
          <nav>
            <ul class="menu">
              <li><a href="{{ url_for('home') }}">Home</a></li>
              <li><a href="{{ url_for('about') }}">About</a></li>
              <li><a href="{{ url_for('contact') }}">Contact</a></li>
              {% if 'email' in session %}
              <li><a href="{{ url_for('profile') }}">Profile</a></li>
              <li><a href="{{ url_for('signout') }}">Sign Out</a></li>
              {% else %}
              <li><a href="{{ url_for('signup') }}">Sign Up</a></li>
              <li><a href="{{ url_for('signin') }}">Sign In</a></li>
              {% endif %}
            </ul>
          </nav>
        </div>
      </header>
    
        <div class="container">
          {% block content %}
          {% endblock %}
        </div>
    
      </body>
    </html>

Starting on line 17, we use Jinja2's if...else syntax and the session() object to check if the browser's cookie contains the 'email' key. If it does, then the user is signed in and therefore should see the "Profile" and "Sign Out" navigation links. Otherwise, the user is signed out and should see links to "Sign Up" and "Sign In".

Now give it a try! Check out how the navigation links appear and disappear by signing in and out of the app.

The last task remaining is a similar issue: when a user is signed in, we don't want him to be able to visit the signup and signin pages. It makes no sense for a signed in user to authenticate themselves again. If signed in users try to visit these pages, they should instead be redirected to their profile page. Open routes.py and add the following piece of code to the beginning of the signup() and signin() functions:

if 'email' in session:
      return redirect(url_for('profile'))
    

Here's what your routes.py file will look like after adding in that snippet of code:

app/intro_to_flask/routes.py

@app.route('/signup', methods=['GET', 'POST'])
    def signup():
      form = SignupForm()
    
      if 'email' in session:
        return redirect(url_for('profile')) 
    .
    .
    .
    @app.route('/signin', methods=['GET', 'POST'])
    def signin():
      form = SigninForm()
    
      if 'email' in session:
        return redirect(url_for('profile'))  
      ...
    

And with that we're finished! Try visiting the the "signup" or "signin" pages while you are currently signed in, to test it out.

— Checkpoint: 20_visibility_control —

Conclusion

We've accomplished a lot in this article. We've taken our Flask app from being a simple Python module and turned it into a well organized application, capable of handling user authentication.

There are several directions in which you can take this app from here. Here are some ideas:

• Let users sign in with an existing account, such as their Google account, by adding support for OpenID.
• Give users the ability to update their account information, as well as delete their account.
• Let users reset their password if they forget it.
• Implement an authorization system.
• Deploy to a production server. Note that when you deploy this app to production, you will need to implement SSL site-wide so that passwords and session tokens cannot be intercepted. If you deploy to Heroku, you can use their SSL certificate.

So go forth and continue to explore Flask, and build your next killer app! Thanks for reading.