Among the various data types in JavaScript, Number is a very commonly used one, and there are some small details that need to be paid special attention to, otherwise it is easy to write code with bugs.
This article will show you some examples, some are hypothetical scenarios, and some are problems I have encountered myself. Before continuing to explain each case, you can try to put yourself in the scenario and think about whether you know the cause of the problem and how to avoid it.
How many data types are there in JavaScript? And what are they?
Before discussing data types, we should first know how many types there are in JavaScript and have a basic understanding of each type. Before we start, you can count them yourself and then compare your answer with mine to see if it is correct.
As JavaScript evolves, this article will use the latest ECMAScript 2021 as the standard. If “spec” is mentioned below, it refers to the ECMAScript 2021 language specification .
I believe that in order to understand the JavaScript programming language, it is important to understand the concept of the “execution environment” or “runtime”. Many people are not aware of this concept, which can lead to differences in understanding of JavaScript or other technologies. Therefore, in this article, let’s talk about the execution environment.
Note: In addition to “runtime”, “execution environment” is also used to refer to the same concept, but these two terms are completely different. To avoid confusion, we will use the term “runtime” throughout this article.
Also, “runtime” has many meanings, but in this context, it refers to the runtime environment.
If you don’t know what CTF is, you can refer to my previous article: How to Get Started with Web Challenges in CTF?, which briefly introduces what CTF is and some basic types of challenges.
I played DiceCTF 2021 seriously last year and finally solved 6 web challenges. My experience is here: DiceCTF 2021 - Summary. I took a look at this year’s DiceCTF and was completely shocked. The difficulty level is completely different.
There are a total of 10 web challenges this time, with 1 easy challenge solved by 365 teams, another relatively simple one solved by 75 teams, and the other 8 challenges solved by only 5 teams or less, with one of them unsolved.
As a person who likes web and JS-related tips, this is a great learning opportunity to learn various techniques through the writeup released after the competition. There won’t be notes on all web challenges below, only the ones I’m interested in.
After discussing the history and baggage of JavaScript, let’s talk about JavaScript itself.
Have you ever wondered how to know if an author of a JavaScript book or tutorial article has written it correctly? How do you know if the knowledge in the book is correct? As the title suggests, could it be that the JavaScript knowledge you previously knew was actually wrong?
Do you just trust the author because they often write technical articles? Or do you believe it because it’s written the same way on MDN? Or is it because everyone says it, so it must be right?
Some questions do not have standard answers, such as the trolley problem, where different schools of thought will have their own approved answers, and there is no saying which one is necessarily correct.
Fortunately, the world of programming languages is relatively simple. When we talk about JavaScript knowledge, there are two places where you can verify whether this knowledge is correct. The first is called the ECMAScript specification, and the second one, we’ll talk about later.
Although Same Site and Same Origin may seem similar, they are actually quite different. This difference affects how the browser perceives the relationship between these two websites and the permissions it grants.
This article will cover the following topics:
Without further ado, let’s get started!
(Before we begin, let’s answer a question. Yes, the title was inspired by the ninja Hattori.)
2022-01-20: Modified the “Examining Same Site” section to supplement the history of the scheme. Thanks to @littlegoodjack.
I believe that to truly understand JavaScript, we must start from its history. Why? Because by understanding its history, we can know why certain parts are designed in a certain way and why there are seemingly strange behaviors. Although some ancient knowledge may not have much practical use, it is very interesting to me.
Learning its history is not about memorizing the year it appeared or how many days it took to develop and design, but rather understanding the context in which it appeared and why it was needed and designed in a certain way.
If you want to learn about the history of JavaScript, my top recommendation is this resource: JavaScript: The First 20 Years, because Brendan Eich, the father of JavaScript, is also one of the authors. If you want to read the Chinese version, it is available here: JavaScript 20 Years.
This book records the history of JavaScript from 1995 to 2015, a total of 20 years. If you have time, I strongly recommend that you read it all. It will give you a different understanding of JavaScript (and you will also learn a lot of interesting facts).
Below, I will pick some of the more important things to write about. If there is no specific mention of the data source, it is from the book mentioned above, so it is normal if it seems familiar.
Since I was born around the same time as JavaScript, I have not personally experienced the early history. If it seems like I have participated in it, it is all just imagination.
This article has a little less technical content, and I would like to share with you the process of writing this series of articles and some thoughts after finishing it.
If you haven’t read this series of articles yet, the links are as follows:
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:
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.
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.