So actually, we already discussed custom domain name binding in the previous demonstration. So let's just look at hot linking this time. We've already bound our domain name, chinasite.xyz, to our bucket. Let's look at how we protect against hot linking. So how do we keep people from linking to our bucket's content from their own web pages? Well, if you go under Access Control, there's this option here, Hotlink Protection, and what you can do is set an HTTP refer white list, so that unauthorized sites cannot directly link to the content of your bucket. This is especially useful, if you're using OSS to host a static site. You'll also notice that for JavaScript, we also have a Cross-Origin Resource Sharing records configuration that you can set up to resolve some common issues with JavaScript code and static sites. We won't go into that.

Let's just focus on the hot linking for now. So I'll click on Configure here, and you see, I can configure a white list. So for instance, I can say chinasite.xyz is now on the white list. And I'm going to check this box here to also allow empty refers, because when I visit the route for my static site, the refer field is going to be empty by default. So I'll click Save. And now if I were to visit my site, chinasite.xyz directly, everything works fine. My site is allowed to link to these images and there's no issue. In fact, if I were to open up the developer pane, reload the site, you can see that these two images here have their refer set to chinasite.xyz, which is in our refer white list, and therefore these images load up just fine. Of course, if I were to link to these images from another site somewhere else, by directly referencing the image URL, it would fail, it would be denied because I've now configured this white list. And only this site is allowed to link back to those images. And that's how you set up Hotlink Protection on OSS.