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

Preface

Recently, my interest is playing CTF, and I only play web problems inside, for a simple reason, because I don’t know anything about other fields… Currently, I am more interested in web things, so I solve problems as a leisure activity.

This article is a summary of the BambooFox CTF 2021, and I only solved three problems.

Read More

Introduction

As a front-end engineer, it is natural to know a lot about front-end-related knowledge, such as HTML or JS-related things, but those knowledge is usually related to “use”. For example, I know that when writing HTML, I should be semantic and use the correct tags; I know how to use JS. However, some knowledge related to web pages, although related to web pages, is not something that front-end engineers usually come into contact with.

What I mean by “some knowledge” actually refers to “knowledge related to information security”. Some concepts commonly found in information security, although related to web pages, are things that we are not familiar with, and I think understanding these is actually very important. Because you must know how to attack in order to defend, you must first understand the attack methods and principles before you know how to defend against these attacks.

Read More

Introduction

Blogs need to display publishing time, restaurant websites need to display reservation time, and auction websites need to display various order times. No matter what you do, you will encounter the very common need to display time.

This problem seems simple, just display the time, right? But if it involves “time zones”, the problem will become even more complicated. Regarding time zones, there are usually several requirements:

1. The time on the website needs to be displayed in a fixed time zone. I want to see the same time on the website whether I am in the United States or in Taiwan.
2. The time on the website will be different according to the user’s browser settings. I will see different times in the United States and Taiwan.
3. PM did not consider this issue and only considered local users, so there is no need to worry about this for the time being.

And this is only the display part. There is another part that communicates with the backend. We can talk about this later, but in any case, correctly handling time and time zones is not a simple matter.

I have recently encountered related issues in one or two jobs, so I have a little experience in this area and wrote this article to share with you.

Read More

Introduction

Recently, my colleagues at work took a course on information security. As I was already interested in information security, I discussed it with my colleagues, which led me to research related topics for the past two weeks. These were things I had heard of before but had not studied seriously, such as LFI (Local File Inclusion), REC (Remote code execution), SSRF (Server-Side Request Forgery), and various magical filters in PHP. I also reviewed SQL Injection and XSS, which I was already relatively familiar with.

In CTF challenges, situations often arise where you need to bypass various restrictions, which is an opportunity to test your understanding of specific protocols or programming languages. You have to think about how to find at least one way to successfully bypass those restrictions under existing limitations.

Originally, I didn’t know what to write about this week. I wanted to write about the things mentioned above, but I hadn’t figured out how to organize them yet. The follow-up series of “I Don’t know React” was not yet organized, so I thought it would be fun to do a little challenge related to “bypassing restrictions” with everyone. That is:

In JavaScript, can you successfully execute console.log(1) without using letters and numbers?

In other words, no English letters (a-zA-Z) or numbers (0-9) can appear in the code. Everything else (various symbols) is allowed. After executing the code, console.log(1) will be executed, and 1 will be printed in the console.

If you have thought of any interesting services or libraries that can do this before, don’t mention them yet. Before that, you can think about it yourself and see if you can write it out, and then check other people’s solutions.

If you can write it all by yourself from scratch, it means that you should be quite familiar with the JS programming language and various automatic type conversions.

Below, I will provide some of my own thoughts and the process of solving this problem. There are spoilers, so don’t scroll down if you haven’t solved it yet.

== Spoiler Alert ==
== Spoiler Alert ==
== Spoiler Alert ==
== Spoiler Alert ==
== Spoiler Alert ==

Read More

Preface

Note: Currently, this blog has problems supporting JSX syntax, so it may not be easy to read the code. I will fix it as soon as possible.

This title pays tribute to a series of books that people who write JavaScript have heard of even if they haven’t read them: You Don’t Know JS by Kyle Simpson. It talks about many things about JS that many people don’t know.

And I don’t know React is a series of records I made for myself, recording some React that I don’t know, and these articles are summarized from my experience using React. Some of the errors I have encountered may be very basic and common (just like those written in the official documents, but I didn’t read them carefully, so I don’t know), and some may be relatively rare (I may encounter them only after writing for three or four years at work).

In other words, the spirit of writing this series is different from YDKJS. The former wants to tell you some things about JS that few people know, and it feels like “I will teach you how to write JS”. The reason why I wrote this series called “I don’t know” is because I want to use a series of articles to record the misunderstandings or omissions I have encountered when writing React, and what is the correct answer.

I don’t know how many articles this series will have. I will post an article every time I make a mistake. There is a big difference in this series that I think is quite large. I will try to provide the scene where the mistake was made at the beginning of the article, so that everyone has the opportunity to debug before seeing the answer and see if they can find out where the error is. I think this is actually the most essential part. This is not a standardized interview question, nor is it a React quiz randomly found on the Internet, but a real situation I have encountered at work.

Because I want everyone to immerse themselves in the situation as much as possible and think about the problems I have encountered, there will be a lot of space for “defining and reproducing problems”. If you are not interested in finding answers yourself, you can also skip this part and go directly to see the answer. But I personally recommend that you try to debug it yourself first, find out where the problem is, and then come to see the answer in the article, so that you can fully absorb what the article wants to express.

Anyway, let’s take a look at the case we want to talk about in this article!

Read More

Introduction

Recently, I came across an article on the front-end community on Facebook: Understanding React useEffect 02, which discusses the usage of useEffect. There was also some discussion in the comments section.

Initially, I found the usage in the article a bit strange, but I could somewhat understand why it was written that way. However, I still found it odd. I wanted to leave a comment, but then I thought, “Maybe I’m the one who’s mistaken,” so I decided to think about it some more. After careful consideration, I realized that I was the one who was mistaken.

Therefore, in this post, I will share my thoughts. If there are any mistakes, please feel free to leave a comment below or discuss it with me in the front-end community. Before continuing to read, I recommend reading the original article and the discussion below it to better understand the context.

Read More

Introduction

If you want to store something in the front-end of a website, which means storing it in the browser, there are basically a few options:

1. Cookie
2. LocalStorage
3. SessionStorage
4. IndexedDB
5. Web SQL

The last two are rarely used, and the last one, Web SQL, was declared deprecated a few years ago. Therefore, when it comes to storing data, most people mention the first three, with the first two being the most commonly used.

After all, when storing data in the front-end, most data is expected to be stored for a period of time, and cookies and localStorage are designed for this purpose. However, sessionStorage is not, as it is only suitable for storing very short-term data.

I don’t know if your understanding of sessionStorage is the same as mine, so let me explain my understanding:

The biggest difference between sessionStorage and localStorage is that the former only exists in one tab. When you close the tab, the data is cleared, so a new tab will have a new sessionStorage, and different tabs will not share the same sessionStorage. However, if it is the same website, the same localStorage can be shared.

But let me ask you this: Is it possible that in a certain scenario, I store something in sessionStorage in tab A, and then a new tab B can also read the sessionStorage in tab A?

You might think it’s impossible, and I used to think so too, as did my colleagues.

But it turns out that it is possible.

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