Front end new person 1, still study hard, write not good, beg light spray, thank ~

Background:

This project is a simple web game — 2048 written by HTML, CSS, javascript, jquery tools. Final project file index respectively. The HTML, 2048. The CSS, main2048. Js, support2048. Js, animation2048. Js code after being submitted to making final will be git page deployment, facilitate the preview running effect.

Attached here is the source code of the project and my own process notes (interested friends can also try their own) :

Code: github.com/rokumeow/20… Running effect: rokumeow. Making. IO / 2048 game/process result and notes: www.jianshu.com/p/bd8c283e0…

Question:

The project runs normally in the local VsCode, but when it is deployed to git page, all js files are not loaded, only HTML files and CSS files are loaded successfully, so the function cannot run normally.

Cause investigation:

Put all the JS code into the HTML file’s built-in script tag and run it again. The result is still the same as before, but there is an error message: $sign is undefined, so we can see that the js failed to load because the jquery library failed to import.

Check the jquery import statement:

< script type = "text/javascript" SRC = "http://ajax.microsoft.com/ajax/jquery/jquery-1.4.min.js" > < / script >Copy the code

Do not use Google link when importing jquery library in China, it is easy to be unstable. However, this project uses jquery links provided by Microsoft, so there should be no unstable links.

Later, under the guidance of my colleague, I changed the HTTP in this statement to HTTPS, and found that the jquery library can be imported correctly, and the JS file can be loaded correctly. The modified statement is:

< script type = "text/javascript" SRC = "https://ajax.microsoft.com/ajax/jquery/jquery-1.4.min.js" > < / script >Copy the code

Deep thinking

The first jquery import statement is from a fairly well-known tutorial site, and it works in VsCode, but why is there a protocol problem when deploying on GitHub? So I searched a lot of relevant information, hoping to understand this problem.

(Excerpts from Resources)

By default, browsers do not allow references to HTTP resources in HTTPS.

The load will continue only after the user confirms, and the user experience is very poor. And if you dynamically import HTTP resources in an HTTPS page, such as a JS file, it will be blocked directly. After Chrome V21, non-SSL Embed Flash resources on SSL encrypted pages are also silently blocked, leaving only a console report.

HTTPS is now the dominant trend on the web, and even big companies like Apple require users to use HTTPS addresses entirely.

However, with old HTTP links, we tend to have a compatibility problem because you can’t switch over all at once, and HTTPS and HTTP should coexist for a long time.

* Source: blog.csdn.net/qq_38834352…

HTTPS and HTTP security

Why is HTTPS considered secure and HTTP not?

The HTTP protocol to express transport protocol, the interaction process and data transmission is encrypted, communication both sides also does not have any certification, communication process is very vulnerable to hijacking, to monitor, tampered with, severe cases, the cause of malicious traffic hijacked, even cause personal privacy leak (such as bank card card number and password leak) such as a serious security problem.

HTTP communication can be likened to sending A letter. A person sends A letter to B, and the letter passes through the hands of many postmen in the process of delivery, who can open the letter and read the contents (because HTTP is transmitted in plain text). Any content in A’s letter (including various account numbers and passwords) can be easily stolen. In addition, postmen can also forge or modify the content of the letter, so that the content of the letter received by B is fake.

For example, in the process of HTTP communication, “middlemen” embed advertising links in THE HTTP packets sent by the server to users, resulting in many bad links in the user interface. Or change the URL of the user’s request header so that the user’s request is hijacked to another site and never reaches the real server. All of these will lead to users can not get the right service, or even a heavy loss. The main difference between HTTPS and HTTP is that the SSL layer is added. In addition, HTTPS adopts asymmetric encryption, symmetric encryption, digital certificates, and digital signatures to ensure security.

The concept of asymmetric encryption and decryption is introduced in HTTPS protocol. In asymmetric encryption and decryption algorithms, the data encrypted by the public key can be decrypted only by the unique private key. Therefore, as long as the server sends the public key to the client, the client can use the public key to encrypt the symmetric key for data transmission. When a client uses a public key to send a symmetric key to a server, even if a middleman intercepts the message, it cannot be decrypted because the private key is deployed only on the server and no one else has it, so only the server can decrypt it. After the server gets the client’s information and decrypts it with the private key, it can get the symmetric key used to encrypt and decrypt the data, and use this symmetric key to encrypt and decrypt the data of subsequent communication. In addition, asymmetric encryption can manage the symmetric key well and ensure that the symmetric key is different every time data is encrypted. In this way, even if the client virus pulls the communication cache information, it cannot steal the normal communication content.

Symmetric encryption means that encryption and decryption use the same key algorithm. It requires the sender and receiver to agree on a symmetric key prior to secure communication. The security of symmetric algorithms depends entirely on the key, and key leakage means that anyone can decrypt the messages they send or receive, so the confidentiality of the key is crucial for communication. A digital certificate is a unique proof of identity given to a website by a third party (CA), just like an ID card. The certificate contains two main parts, one is plaintext information (including the public key of the server, information about the server itself, and information about the third party. Used to transfer the server public key, and generate message digest, verify whether the information is tampered with), the second is digital signature. The process of generating a digital signature is as follows: A message digest is generated using the hash algorithm based on the server URL information, and then the message digest is encrypted using the CA private key. (Note that the ca’s private key is not known to the server, it only has a digital signature.) After receiving the certificate, the browser first uses the CA’s public key to decrypt the digital signature and generate the corresponding message digest. The same hash algorithm is used to process the server url and generate the message digest. Comparing the two message digests, which are identical, verifies that the server’s public key has not been tampered with.

The overall HTTPS process is shown as follows:

* References and Sources:

Blog.csdn.net/xifeijian/a… www.cnblogs.com/whalesea/p/… Blog.csdn.net/howgod/arti…

HTTPS and HTTP coexist in the following scenarios:

  1. The app has been published and its calling interface address is HTTP, so this must be compatible.
  2. The H5 page is embedded in the APP, which is accessed using HTTP in the previous design. If the URL is changed to HTTPS, the H5 page may not be opened.
  3. For traffic promotion services, the original HTTP promotion address may have been sent to a third party. Even if you notify the third party to request HTTPS, the access to the HTTP address is not excluded.

For the above scenario, we definitely want HTTPS and HTTP to coexist.

Change HTTPS at first glance, in fact, is a domain name pointing to the problem, maybe we just want to HTTP request, directly jump to HTTPS address, then complete HTTPS switch. It’s not that simple. If an HTTP resource is loaded from an HTTPS address, the browser will consider it to be an insecure resource *[1]* and will block it by default. This will cause incomplete resource problems, such as images that do not display, styles that do not load, and JS that do not load. Because the style class is basically written in the local, so it is generally ok, but some public JS files, often exist in the CDN or other servers, at this time, if not access, may lead to the business can not be completely operated. For example, if the jquery template load fails, all operations and requests may be invalid. If the js file in the project cannot be loaded, it will directly cause the project effect (use $error). As shown below:

Jumping from HTTP requests to HTTPS requests is one solution, and many companies do this, such as Baidu, but only if all services have been switched to HTTPS.

* source: blog.csdn.net/ganquanzhon…

The author:ForFuture Group

How to solve the problem

  1. The dumbest approach is to simply copy the original code and write two sets of code, one for HTTP and one for HTTPS, each pointing to its own service.

  2. Available methods, with the same set of code, in the background request to identify the protocol, the variable to the HTML page, for protocol replacement, such as: background variable, $protocol = ‘https://’; The foreground receives variable SRC ='{$protocol}res.aa.com/jquery.js’.

  3. H5 method, load the protocol situation itself with JS, as in body ο NL ο AD =’ AA ()’. In aa() method, load the resources as required.

  4. For example, if the current page is an HTTPS page, it is an HTTPS resource. If the page is an HTTP page, it is an HTTP resource. Concrete methods to realize simple: < script SRC = “/ / cdn.bootcss.com/jquery/3.3.1/jquery.min.js’ > < / script >

Mixed Content

HTTP resources loaded in HTTPS web pages are called Mixed Content, and different browsers treat Mixed Content differently.

Dynamic import of HTTP resources in HTTPS pages, such as import of a JS file, will be blocked directly. An AJAX request for an HTTP resource in an HTTPS page will also be blocked.

Solution:


This means that an insecure HTTP request is automatically upgraded to an HTTPS request.

Upgrade-insecure -requests for more information

Migrating to HTTPS is often a huge task for a large site with a long history, especially when it comes to replacing all resources with HTTPS, which can easily slip through the cracks. Even if all the code confirms that there is no problem, it is likely that some of the fields read from the database still have HTTP links.

The upgrade-insecure-requests CSP directive lets the browser do the conversion for you. After enabling this policy, there are two changes:

  • All HTTP resources on the page will be replaced with HTTPS addresses to initiate requests.

  • Page all site links, click will be replaced by HTTPS address to jump again;

It is important to note that upgrade-insecure requests only replaces the protocol part, so it only applies to the scenario where the HTTP/HTTPS domain name and path are identical.

* source: blog.csdn.net/ganquanzhon…

The author:ForFuture Group

Supplementary information:

[1] Not all browsers have stopped loading HTTP resources. It should be noted that the browser in this article mainly refers to Google’s Chrome browser.

According to Google, Chrome users now spend more than 90 percent of their browsing time on HTTPS across all major platforms. However, it is not uncommon for secure pages to load HTTP child resources that are not secure. Many of these sub-resources are blocked by default, but some sneak in as images, audio and video, or “mixed content” that can put users at risk, such as scripts, iframes, and media files.

Starting with Chrome 79, which will begin testing in December 2019, Chrome will gradually block all mixed content. By January 2020, Chrome 80 will automatically upgrade all mixed audio and video resources to HTTPS, and will automatically block them if they cannot be loaded over HTTPS. Finally, in February 2020, Chrome 81 will automatically upgrade all mixed images, audio, and video to HTTPS and block images that cannot be loaded over HTTPS. A new setting will also be added to Chrome 79 that users can use to unblock mixed content on specific sites. This transition gives developers time to migrate their mixed content to HTTPS. In a similar move, as we reported earlier, Google Chrome engineer Emily Stark has proposed on the W3C mailing list a plan to ban some HTTP downloads on HTTPS sites by default, Browsers will block downloads when it comes to EXE, DMG (Mac application binaries), CRX (Chrome extensions), and mainstream compressed/packaged files such as ZIP, GZIP, BZIP, TAR, RAR, and 7Z. These file types that block downloads by default are considered “high risk” because they are most likely to be abused to hide malicious programs.

* source: www.ithome.com/0/448/673.h…