#JavaScript

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:

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

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

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

If you have written functions in other programming languages that are not first-class, you may experience some pain when writing JavaScript and wonder what you are doing - at least that’s how I feel.

When I first discovered that functions can be passed around as parameters, I had to think hard about more complex code, and other behaviors of functions also confused me, such as the fact that functions are also objects, and what exactly is this.

This article mainly wants to share some interesting aspects of functions. However, it is too boring to start talking about a lot of knowledge directly. I hope to arouse everyone’s curiosity about this knowledge. The best way to arouse curiosity is to provide a “question that you will also be interested in”. You will have the motivation to continue reading.

Therefore, the following uses a few small questions as the opening. Although they are in the form of questions, it doesn’t matter if you can’t answer them. If you are interested in the answers to these questions, please continue reading. If you are not interested, just go straight ahead and turn left at the end.

By the way, the title of this article was originally intended to be called “How much do you know about JavaScript functions” or “Interesting JavaScript functions”, but these titles are too boring, so I thought of this light novel-style (?) title.

Read More

Introduction

In two of my previous articles, I Know You Understand Hoisting, But Do You Really Understand It? and All Functions Are Closures: Discussing Scope and Closure in JS, I talked about the differences between the scopes of let and var.

The scope of let is block, while var is function. This is a classic example:

for(var i=1; i<=10; i++) {
  setTimeout(function() {
    console.log(i)
  })
}

It was originally expected to output 1 to 10 in order, but unexpectedly output 10 11s. The reason behind this is that the i on the third line always has only one, which is the var i declared in the for loop, and it is the same variable from beginning to end.

The classic solution is also very simple, just change var to let:

for(let i=1; i<=10; i++) {
  setTimeout(function() {
    console.log(i)
  })
}

The reason why this works is that the above code can be seen as the following form:

{
 let i=1
 setTimeout(function() {
    console.log(i)
  })
}

{
 let i=2
 setTimeout(function() {
    console.log(i)
  })
}

...

{
 let i=10
 setTimeout(function() {
    console.log(i)
  })
}

Since the scope of let is block, there is actually a new i in each round of the loop, so there are 10 different i after the loop runs 10 times, and of course, 10 different numbers are output in the end.

Therefore, the biggest difference between var and let in this example is the number of variables, the former has only one, while the latter has 10.

Okay, now that you know the difference between let and var, let’s take a look at the main issue of this article.

In fact, this issue comes from a question raised by @getify, the author of YDKJS (You Don’t Know JS), on his Twitter:

question for JS engines devs…
is there an optimization in place for this kind of code?

for (let i = 0; i < 10; i++) {
  // no closure
}

IOW, where the behavior of creating a new i per iteration is not needed nor observable… does JS skip doing it?

If you didn’t understand it very well, you can continue to read the other tweet:

here’s a variation on the question… will JS engines exhibit much performance difference between these two loops?

for (var i = 0; i < 100000000; i++) {
   // do some stuff, but not closure
}

for (let i = 0; i < 100000000; i++) {
   // do the same stuff (no closure)
}

Simply put, when we usually use let with loops, isn’t it like we said above, there will be a new i in each round? If so, then there should be a performance difference between var and let, because let must new a new variable in each round, so let will be slower.

If the loop does not need a new i in each round, will the JS engine optimize it? This issue is mainly to explore whether the JS engine will optimize this behavior.

So how do we know? Either you are a JS engine developer, or you can look at the JS bytecode, but both of these difficulties are a bit too high. But don’t worry, there is a third way: look at the JS bytecode.

Read More

Introduction

In the past few years, “problem-solving” seems to have become a trend. When students majoring in computer science go for interviews with big companies, they are required to solve problems. Even non-computer science students are expected to solve problems during interviews. It seems that if you don’t solve problems, you will fall behind others and be eliminated by the company.

Actually, I have never been fond of the term “problem-solving”, mainly because of the word “solving”. I don’t know how you interpret this word, but I feel that there is a sense of “solving problems just for the sake of solving problems”, just like the tactic of solving a lot of problems. Although this tactic can be effective if used properly, I always feel that many people will end up with the mentality of “I can solve the problems I have seen, but I can’t solve the ones I haven’t seen”. If that’s the case, I don’t think it’s a good thing.

I have written an article before: What should we learn when we are learning to code?, which briefly discusses this issue.

In short, I prefer to use the phrase “programming problem-solving” to express what I want to say, rather than the term “problem-solving”.

Read More