Check out a free preview of the full Progressive Web Applications and Offline course:
The "Intercepting Network Requests" Lesson is part of the full, Progressive Web Applications and Offline course featured in this preview video. Here's what you'd learn in this lesson:

Steve discusses Service Worker's ability for an application to intercept any network requests and respond back with custom responses. Steve also takes questions from students.

Get Unlimited Access Now

Transcript from the "Intercepting Network Requests" Lesson

[00:00:00]
>> Steve Kinney: So the main thing we talked about is that what makes a service worker really cool is that it can intercept network requests, right? That is what gives us the ability to say, hey, actually we would like to get something from the network. We would like to get something from cache.

[00:00:13] We would like as Mike just said have a fallback image. This is where the service worker really shines. What we did yesterday was we had a service worker that log stuff and that was neat, but kind of misses the point of a service worker. And we saw that service workers can add a event listener for a fetch and this would because XHR uses fetch under the hood, loading images and image check uses fetch under the hood.

[00:00:46] This will be pretty much all network request that our application makes. And so we can just intercept anything that its asking for. And again, reframing it in the fact that we are trying build on applications that work on either on unreliable or no network connection. We can see how this concept of any network request for any kind of resource going to the service worker can be incredibly powerful.

[00:01:09] The event that the fetch listener received has a lot of properties. Let's just talk about a few of them. Event.request is that request object that you passed into the fetch or that the browser passed it, right? We saw two examples yesterday. We saw an example where that was a string and maybe an object options.

[00:01:31] We saw an example we could literally construct a new request with a string and an object of options, right? That request is why we have this event.request and that request has the properties that we might expect. It has the URL like what URL you're requesting, what method, right?

[00:01:48] You would access to the header and so on and so forth. The other really powerful one on the event object is this method called respondWith. So we receive an event that has the request on it and we have this method called respondWith which means that we could theoretically respond with something otherwise, right?

[00:02:08] We could create our own response object be like, I know what you requested, here take this response. So what that could look like? So we will listen for fetch events. If the request URL is where we are currently like for this current page respond with a brand new response, but we'll set the body of hello in paragraph tags and we'll set it as an HTML document and I know that you requested this page.

[00:02:39] I'm not even going to go to the network. I'm going to just hand this back to you, right? If we don't use event.respondWith, it passes through to the network. So yesterday, we had a self.addEventListener on fetch and we put in a console log that didn't break our network connections, right?

[00:03:00] It went through the network. We just logged something on the way. In this case, we are literally intercepting it. Crafting our own response and sending it back to the browser.
>> Speaker 2: One question, since in this example we are sending HTML, can we assume that service workers are more secure over the DOM that somebody else may not have access?

[00:03:29]
>> Steve Kinney: I mean, if it's user data, you can't assume anything, right,? That is your code.
>> Speaker 2: Sure, but for cross site scripting or all that kind of attacks or changing some of.
>> Steve Kinney: I don't think you can assume that it's more. When you're dealing with arbitrary data, you can't assume that it's safe.

[00:03:50] I would definitely sterilize in this case.
>> Speaker 2: I mean, can a user or a third party hack that service worker's code and inject bad HTM?
>> Steve Kinney: So I can feel the Sun.
>> Speaker 2: Yeah.
>> Steve Kinney: You need to use the same precautions here anywhere that you would use, you'd be rendering user data in HTML and the typical convention is never trust anything a user is capable of editing.

[00:04:24] Always sanitize it, always sanitize it. Most modern view layers like React which we are using here, they offer some protection for you in that they don't let you render. You could not change the name of a grocery item to a script tag and trigger like the download, and execution of that script.

[00:04:44] In this case, there is no protection for you. Because we are not using a library, like you are going to get this HTML here. So just be really careful when allowing user values to be put into HTML, because that you have to treat it like code, because it can contain code.

[00:05:03]
>> Speaker 3: Yep, it's not trusting user input. It's not unique to the DOM, right? In the same way, you wouldn't trust it in a SQL query, right? It is effectively not trusting users is this global truth of programming whether in Vasterdam, whether in Vaxico. Anytime you're evaluating user data, you'll never trust users.

[00:05:28] All right and the same is true in the server's worker as it would be on the DOM, as it would be on the server in all those cases.