You might have felt the want to start including the same code in

each of your route methods here.

Now like we talked about,

we really want to know the username before the idea's page is able to be accessed.

So a common way to do this is by applying what is known as HTTP middleware.

What this allows you to do is this.

A request comes in, and the framework first looks for

any handler that should run before the request is processed.

This handler has access to request and response, and

it can add or change things, including stopping the request altogether.

[SOUND] If things are to continue,

the request is handled using the proper methods.

Finally, any matching after-methods are run.

Now this pattern is pretty powerful for

things like authentication, like logging into a site with a username or a password.

If you wanna make sure that proper access is granted for

a specific section, you simply need to make a before-handler that checks that

the request is coming from someone that is logged in, or authenticated.

Otherwise, you handle things.

In Spark, this HTTP middleware concept is handled with something called filters.

There's one for before and another for after.

Why don't we make sure that visiting the ideas page requires a known user name, and

if not, let's redirect them.

Okay, so let's add a filter for before the /ideas page renders.

In Spark, that is just using the Spark static method called before.

So we'll put that up there.

So we'll say before, and it was right.

We want a static import that method, Spark.before.

And the first optional parameter here, is the URI that you wanna catch.

So this also takes wild card matching, but

we wanna catch specifically this ideas page, right?

And then it takes a filter object and

it's very similar to the single abstract method that our routes are using.

So it takes a request and a response.

And we can, of course, represent that as a lambda.

What we wanna do is we wanna check and see if the username is in the cookies, so

if it's not, null.

So let's go ahead and we'll say if

(req.cookie("username") != null)

then what we want to do is we wanna redirect, right?

We wanna redirect to the home page.

So we'll say res.redirect.

And now, since we've already dealt with this response,

we don't need to do any other processing.

So, let's stop the request from hitting one of the other routes.

So, we can do this by calling the static halt method, and nothing more will happen.

So, we just say halt.

When that redirect happens, that's gonna be a little jarring.

So, I think we should probably tell them a message, right?

Let's add a to do about that.

Let's add a to do.

We'll say, // TODO.

Send message about, whoops.

Send message about redirect...somehow.

We don't have any messaging in place, do we?

We should fix that.

I don't know what's going on with the indentation.

Let's fix that, there we go.

Okay, so let's double check that that's working, right?

So we will restart the server, flip over to our page.

There are no cookies.

So if I go to the /ideas, this before filter should catch it and redirect us.

It did it, let's take a look at why.

I said not equal to null.

If it is equal to null, okay.

So if it doesn't exist, we wanna flip them over there.

Common mistake, I'm gonna keep that in there, enjoy.

All right, no cookies, let's go to the ideas, I restarted the server.

See now it flipped to Welcome Students instead of, what's your idea.

So it's working, but we really should show a message, right?

We should say like, you need to log in before you can see the ideas page,

something like that.

Okay, so we already added a to do about that.

Let's see what other to do's are out there, ooh!

TODO, this username is tied to the cookie implementation.

Maybe we can take care of that.

I mean, that's one of the powers of middleware, right?

We can abstract away parts of this flow.

So let's do that, let's go take look at where that's at.

One thing that we can do, is we can manipulate the request object and

we can add data to it, so that other filters and routes can access it.

So, let's remove this dependence on our cookie implementation and

we'll keep it in our middleware.

We'll keep it secret in our middleware, just using filters.

So, let's do that.

We'll come up here.

Now, the way that before filters work is it's the way that they're added.

So, we want it before this one.

Before this before, that's a lot of beforing.

All right, if we don't put a path, what that means is this is gonna happen for

every single request response.

Every single request.

So, here we'll check and see if the cookie exists.

Now we'll use my inverted logic that I did before.

If it exists, what we're going to do is we're going to add

an attribute to the request, so the rest of the request can use it.

So those, on Spark, are called attributes.

So we're gonna say, req.attribute, and we're gonna set username.

And we're gonna pull that right off of the cookie.

Now it's okay that it knows about it here, right?

Because we could write any one of these filters for later, okay?

So that should do it.

And now any place after this request where we're doing this,

if we wanna find any time that we talk about cookie.

Right, every time I talk about a request cookie,

let's replace that now with request attribute.

So, req.attribute,

that was a Cmd+R opened this up.

So let's go ahead and let's do Replace.

And it's gonna flip through each one.

We wanna replace that one, and we wanna replace that one.

So now, any time we talk about request cookie,

it's only up in the top area.

Every other time, it's looking for request.attribute.

So, there we go.

The cookie implementation, at least on the read side, has been removed.

Now as long as we set the attribute username, anything can do this, right?

Any kind of middleware, we could do facial recognition or voice recognition,

anything.

As long as it sets the username attribute, the username will be used in present.

Pretty cool, right?

So we definitely can remove this to do.

And I guess, before we get too brave,

we should make sure that our changes are working, right?

Cuz we don't have tests.

So I'm gonna restart this.

And I'm gonna try to go, there are no cookies,

I'm gonna try to go to the ideas page.

And I can't, but if I do put in my ID, a cookie comes across,

but it's using the request attribute.

So I want, really want a course on Spark testing.

Things are looking good.

HTTP middleware is definitely powerful and

allows you to abstract away the implementation of fairly difficult things.

I'm glad you got some hands on experience with it.

When you feel yourself duplicating code and

routes, consider leaning on them as a solution.

I really enjoy Spark's simple approach to the problem space of being

able to modify requests and responses.

You'll find similar solutions in other frameworks.

But this is so nice and succinct, and

really, in my opinion, what makes these micro frameworks like Spark shine.

Okay, now we can gather awesome ideas from students,

let's allow you all to vote on them.