The percussion quartet Umbilicus, featuring Tom Goldstein, music, Shelly Purdy ’10, Will Redman ’98, and Rob Wolk ’11, performs Friday, November 15 at 8 p.m. at The Parlor, in a program including a set with new Department of Music faculty member, Patrick Crossland, trombone. Umbilicus’ set will include work by Anna Rubin, music.

The Parlor
800 St. Paul Street
Baltimore, MD

Umbilicus was founded in 2012 in reaction to the generic contemporary percussion quartet, with the intention of promoting and performing a more experimental repertoire, much if it composed by its members.

The suggested donation for this event is $5-$7.

Authentication is required for virtually any type of web application. In this tutorial, I’d like to show you how you can go about creating a small authentication application using Laravel 4. We’ll start from the very beginning by creating our Laravel app using composer, creating the database, loading in the Twitter Bootstrap, creating a main layout, registering users, logging in and out, and protecting routes using filters. We’ve got a lot of code to cover, so let’s get started!

Installation

Let’s start off this tutorial by setting up everything that we’ll need in order to build our authentication application. We’ll first need to download and install Laravel plus all of its dependencies. We’ll also utilize the popular Twitter Bootstrap to make our app look pretty. Then we’ll do a tad bit of configuration, connect to our database and create the required table and finally, start up our server to make sure everything is working as expected.

Download

Let’s use composer to create a new Laravel application. I’ll first change directories into my Sites folder as that’s where I prefer to store all of my apps:

cd Sites

Then run the following command to download and install Laravel (I named my app laravel-auth) and all of its dependencies:

composer create-project laravel/laravel laravel-auth

Add In Twitter Bootstrap

Now to keep our app from suffering a horrible and ugly fate of being styled by yours truly, we’ll include the Twitter bootstrap within our composer.json file:

{
    	"name": "laravel/laravel",
    	"description": "The Laravel Framework.",
    	"keywords": ["framework", "laravel"],
    	"require": {
    		"laravel/framework": "4.0.*",
    		"twitter/bootstrap": "*"
    	},
    
    	// The rest of your composer.json file below ....
    

… and then we can install it:

composer update
    

Now if you open up your app into your text editor, I’m using Sublime, and if you look in the vendor folder you’ll see we have the Twitter Bootstrap here.

Now by default our Twitter Bootstrap is composed of .less files and before we can compile them into .CSS files, we need to install all of the bootstrap dependencies. This will also allow us to use the Makefile that is included with the Twitter bootstrap for working with the framework (such as compiling files and running tests).

Note: You will need npm in order to install these dependencies.

In your terminal, let’s change directories into vendor/twitter/bootstrap and run npm install:

cd ~/Sites/laravel-auth/vendor/twitter/bootstrap
    npm install
    

With everything ready to go, we can now use the Makefile to compile the .less files into CSS. Let’s run the following command:

make bootstrap-css
    

You should now notice that we have two new folders inside our vendor/twitter/bootstrap directory named bootstrap/css which contain our bootstrap CSS files.

Now we can use the bootstrap CSS files later on, in our layout, to style our app.

But, we have a problem! We need these CSS files to be publicly accessible, currently they are located in our vendor folder. But this is an easy fix! We can use artisan to publish (move) them to our public/packages folder, that way we can link in the required CSS files into our main layout template, which we’ll create later on.

First, we’ll change back into the root of our Laravel application and then run artisan to move the files:

cd ~/Sites/laravel-auth
    php artisan asset:publish --path="vendor/twitter/bootstrap/bootstrap/css" bootstrap/css
    

The artisan command asset:publish allows us to provide a --path option for which files we want to move into our public/packages directory. In this case, we tell it to publish all of the CSS files that we compiled earlier and place them inside of two new folders named bootstrap/css. Your public directory should now look like the screenshot below, with our Twitter Bootstrap CSS files now publicly accessible:

Set Permissions

Next we need to ensure our web server has the appropriate permissions to write to our applications app/storage directory. From within your app, run the following command:

chmod -R 755 app/storage

Connect To Our Database

Next, we need a database that our authentication app can use to store our users in. So fire up whichever database you are more comfortable using, personally, I prefer MySQL along with PHPMyAdmin. I’ve created a new, empty database named: laravel-auth.

Now let’s connect this database to our application. Under app/config open up database.php. Enter in your appropriate database credentials, mine are as follows:

// Default Database Connection Name
    
    'default' => 'mysql',
    
    // Database Connections
    
    	'connections' => array(
    
    		'mysql' => array(
    			'driver'    => 'mysql',
    			'host'      => '127.0.0.1',
    			'database'  => 'laravel-auth',
    			'username'  => 'root',
    			'password'  => '',
    			'charset'   => 'utf8',
    			'collation' => 'utf8_unicode_ci',
    			'prefix'    => '',
    		),
    
    		// the rest of your database.php file's code ...
    

Create the Users Table

With our database created, it won’t be very useful unless we have a table to store our users in. Let’s use artisan to create a new migration file named: create-users-table:

php artisan migrate:make create-users-table

Let’s now edit our newly created migration file to create our userstable using the Schema Builder. We’ll start with the up() method:

public function up()
    {
    	$table->increments('id');
    	$table->string('firstname', 20);
    	$table->string('lastname', 20);
    	$table->string('email', 100)->unique();
    	$table->string('password', 64);
    	$table->timestamps();
    }
    

This will create a table named users and it will have an id field as the primary key, firstname and lastname fields, an email field which requires the email to be unique, and finally a field for the password (must be at least 64 characters in length) as well as a few timestamps.

Now we need to fill in the down() method in case we need to revert our migration, to drop the users table:

public function down()
    {
    	Schema::drop('users');
    }
    

And now we can run the migration to create our users table:

php artisan migrate

Start Server & Test It Out

Alright, our authentication application is coming along nicely. We’ve done quite a bit of preparation, let’s start up our server and preview our app in the browser:

php artisan serve

Great, the server starts up and we can see our home page:

Making the App Look Pretty

Before we go any further, it’s time to create a main layout file, which will use the Twitter Bootstrap to give our authentication application a little style!

Creating a Main Layout File

Under app/views/ create a new folder named layouts and inside it, create a new file named main.blade.php and let’s place in the following basic HTML structure:

<!DOCTYPE html>
    <html lang="en">
      <head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
    
        <title>Authentication App With Laravel 4</title>
      </head>
    
      <body>
    
      </body>
    </html>
    

Linking In the CSS Files

Next, we need to link in our bootstrap CSS file as well as our own main CSS file, in our head tag, right below our title:

	<head>
        	<meta charset="utf-8">
        	<meta name="viewport" content="width=device-width, initial-scale=1.0">
    
        	<title>Authentication App With Laravel 4</title>
        	{{ HTML::style('packages/bootstrap/css/bootstrap.min.css') }}
        	{{ HTML::style('css/main.css')}}
      	</head>
    

Now we just need to create this main.css file where we can add our own customized styling for our app. Under the public directory create a new folder named css and within it create a new file named main.css.

Finishing the Main Layout

Inside of our body tag, let’s create a small navigation menu with a few links for registering and logging in to our application:

<body>
    
      	<div class="navbar navbar-fixed-top">
    	  	<div class="navbar-inner">
    	    	<div class="container">
    				<ul class="nav">  
    					<li>{{ HTML::link('users/register', 'Register') }}</li>   
    					<li>{{ HTML::link('users/login', 'Login') }}</li>   
    				</ul>  
    	    	</div>
    	  	</div>
    	</div> 
    
    </body>
    

Notice the use of several Bootstrap classes in order to style the navbar appropriately. Here we’re just using a couple of DIVs to wrap an unordered list of navigation links, pretty simple.

For our application, we’re going to want to give our users simple flash messages, like a success message when the user registers. We’ll set this flash message from within our controller, but we’ll echo out the message’s value here in our layout. So let’s create another div with a class of .container and display any available flash messages right after our navbar:

<body>
    
      	<div class="navbar navbar-fixed-top">
    	  	<div class="navbar-inner">
    	    	<div class="container">
    				<ul class="nav">  
    					<li>{{ HTML::link('users/register', 'Register') }}</li>   
    					<li>{{ HTML::link('users/login', 'Login') }}</li>   
    				</ul>  
    	    	</div>
    	  	</div>
    	</div> 
                
    
        <div class="container">
        	@if(Session::has('message'))
    			<p class="alert">{{ Session::get('message') }}</p>
    		@endif
        </div>
    
    	</body>
    

To display the flash message, I’ve first used a Blade if statement to check if we have a flash message to display. Our flash message will be available in the Session under message. So we can use the Session::has() method to check for that message. If that evaluates to true, we create a paragraph with the Twitter bootstrap class of alert and we call the Session::get() method to display the message’s value.

Now lastly, at least for our layout file, let’s echo out a $content variable, right after our flash message. This will allow us to tell our controller to use this layout file, and our views will be displayed in place of this $content variable, right here in the layout:

<body>
    
      	<div class="navbar navbar-fixed-top">
    	  	<div class="navbar-inner">
    	    	<div class="container">
    				<ul class="nav">  
    					<li>{{ HTML::link('users/register', 'Register') }}</li>   
    					<li>{{ HTML::link('users/login', 'Login') }}</li>   
    				</ul>  
    	    	</div>
    	  	</div>
    	</div> 
                
    
        <div class="container">
        	@if(Session::has('message'))
    			<p class="alert">{{ Session::get('message') }}</p>
    		@endif
    
    		{{ $content }}
        </div>
    
    	</body>
    

Custom Styling

Now that we have our layout complete, we just need to add a few small custom CSS rules to our main.css file to customize our layout a little bit more. Go ahead and add in the following bit of CSS, it’s pretty self explanatory:

body {
    	padding-top: 40px;
    }
    
    .form-signup, .form-signin {
    	width: 400px;
    	margin: 0 auto;
    }
    

I added just a small amount of padding to the top of the body tag in order to prevent our navbar from overlapping our main content. Then I target the Bootstrap’s .form-signup and .form-signin classes, which we’ll be applying to our register and login forms in order to set their width and center them on the page.

Creating the Register Page

It’s now time to start building the first part of our authentication application and that is our Register page.

The Users Controller

We’ll start by creating a new UsersController within our app/controllers folder and in it, we define our UsersController class:

<?php
    
    class UsersController extends BaseController {
    
    }
    ?>
    

Next, let’s tell this controller to use our main.blade.php layout. At the top of our controller set the $layout property:

<?php
    
    class UsersController extends BaseController {
    	protected $layout = "layouts.main";
    }
    ?>
    

Now within our UsersController, we need an action for our register page. I named my action getRegister:

public function getRegister() {
    	$this->layout->content = View::make('users.register');
    }
    

Here we just set the content layout property (this is the $content variable we echo’d out in our layout file) to display a users.register view file.

The Users Controller Routes

With our controller created next we need to setup the routes for all of the actions we might create within our controller. Inside of our app/routes.php file let’s first remove the default / route and then add in the following code to create our UsersController routes:

Route::controller('users', 'UsersController');
    

Now anytime that we create a new action, it will be available using a URI in the following format: /users/actionName. For example, we have a getRegister action, we can access this using the following URI: /users/register.

Note that we don’t include the “get” part of the action name in the URI, “get” is just the HTTP verb that the action responds to.

Creating the Register View

Inside of app/views create a new folder named users. This will hold all of our UsersController‘s view files. Inside the users folder create a new file named register.blade.php and place the following code inside of it:

{{ Form::open(array('url'=>'users/create', 'class'=>'form-signup')) }}
    	<h2 class="form-signup-heading">Please Register</h2>
    
    	<ul>
    		@foreach($errors->all() as $error)
    			<li>{{ $error }}</li>
    		@endforeach
    	</ul>
    
    	{{ Form::text('firstname', null, array('class'=>'input-block-level', 'placeholder'=>'First Name')) }}
    	{{ Form::text('lastname', null, array('class'=>'input-block-level', 'placeholder'=>'Last Name')) }}
    	{{ Form::text('email', null, array('class'=>'input-block-level', 'placeholder'=>'Email Address')) }}
    	{{ Form::password('password', array('class'=>'input-block-level', 'placeholder'=>'Password')) }}
    	{{ Form::password('password_confirmation', array('class'=>'input-block-level', 'placeholder'=>'Confirm Password')) }}
    
    	{{ Form::submit('Register', array('class'=>'btn btn-large btn-primary btn-block'))}}
    {{ Form::close() }}
    

Here we use the Form class to create our register form. First we call the open() method, passing in an array of options. We tell the form to submit to a URI of users/create by setting the url key. This URI will be used to process the registration of the user. We’ll handle this next. After setting the url we then give the form a class of form-signup.

After opening the form, we just have an h2 heading with the .form-signup-heading class.

Next, we use a @foreach loop, looping over all of the form validation error messages and displaying each $error in the unordered list.

After the form validation error messages, we then we create several form input fields, each with a class of input-block-level and a placeholder value. We have inputs for the firstname, lastname, email, password, and password confirmation fields. The second argument to the text() method is set to null, since we’re using a placeholder, we don’t need to set the input fields value attribute, so I just set it to null in this case.

After the input fields, we then create our submit button and apply several different classes to it so the Twitter bootstrap handles the styling for us.

Lastly, we just close the form using the close() method.

Make sure to start up your server, switch to your favorite browser, and if we browse to http://localhost:8000/users/register you should see your register page:

Processing the Register Form Submission

Now if you tried filling out the register form’s fields and hitting the Register button you would have been greeted with a NotFoundHttpException, and this is because we have no route that matches the users/create URI, because we do not have an action to process the form submission. So that’s our next step!

Creating a postCreate Action

Inside of your UsersController let’s create another action named postCreate:

public function postCreate() {
    		
    }
    

Now this action needs to handle processing the form submission by validating the data and either displaying validation error messages or it should create the new user, hashing the user’s password, and saving the user into the database.

Form Validation

Let’s start with validating the form submission’s data. We first need to create our validation rules that we’ll validate the form data against. I prefer storing my validation rules in my model as that’s the convention I’m used to, from working with other frameworks. By default, Laravel ships with a User.php model already created for you.

Make sure you don’t delete this User model or remove any of the preexisting code, as it contains new code that is required for Laravel 4′s authentication to work correctly. Your User model must implement UserInterface and RemindableInterface as well as implement the getAuthIdentifier() and getAuthPassword() methods.

Under app/models open up that User.php file and at the top, add in the following code:

public static $rules = array(
    	'firstname'=>'required|alpha|min:2',
    	'lastname'=>'required|alpha|min:2',
    	'email'=>'required|email|unique:users',
    	'password'=>'required|alpha_num|between:6,12|confirmed',
    	'password_confirmation'=>'required|alpha_num|between:6,12'
    	);
    

Here I’m validating the firstname and lastname fields to ensure they are present, only contain alpha characters, and that they are at least two characters in length. Next, I validate the email field to ensure that it’s present, that it is a valid email address, and that it is unique to the users table, as we don’t want to have duplicate email addresses for our users. Lastly, I validate the password and password_confirmation fields. I ensure they are both present, contain only alpha-numeric characters and that they are between six and twelve characters in length. Additionally, notice the confirmed validation rule, this makes sure that the password field is exactly the same as the matching password_confirmation field, to ensure users have entered in the correct password.

Now that we have our validation rules, we can use these in our UsersController to validate the form submission. In your UsersController‘s postCreate action, let’s start by checking if the data passes validation, add in the following code:

public function postCreate() {
    	$validator = Validator::make(Input::all(), User::$rules);
    
    	if ($validator->passes()) {
    		// validation has passed, save user in DB
    	} else {
    		// validation has failed, display error messages	
    	}
    }
    }
    

We start by creating a validator object named $validator by calling the User::validate() method. This accepts the two arguments, the submitted form input that should be validated and the validation rules that the data should be validated against. We can grab the submitted form data by calling the Input::all() method and we pass that in as the first argument. We can get our validation rules that we created in our User model by accessing the static User::$rules property and passing that in as the second argument.

Once we’ve created our validator object, we call its passes() method. This will return either true or false and we use this within an if statement to check whether our data has passed validation.

Within our if statement, if the validation has passed, add in the following code:

if ($validator->passes()) {
    	$user = new User;
    	$user->firstname = Input::get('firstname');
    	$user->lastname = Input::get('lastname');
    	$user->email = Input::get('email');
    	$user->password = Hash::make(Input::get('password'));
    	$user->save();
    
    	return Redirect::to('users/login')->with('message', 'Thanks for registering!');
    } else {
    	// validation has failed, display error messages	
    }
    

As long as the data that the user submits has passed validation, we create a new instance of our User model: new User; storing it into a $user variable. We can then use the $user object and set each of the user’s properties using the submitted form data. We can grab the submitted data individually using the Input::get('fieldName') method. Where fieldName is the field’s value you want to retrieve. Here we’ve grabbed the firstname, lastname, and email fields to use for our new user. We also grabbed the password field’s value, but we don’t just want to store the password in the database as plain text, so we use the Hash::make() method to hash the submitted password for us before saving it. Lastly, we save the user into the database by calling the $user object’s save() method.

After creating the new user, we then redirect the user to the login page (we’ll create the login page in a few moments) using the Redirect::to() method. This just takes in the URI of where you’d like to redirect to. We also chain on the with() method call in order to give the user a flash message letting them know that their registration was successful.

Now if the validation does not pass, we need to redisplay the register page, along with some validation error messages, with the old input, so the user can correct their mistakes. Within your else statement, add in the following code:

if ($validator->passes()) {
    	$user = new User;
    	$user->firstname = Input::get('firstname');
    	$user->lastname = Input::get('lastname');
    	$user->email = Input::get('email');
    	$user->password = Hash::make(Input::get('password'));
    	$user->save();
    
    	return Redirect::to('users/login')->with('message', 'Thanks for registering!');
    } else {
    	return Redirect::to('users/register')->with('message', 'The following errors occurred')->withErrors($validator)->withInput();
    }
    

Here we just redirect the user back to the register page with a flash message letting them know some errors have occurred. We make sure to display the validation error messages by calling the withErrors($validator) method and passing in our $validator object to it. Finally, we call the withInput() method so the form remembers what the user originally typed in and that will make it nice and easy for the user to correct the errors.

Adding In the CSRF Before Filter

Now we need to make sure to protect our POST actions from CSRF attacks by setting the CSRF before filter within our UsersController‘s constructor method. At the top of your UsersController add in the following code:

public function __construct() {
    	$this->beforeFilter('csrf', array('on'=>'post'));
    }
    

Within our constructor, we call the beforeFilter() method and pass in the string csrf, as the first argument. csrf is the filter that we want to apply to our actions. Then we pass in an array as the second argument and tell it to only apply this filter on POST requests. By doing this, our forms will pass along a CSRF token whenever they are submitted. This CSRF before filter will ensure that all POST requests to our app contain this token, giving us confidence that POST requests are not being issued to our application from other external sources.

Creating the Login Page

Before you run off and try out your register page, we first need to create the Login page so that when our register form submission is successful, we don’t get an error. Remember, if the form validation passes, we save the user and redirect them to the login page. We currently don’t have this login page though, so let’s create it!

Still inside of your UsersController, create a new action named getLogin and place in the following code:

public function getLogin() {
    	$this->layout->content = View::make('users.login');
    }
    

This will display a users.login view file. We now need to create that view file. Under app/views/users create a new file named login.blade.php and add in the following code:

{{ Form::open(array('url'=>'users/signin', 'class'=>'form-signin')) }}
    	<h2 class="form-signin-heading">Please Login</h2>
    
    	{{ Form::text('email', null, array('class'=>'input-block-level', 'placeholder'=>'Email Address')) }}
    	{{ Form::password('password', array('class'=>'input-block-level', 'placeholder'=>'Password')) }}
    
    	{{ Form::submit('Login', array('class'=>'btn btn-large btn-primary btn-block'))}}
    {{ Form::close() }}
    

This code is very similar to the code we used in our register view, so I’ll simplify the explanation this time to only what is different. For this form, we have it submit to a users/signin URI and we changed the form’s class to .form-signin. The h2 has been changed to say “Please Login” and its class was also changed to .form-signin-heading. Next, we have two form fields so the user can enter in their email and password, and then finally our submit button which just says “Login”.

Let’s Register a New User!

We’re finally at a point to where we can try out our registration form. Of course, the login functionality doesn’t work just yet, but we’ll get to that soon enough. We only needed the login page to exist so that our register page would work properly. Make sure your server is still running, switch into your browser, and visit http://localhost:8000/users/register. Try entering in some invalid user data to test out the form validation error messages. Here’s what my page looks like with an invalid user:

Now try registering with valid user data. This time we get redirected to our login page along with our success message, excellent!

Logging In

So we’ve successfully registered a new user and we have a login page, but we still can’t login. We now need to create the postSignin action for our users/signin URI, that our login form submits to. Let’s go back into our UsersController and create a new action named postSignin:

public function postSignin() {
    			
    }
    

Now let’s log the user in, using the submitted data from the login form. Add the following code into your postSignin() action:

if (Auth::attempt(array('email'=>Input::get('email'), 'password'=>Input::get('password')))) {
    	return Redirect::to('users/dashboard')->with('message', 'You are now logged in!');
    } else {
    	return Redirect::to('users/login')
    		->with('message', 'Your username/password combination was incorrect')
    		->withInput();
    }
    

Here we attempt to log the user in, using the Auth::attempt() method. We simply pass in an array containing the user’s email and password that they submitted from the login form. This method will return either true or false if the user’s credentials validate. So we can use this attempt() method within an if statement. If the user was logged in, we just redirect them to a dashboard view page and give them a success message. Otherwise, the user’s credentials did not validate and in that case we redirect them back to the login page, with an error message, and display the old input so the user can try again.

Creating the Dashboard

Now before you attempt to login with your newly registered user, we need to create that dashboard page and protect it from unauthorized, non logged in users. The dashboard page should only be accessible to those users who have registered and logged in to our application. Otherwise, if a non authorized user attempts to visit the dashboard we’ll redirect them and request that they log in first.

While still inside of your UsersController let’s create a new action named getDashboard:

public function getDashboard() {
    	
    }
    

And inside of this action we’ll just display a users.dashboard view file:

public function getDashboard() {
    	$this->layout->content = View::make('users.dashboard');
    }
    

Next, we need to protect it from unauthorized users by using the auth before filter. In our UsersController‘s constructor, add in the following code:

public function __construct() {
    	$this->beforeFilter('csrf', array('on'=>'post'));
    	$this->beforeFilter('auth', array('only'=>array('getDashboard')));
    }
    

This will use the auth filter, which checks if the current user is logged in. If the user is not logged in, they get redirected to the login page, essentially denying the user access. Notice that I’m also passing in an array as a second argument, by setting the only key, I can tell this before filter to only apply it to the provided actions. In this case, I’m saying to protect only the getDashboard action.

Customizing Filters

By default the auth filter will redirect users to a /login URI, this does not work for our application though. We need to modify this filter so that it redirects to a users/login URI instead, otherwise get an error. Open up app/filters.php and in the Authentication Filters section, change the auth filter to redirect to users/login, like this:

/*
    |--------------------------------------------------------------------------
    | Authentication Filters
    |--------------------------------------------------------------------------
    |
    | The following filters are used to verify that the user of the current
    | session is logged into this application. The "basic" filter easily
    | integrates HTTP Basic authentication for quick, simple checking.
    |
    */
    
    Route::filter('auth', function()
    {
    	if (Auth::guest()) return Redirect::guest('users/login');
    });
    

Creating the Dashboard View

Before we can log users into our application we need to create that dashboard view file. Under app/views/users create a new file named dashboard.blade.php and insert the following snippet of code:

<h1>Dashboard</h1>
    
    <p>Welcome to your Dashboard. You rock!</p>
    

Here I’m displaying a very simple paragraph to let the user know they are now in their Dashboard.

Let’s Login!

We should now be able to login. Browse to http://localhost:8000/users/login, enter in your user’s credentials, and give it a try.

Success!

Displaying the Appropriate Navigation Links

Ok, we can now register and login to our application, very cool! But we have a little quirk here, if you look at our navigation menu, even though we’re logged in, you can see that the register and login buttons are still viewable. Ideally, we want these to only display when the user is not logged in. Once the user does login though, we want to display a logout link. To make this change, let’s open up our main.blade.php file again. Here’s what our navbar code looks like at the moment:

<div class="navbar navbar-fixed-top">
      	<div class="navbar-inner">
        	<div class="container">
    			<ul class="nav">  
    				<li>{{ HTML::link('users/register', 'Register') }}</li>   
    				<li>{{ HTML::link('users/login', 'Login') }}</li>   
    			</ul>  
        	</div>
      	</div>
    </div> 
    

Let’s modify this slightly, replacing our original navbar code, with the following:

<div class="navbar navbar-fixed-top">
      	<div class="navbar-inner">
        	<div class="container">
    			<ul class="nav">  
    				@if(!Auth::check())
    					<li>{{ HTML::link('users/register', 'Register') }}</li>   
    					<li>{{ HTML::link('users/login', 'Login') }}</li>   
    				@else
    					<li>{{ HTML::link('users/logout', 'logout') }}</li>
    				@endif
    			</ul>  
        	</div>
      	</div>
    </div> 
    

All I’ve done is wrapped our li tags for our navbar in an if statement to check if the user is not logged in, using the !Auth::check() method. This method returns true if the user is logged in, otherwise, false. So if the user is not logged in, we display the register and login links, otherwise, the user is logged in and we display a logout link, instead.

Logging Out

Now that our navbar displays the appropriate links, based on the user’s logged in status, let’s wrap up this application by creating the getLogout action, to actually log the user out. Within your UsersController create a new action named getLogout:

public function getLogout() {
    	
    }
    

Now add in the following snippet of code to log the user out:

public function getLogout() {
    	Auth::logout();
    	return Redirect::to('users/login')->with('message', 'Your are now logged out!');
    }
    

Here we call the Auth::logout() method, which handles logging the user out for us. Afterwards, we redirect the user back to the login page and give them a flash message letting them know that they have been logged out.

Conclusion

And that concludes this Laravel 4 Authentication tutorial. I hope you’ve found this helpful in setting up auth for your Laravel apps. If you have any problems or questions, feel free to ask in the comments and I’ll try my best to help you out. You can checkout the complete source code for the small demo app that we built throughout this tutorial on Github. Thanks for reading.

A new phishing scam is threatening to deactivate email accounts. This email is not from UMBC. Do not click this link.

Here's what's being received:

"This E-mail is sent by the HelpDesk Expert for IT Support system for Mailbox notification and update purposes. We are conducting an email sweep upgrade due to our new login home page that is coming up soon for your better and faster server. So we are removing all unused email and registration of all active Student/Staff mail account to enable the University create new logins for our 2013/2014 students and staff. So all users are to verify there accounts.

CLICK HERE: To go to verification page and follow the instructions on the popup page

IMPORTANT NOTICE: ACCOUNT OWNER THAT REFUSES TO VERIFY/UPGRADE HIS/HER ACCOUNT WILL LEADS TO YOUR ACCOUNT DE-ACTIVATION WITHIN 48 HOURS PRIOR TO THE URGENT THAT CONTAINED IN THIS SHEET.

Copyright@2013 Help-desk Technical Support Centre."

Again: Do Not Click The Link. If you already did, please change your password immediately.

Dean John Jeffries retired at the end of June after forty years of service to UMBC. In recognition of his profound impact on UMBC, we are delighted to announce the establishment of the John Jeffries International Fellowship.

The Fellowship fund honors John’s commitment to building a strong and distinctive undergraduate curriculum and to educating students to become informed and engaged global citizens.  The Fellowship will provide faculty with resources to create, or redesign, and teach a course in their fields in order to add or enhance an explicit international or transnational focus. Our expectation is that the resulting courses will be taught regularly and will broaden the intellectual scope of the curriculum in the College of Arts, Humanities, and Social Sciences.

In a matter of weeks, current and former Department Chairs, Program Directors, and Associate Deans in the College of Arts, Humanities, and Social Sciences have contributed more than $25,000 to endow the John Jeffries Fellowship. Since then, others have contributed towards the goal of $200,000, which will enable the campus to support two Jeffries Fellows each year.

If you are interested in making a gift to the John Jeffries International Fellowship Program or have any questions, please contact Marjoleine Kars, Jason Loviglio, or Carole McCann.

I can remember a time when pretty much everyone designed websites for an 800×600 screen resolution, but (thankfully) those days are long gone. Smart watches and 4k displays are pushing resolutions at both ends of the spectrum, and even more devices fill the gaps between, such as desktops, tablets, phones, and gaming consoles. In parallel, the density of pixels is increasing, too.

Designing for a single screen resolution is dead. Photo courtesy Flickr user endlisnis.

How can a web designer create sites that work on the devices of today and tomorrow? In this post, I propose a workflow called Scalable Web Design that attempts to address pixel density in a sustainable fashion.

We’ve Been Here Before

Fortunately, Responsive Web Design (RWD) came at just the right time and has since become the de facto solution for building modern websites. If you’re not familiar with it yet, the Beginner’s Guide to Responsive Web Design will help you get caught up. The genius of RWD is that it works on current devices as well as devices that haven’t been dreamt up yet. No matter what kind of shiny new glowing rectangles are released in the next few years, chances are pretty good that a responsive website will require little to no changes.

RWD solves the problem of device sizes, but some devices have a 1x pixel ratio, some are at 2x, still others are at 1.5x, and who knows what else. Check out this handy table at screensiz.es to see what I mean.

Screensiz.es provides tables of information about popular hardware devices.

Once again, web designers are faced with a new rabbit hole of questions with fuzzy answers. Do you create 1x and 2x versions of all your images? Do you only use 2x for everything? What if 3x becomes popular?

Scalable Web Design

The problem of pixel densities is similar in spirit to the problem of screen sizes that RWD solves, so I’ve come up with a workflow that I’ve been calling “Scalable Web Design.” I’m sure some people will hate this term because scalable already can refer to building sites that are capable of handling lots of traffic, but you could say similar things about the term responsive. As long as it’s used in the context of design, I think it adequately encapsulates the idea of creating designs that scale with pixel density. If you agree or disagree, I’d love to hear your thoughts in the comments.

So then, what are the steps for building a scalable design? Let’s break it down.

Step 1: Vector First

Rather than scramble to accommodate every new pixel density, it’s better to retool our thinking from the start. As mobile devices surge beyond the popularity of desktops, this shift in thinking has already started with the “mobile first” approach (and rightly so). Now, I think it’s time we start thinking “vector first” as well. Check out this 19kb SVG example on CodePen and notice how crisp it looks, even when it fills the page.

See the Pen AFjaw by Nick Pettit (@nickpettit) on CodePen

If you’re addicted to using Photoshop for everything, it’s time to start learning a vector based drawing program like Illustrator. Vector graphics like SVGs and icon fonts have considerable benefits over bitmap formats:

• Vectors can scale to virtually any pixel density. Only at very small sizes (like favicons) should you create a more customized graphic.
• Vectors typically have smaller file sizes than their bitmapped counterparts, especially when the comparison is between imagery with large dimensions.
• Vectors will never have any compression artifacts. They’ll always look sharp.
• Vectors are more future proof than bitmaps. If 2.5x or 3x or 4x screens catch on, your assets will be ready to go.

Designing with vectors in mind from the start should prompt healthy thinking about aesthetic and technological choices. For example, if you only need to use 1 or 2 photographs and it’s going to mean including more code to serve multiple source images, it might make you reconsider whether or not that photograph is really necessary. I wouldn’t expect every web designer to create sites with 100% vector imagery, but it’s certainly worth using vectors where possible. The good news is, vectors work beautifully with the recent “flat design” aesthetic, as most vectors trend towards solid colors, sharp lines, and simple shapes.

When it comes to vectors, you basically have the option of using icon fonts or SVGs. Icon fonts are great because there are lots of premade options and they boast smaller filesizes than SVGs. However, as Filament Group smartly pointed out, browser support for icon fonts isn’t that great. SVGs on the other hand are pretty well supported and they allow for full color graphics and gradients (font icons are monochromatic). Filament Group even created an awesome bitmap based fallback solution called Grumpicon. The workflow is simple:

1. Export your SVGs from your vector package of choice. The default settings in Illustrator are fine.
2. Drag and drop all your SVGs into Grumpicon.
3. When you’re done, you get example code showing you how to use your SVGs as background images along with the fallback images. Awesome!

For more detailed information about SVG browser support, here’s the handy caniuse.com SVG support table.

Step 2: CSS Next

After you’ve created a vector layout, you should next look for areas where SVGs can be replaced with simple CSS. Designing with vectors has a tendency to lead towards flat color and simple shapes. Using CSS pseudo elements, it’s possible to create lots of shapes without adding any markup. To see lots of examples of shapes created with a single HTML element, check out The Shapes of CSS on CSS-Tricks.

If you’ve never investigated CSS shapes before, you might be surprised by what’s possible.

Replacing SVGs with CSS will help reduce the number of assets you need to load, which makes for more performant pages. This step will pick up even more steam in the next few years when the CSS shapes module gains broad browser support.

Step 3: Bitmaps for Photographs

Vectors don’t work for extremely detailed images like photographs or screenshots, so you will still need to use bitmapped graphics there (the picture element is looking like a promising solution in this case). However, limitations can be a great source of creativity.

For example, Treehouse teacher Mat Helme created a website for a fictional conference called Stop Visual Pollution and the site uses SVGs for all the images. It’s not perfectly responsive (as it’s only intended for demonstration purposes), but it’s a wonderful example of what vector based thinking can lead towards. He could have used photos for the speakers, but the illustrations are much more captivating. This graphically rich site is just 386kb total and it looks incredibly sharp on my 15″ retina display. To do this without vectors, you would need to use massive PNG images, which isn’t practical.

This screenshot of the fictional Stop Visual Pollution website shows how Mat used illustrations for each speaker instead of a photograph.

If you do need to use bitmaps, start out with the largest source material available. It might not ever get used in production, but it’s good to keep it handy in case you need it someday.

As a general rule of thumb, it’s usually safe to provide a single 2x bitmap and call it a day. Modern browsers do a great job of scaling these down to 1x if necessary and the difference in filesize between 1x and 2x images is usually pretty small. That’s because you can apply a much greater amount of image compression to 2x images and they’ll still look good, because the compression artifacts have a tendency to wash out when the images are rescaled.

For responsive designs, you may need to use multiple image sources that get served up based on the size of the screen. The picture element which I mentioned earlier looks like a promising for the future, but presently, there are numerous solutions that do this. Here are a few to get you started:

• Responsive Images
• ZURB Interchange
• Adaptive Images

Many image source swapping solutions will also allow you to include imagery intended for higher pixel densities. If you do find that a higher number of your website visitors are using 3x devices and beyond, you’ll probably want to consider serving up 3x assets specifically for them (and not to other visitors as to not waste bandwidth). If you need help doing your density calculations, check out the Teehan+Lax Density Converter.

Tomorrow is Today

I think the advent of vectors came a bit faster than web professionals expected. For years SVGs were a dream from tomorrow, but Internet Explorer was the last holdout, and that threshold was crossed several versions ago now.

Indeed, uncertainty is a part of web design, so we should embrace it. It’s impossible to predict every twist that technology will take next and create future proof designs, but vectors are a pretty good preventative measure.

The post Scalable Web Design appeared first on Treehouse Blog.

When: Friday, Nov. 22, 6:30 PM to 8:30 PM
Where: Google Campus, London

View Larger Map

Untangle the Web is back at the Google Campus in London this month with three fantastic talks and a new bigger ground floor space!

If you’re new to our Meetups, we host monthly events where we invite industry professionals from the world of the web to share their experiences and offer guidance to those new to the arena. With a philosophy of simplicity and conciseness, all talks are refreshingly “data-light” and cover a wide variety of topics.

This month focuses on how to engage users and cultivate relationships with client. James Offer will be talking about content strategy, and Ruth Smith and Treehouse student Graham Davidson will be discussing working with clients.

As always there will be pizza, beer and soft drinks available at the end of the evening for everyone, so feel free to stick around and hang out after the talks. We’ll also have another Treehouse giveaway, so be sure to come and enter for a chance to win some fun Treehouse swag!

RSVP to reserve your spot today and please help us spread the word as we’ll have an even bigger space than usual, so the more the merrier.

We look forward to seeing you on the 22nd!

The post Join Us for the November Untangle the Web + Treehouse Meetup in London appeared first on Treehouse Blog.