Introduction

In the previous articles, we learned that the CORS protocol is essentially a security protocol. In addition to CORS, there are actually a series of things related to cross-origin, such as:

1. CORB (Cross-Origin Read Blocking)
2. CORP (Cross-Origin Resource Policy)
3. COEP (Cross-Origin-Embedder-Policy)
4. COOP (Cross-Origin-Opener-Policy)

Doesn’t just seeing this series of similar terms make you dizzy? Yes, me too. In the process of organizing this information, I found that the security issues related to cross-origin are more complicated than I thought, but after spending some time organizing them, I found that there is still a logical sequence to follow. Therefore, this article will explain why these things appear in a context that I think should be easier to understand.

In addition to the various COXX things mentioned above, there are other cross-origin related security issues that I want to mention in this article.

Before we continue, I would like to remind everyone that this article is about “security issues of cross-origin”, not just “security issues of CORS”. The things protected by the CORS protocol and their content have been introduced before. What this article is going to talk about is actually somewhat deviating from the main title “CORS” complete guide, because this is not very related to the CORS protocol, but rather raises the level again and talks about “cross-origin” itself.

So when you read the following things, don’t confuse them with CORS. Except for the first thing to be discussed later, the others are not very related to CORS.

Read More

Introduction

After acquiring knowledge, how can you determine whether it is correct or not? In the field of programming, this is actually a relatively simple question. You just need to check how the specification is written (if there is one).

For example, various language features of JavaScript can be found in the ECMAScript Specification. Why [] === [] is false, why 'b' + 'a' + + 'a' + 'a' is baNaNa, all of these are explained in detail in the specification, using what rules to perform the conversion.

In addition to JS, almost all HTML or other related specifications in the Web field can be found on w3.org or whatwg.org, and the resources are quite rich.

Although the implementation of browsers may be different from what is written in the specification (such as this article), the spec is the most complete and authoritative place, so it is correct to come here to find information.

If you search for the CORS spec, you may find RFC6454 - The Web Origin Concept and W3C’s Cross-Origin Resource Sharing, but these two have been replaced by a document called Fetch.

At first, I was puzzled and thought I had read it wrong. What is the relationship between fetch and CORS? Later, I learned that the fetch here is different from the fetch in the Web API. This specification defines everything related to “fetching data”, as written in its outline:

The Fetch standard defines requests, responses, and the process that binds them: fetching.

In this article, let’s take a look at the CORS-related specifications together, proving that what I said in the previous articles is not nonsense, but based on facts. Since the specification is quite long, I will only pick some key points that I think are important. If you want to understand all the content of the specification, you still need to read it yourself.

Read More

Introduction

In the previous article, we mentioned the common solutions to CORS errors and the solution that should be chosen in most cases: “Ask the backend to add response headers.”

However, “cross-origin requests” can actually be further divided into two types: simple requests and non-simple requests. Simple requests can be solved using the solution in the previous article, but non-simple requests are more complicated.

In addition, cross-origin requests do not send cookies by default, and an additional setting is required when using xhr or fetch, and the backend also needs to add an additional header.

There are actually many headers related to CORS, some of which you may not have heard of. Originally, I wanted to list these things one by one and explain them, but after careful consideration, I felt that this would be a bit boring, and everyone would probably forget after reading it.

So what would be a better way? Everyone likes to hear stories, so in this article, let’s start from the perspective of a story and tell you a story about love and CORS.

The protagonist’s name is well known, yes, it’s the unoriginal Xiaoming.

Read More

Introduction

In the previous article CORS Complete Guide (Part 1): Why CORS Error Occurs?, we understood why the browser has a same-origin policy and that the blocked cross-origin request is actually the response, not the request. After clarifying some misconceptions and having a basic understanding of CORS, we can now talk about how to solve CORS issues.

First of all, I want to let you know that the methods mentioned in this article are not complete solutions. In fact, cross-origin requests are divided into two types: simple requests and non-simple requests. The fact that “the blocked cross-origin request is actually the response, not the request” basically only applies to simple requests, and this article will only focus on “simple requests”. As for how to distinguish between simple and non-simple requests, and how to handle non-simple requests, these will be discussed in the next article.

There are actually many ways to solve basic CORS errors. Let’s first introduce a few “palliative” methods:

1. Turn off the browser’s security settings.
2. Set the fetch mode to no-cors.
3. Do not use AJAX to fetch data.

After discussing these three methods, we will talk about the last and most correct method: “Add CORS header to the backend”.

Read More

Preface

Three years ago, I wrote an article: Easy Understanding of AJAX and Cross-Origin Requests, which mentioned API integration, AJAX, same-origin policy, JSONP, and CORS. At that time, I put everything I wanted to say into it, but looking back now, it seems that many important parts were not mentioned.

Three years later, I am challenging this topic again and trying to express it more completely.

The reason why I want to write this series is that CORS is a frequently asked topic in programming-related discussion forums, and both front-end and back-end developers may ask related questions.

So I thought: “Okay, then I’ll write a series. I want to try to write this topic so that everyone who encounters CORS problems will come to see this series, and after reading it, they will know how to solve the problem.” This is my goal for this article. If the quality of the article cannot achieve this goal, I will continue to improve it.

This series consists of six articles:

• CORS Complete Guide (Part 1): Why CORS Errors Occur?
• CORS Complete Guide (Part 2): How to Solve CORS Problems?
• CORS Complete Guide (Part 3): CORS Detailed Explanation
• CORS Complete Guide (Part 4): Let’s Look at the Specification Together
• CORS Complete Guide (Part 5): Security Issues of Cross-Origin Requests
• CORS Complete Guide (Part 6): Summary, Afterword, and Leftovers

It will start from the same-origin policy, then talk about why there are errors when accessing resources across origins, and then talk about how to solve CORS-related problems correctly and incorrectly. The third article will explain in detail the detailed process of cross-origin requests, such as preflight requests.

The basic part is enough to read the first three articles, and the following will be a bit deeper. The fourth article will take you to look at the spec together, proving that the previous articles were not nonsense, and the fifth article will show you cross-origin-related regulations such as CORB (Cross-Origin Read Blocking), COEP (Cross-Origin Embedder Policy), or COOP (Cross-Origin-Opener-Policy), and related security issues. The last article will be some scattered topics and thoughts.

Read More

Introduction

Have you ever heard of vite? With a name starting with “v”, you might guess that it’s related to Vue. Yes, it’s another tool developed by the creator of Vue, Evan You. Originally intended for use with VuePress, it has proven to be much more versatile.

On the GitHub page for Vite, there are only two sentences:

Native-ESM powered web dev build tool. It’s fast.

If you’ve tried it, you’ll know that it really is fast. Vite is a combination of a build tool and a dev server. In this article, we’ll briefly introduce how to use Vite, then talk about ES modules, and finally explore the magic of Vite.

Read More

Introduction

While making some performance adjustments at work, I accidentally discovered a strange phenomenon. After investigating further, I found a bug that seemed to have gone unnoticed by anyone, and I found the cause quite interesting. So I thought I’d write a post to share it with everyone.

This post is not very technical, so you can read it with a story-telling mindset, which will make it more interesting.

The Beginning of the Story

The origin of the story is that I was making some adjustments to a website at work, trying to improve its loading speed. When it comes to performance optimization, there are many things that can be done. For example, with regard to the server, the following are more relevant:

1. Use HTTP/2
2. Use gzip or brotli for compression
3. Use Cache (to speed up revisits)
4. Use CDN
5. Reduce TTFB time

However, all of the above require assistance from the backend or SRE, and are not very relevant to the frontend. With regard to the frontend, there are many aspects to consider. For example, from the perspective of “reducing resources,” the following can be done:

1. Image format adjustment (compression + webp or other formats)
2. JS size (ugligy, code splitting, dynamic import)
3. CSS size (minify, remove unnecessary CSS)

From the perspective of “accelerating the loading of important resources,” preload or preconnect hints can be added to indicate to the browser which things should be loaded first.

You can also look at it from the perspective of “reducing JS execution time.” For example, if you are writing React, you can use shouldComponentUpdate, PureComponent, or memo to reduce unnecessary re-renders.

Since the title of this post is “styled components,” the main topic is, of course, centered around CSS.

Read More

Introduction

In my blog, there are actually few tool-related tutorial articles. One reason is that these tool-related articles are all similar, and the other reason is that I am lazy and many step-by-step tutorials require detailed descriptions and rich screenshots, which is not suitable for me.

But this time I decided to write this topic because I think webpack is a tool that beginners are not easy to understand, and even if they understand it, they may not really understand it. In other words, it is a tool that is often misunderstood.

This is not a problem with webpack itself, but many beginners now start with React or Vue directly in front-end development, and they all use the CLI tools provided by them. When they need to customize some settings, they will notice: “Oh, there is a thing called webpack.”

CLI tools bring convenience, and the advantage is that beginners can quickly get started without worrying about those cumbersome settings; the disadvantage is that if beginners are not aware of the tools behind them, when the tools are broken, cannot be used, or need to be modified somewhere, it will be the beginning of a nightmare.

In order to reduce this situation, I decided to write this article, hoping to introduce everyone to the concept of webpack and modularity from the source. You must first know what a module is to understand what webpack is.

At the beginning, I want to let everyone think about their familiarity with modularity and webpack through a few questions:

1. Why do many projects (such as React) need to be built before deployment? What is this step doing?
2. Do you know the difference between require/module.exports and import/export?
3. Do you know that these two syntaxes of import and export cannot be used casually on the browser?
4. Do you know why to use webpack?
5. Do you know why webpack needs a loader?

These questions should inspire you a little bit while reading this article, and I will answer them for you at the end.

Read More

Introduction

In recent years, front-end frameworks have been flourishing, and many beginners who have just learned JavaScript have directly learned the three major frameworks (although React is not a framework, the entire ecosystem is actually no different from the framework, so I think it can be classified as a framework).

These three major frameworks are usually used to write SPA (Single Page Application). I have always believed that some basic knowledge should be possessed before learning these frameworks, especially the understanding of front-end and back-end. Otherwise, you will definitely encounter many problems that you don’t know where to start.

Therefore, this article uses a problem that I have encountered myself and that students often come to ask me as an example. You can also think about whether you can answer this question:

Suppose I have an SPA, using a library of some routers to implement routing, so /list will go to the list page, and /about will go to the about me page.

But strange, when I uploaded the SPA to GitHub Pages, the homepage is good, and when I go to /list from the homepage, it is also good, but when I refresh /list, it shows 404 not found. Why is this?

To answer this question, you must first review some basic knowledge related to front-end and back-end networks.

Read More

(The original article was written on Medium, and I’m backing it up here.)

Although I have always been clear about my preferred learning methods and paths, and have turned what I think is suitable into a course outline for teaching, few people seem to look at that outline, and it does not explain the reasons behind it in detail. Therefore, I feel it is necessary to write this article to describe what I think is a “solid” front-end learning path.

Read More