preface

This series started with preparing yourself for an interview. Later found more and more sorting, almost 120,000 characters, finally decided to share to everyone.

In order to share the sorting out, I spent a lot of time, at least three times as much time as ONLY myself. If you like, welcome to collect, follow me! Thank you very much!

The article links

  • Front – end interview check and fill gaps -(1) tremble and throttling
  • (2) Garbage collection mechanism
  • (3) Cross-domain and common solutions
  • (4) Front-end local storage
  • (5) Rendering mechanism and redraw and backflow
  • Front – end interview -(six) browser cache
  • (7) XSS attack and CSRF attack
  • (8) Front-end encryption
  • (9) HTTP and HTTPS
  • Check and fill gaps in front interview –(10) Front authentication
  • (11) Front-end software architecture pattern MVC/MVP/MVVM
  • (12) From the input URL to the page to see the whole process (including three handshake, four wave detailed explanation)
  • Front – end interview leak -(13) memory leak
  • Front – end interview omission and filling -(xiv) algorithm and sorting
  • (15) Event Loop

Collection of articles:

The Index (120,000 character collection) contains more than a dozen other articles in the series written so far. The following new value-added articles will not be added in each link, strongly suggest that the comments like, pay attention to the collection!!!! , thank you! ~

Follow-up Update Plan

Design pattern, front-end engineering, project process, deployment, closed loop, vUE often test knowledge and other contents will be added in the future. If you think the content is good, welcome to collect, follow me! Thank you very much!

Ask for an extrapolation

At present, I am also preparing for job-hopping. I hope you and HR sister can promote a reliable front-end position in Wuhan! Email :[email protected]. Thanks! ~

An overview of the

Because browsers have the same origin policy for security reasons, any difference in protocol, domain name, or port is treated as a different domain. That is, if one of the protocol, domain name, or port differences is cross-domain, the Ajax request will fail.

Common cross-domain solutions

JSONP

The principle of JSONP is simply to take advantage of the fact that 

<script src="http://domain/api? param1=a&param2=b&callback=jsonp"></script> <script> function jsonp(data) { console.log(data) } </script>Copy the code

JSONP is simple to use and compatible, but it is limited to GET requests.

In development, you may encounter multiple JSONP requests with the same callback name. In this case, you need to encapsulate a JSONP. Here is a simple implementation

function jsonp(url, jsonpCallback, success) {
  let script = document.createElement('script')
  script.src = url
  script.async = true
  script.type = 'text/javascript'
  window[jsonpCallback] = function(data) {
    success && success(data)
  }
  document.body.appendChild(script)
}
jsonp('http://xxx'.'callback'.function(value) {
  console.log(value)
})
Copy the code

CORS

Cross-origin ResourceSharing (CORS), which defines how browsers and servers communicate when accessing cross-domain resources.

The basic idea behind CORS is to use custom HTTP headers to let the browser communicate with the server to determine whether the request or response should succeed or fail. Currently, all browsers support this function. The value of Internet Explorer cannot be lower than IE10. Because it needs to be implemented through XDomainRequest.

The entire CORS communication process is completed automatically by the browser without user participation. For developers, CORS communication is no different from the same source AJAX communication; the code is exactly the same. Once the browser realizes that the AJAX request is cross-source, it automatically adds some additional header information and sometimes an additional request, but the user doesn’t notice.

Therefore, the key to CORS communication is the server. As long as the server implements the CORS interface, it can communicate across sources.

Server side for CORS support, is mainly through the setting of access-control-allow-Origin. This property indicates which domain names can access the resource. If the wildcard character is set, all websites can access the resource. If the browser detects the Settings, Ajax can be allowed to make cross-domain access.

postMessage

This is the API proposed by H5, IE8 above support this function. The window.postMessage() method enables safe cross-source communication. Typically, scripts for two different pages can communicate with each other only if the page on which they are executed is on the same protocol (usually HTTPS), the port number (443 is the default for HTTPS), and the host (the modulus document.domain of the two pages is set to the same value). The window.postMessage() method provides a controlled mechanism to circumvent this restriction, and as long as used correctly, this method is safe.

When the window.postMessage() method is called, it sends a MessageEvent message to the target window after all the page scripts have been executed.

The MessageEvent message has four properties to note:

  • The message property indicates the type of the message;
  • The data property is the first argument of window.postMessage;
  • The origin property represents the current state of the invoked page when the window.postMessage() method is called;
  • The source property records information about the window in which the window.postMessage() method was called.

grammar

otherWindow.postMessage(message, targetOrigin);

  • OtherWindow: the target window, i.e. the window to which the message is sent, is either a member of the window.frames property or a window created by the window.open method
  • Message: indicates the message to be sent. The type is String or Object (not supported in IE8 and IE9).
  • TargetOrigin: specifies the range of messages to be received. If not, use ‘* ‘

Example:

A page sends A message through the postMessage method:

window.onload = function() {  
    var ifr = document.getElementById('ifr');  
    var targetOrigin = "http://www.google.com";  
    ifr.contentWindow.postMessage('hello world! ', targetOrigin);  
};
Copy the code

B the page listens for and receives messages via the Message event:

var onmessage = function (event) {  
  var data = event.data;/ / message
  var origin = event.origin;// Source address
  var source = event.source;// Source Window object
  if(origin=="http://www.baidu.com") {console.log(data);//hello world!  }};if (typeof window.addEventListener ! ='undefined') {  
  window.addEventListener('message', onmessage, false);  
} else if (typeof window.attachEvent ! ='undefined') {  
  //for ie  
  window.attachEvent('onmessage', onmessage);  
}
Copy the code

Nginx agents cross domains

Cross-domain Principle: The same-origin policy is a browser security policy and is not part of the HTTP protocol. The server side only uses THE HTTP protocol to call the HTTP interface, and does not execute JS scripts. It does not need the same origin policy, so there is no spanning problem.

Implementation idea: NGINx is used to configure a proxy server (with the same domain name as domain1 but different ports) as the jumper. The reverse proxy accesses the interface of Domain2. In addition, the domain information in cookies can be modified to facilitate the writing of cookies in the current domain and realize cross-domain login.

Nginx configuration:

# proxy server
server {
    listen       81;
    server_name  www.domain1.com;

    location / {
        proxy_pass   http://www.domain2.com:8080;  # Reverse proxy
        proxy_cookie_domain www.domain2.com www.domain1.com; Change the domain name in cookie
        index  index.html index.htm;

        # When accessing nignx using middleware proxy interfaces such as Webpack-dev-server, no browser is involved, so there is no same-origin restriction, the following cross-domain configuration is not enabled
        add_header Access-Control-Allow-Origin http://www.domain1.com;  * is used when the current end is cross-domain and does not contain cookies
        add_header Access-Control-Allow-Credentials true; }}Copy the code

WebSocket and NodeJs middleware cross-domain and other methods

None of these methods are used very much except nodeJS. WebSocket is not used specifically for cross-domain purposes, but for messaging, chat, etc.

The rest of the methods, detailed can refer to: Front-end Common cross-domain Solutions (full)