Up dumped four arithmetic problem, the algorithm is indeed weak, the whole Mongolia:
Written part
算法题1：
leetcode 283：https://leetcode-cn.com/problems/move-zeroes/submissions/
Algorithm:
var moveZeroes = function(nums) {
var sum = 0;
var len = nums.length;
for(let i=0;i<len;i++) {
if(nums[i] === 0) {
sum++;
nums.splice(i, 1);
i--;
}
}
for(let i=0;i<sum;i++) {
nums.push(0);
}
return nums;
};
算法题2：
leetcode 617：https://leetcode-cn.com/problems/merge-two-binary-trees/
Algorithm:
var mergeTrees = function(t1, t2) {
if(t1 === null) {
return t2;
} else if(t2 === null) {
return t1;
} else {
t1.val = t1.val + t2.val;
t1.left = mergeTrees(t1.left, t2.left);
t1.right = mergeTrees(t1.right, t2.right);
return t1;
}
};
Problem 3 algorithm:
the main function page page entry in page.js, less its dependency tree.
For performance requirements we will assemble a combo page request: http: //res.wx.qq.com/F.js,E.js,D.js,C.js,B.js,A.js,page.js each file is a self-running js anonymous function wrapped up, the server side in order to return the combined js file.
Please design gen_url (requireTree), the return value will be as shown in the combo url.
requireTree data structure on the following page.
requireTree = {
"name": "page.js",
"require": [{
"name": "A.js",
"require": [{
"name": "C.js",
"require": [{
"name": "F.js"
}]
}]
}, {
"name": "B.js",
"require": [{
"name": "D.js",
"require": [{
"name": "F.js"
}]
}, {
"name": "E.js",
"require": []
}]
}]
}
Algorithm:
(to be filled)
算法题4：
leetcode 503：https://leetcode-cn.com/problems/next-greater-element-ii/solution/
Algorithm:
var nextGreaterElements = function(nums) {
var max = Number.MIN_SAFE_INTEGER;
var len = nums.length;
var res = [];
var stack = [];
if(!nums.length) {
return [];
}
if(nums.length === 1) {
return [-1];
}
nums.forEach((item, index) => {
if(item > max) {
max = item;
}
})
var newNums = [];
var loop = nums.concat(nums);
var length = loop.length;
for(let i=0; i<len; i++) {
if(nums[i] === max) {
newNums.push(-1);
continue;
}
for(let j=i+1; j<length; j++) {
if(loop[j]>nums[i]) {
newNums.push(loop[j]);
break;
}
}
}
return newNums;
};
Interview part
1. Please talk http request getand postdifferences
-
GET is harmless when the browser is rolled back and the POST request will be submitted again.
-
GET URL address can be generated Bookmark, and not POST.
-
GET requests are active cache browser, POST will not, unless manually.
-
GET request can only be url encoded, and POST supports multiple encoding.
-
GET request parameters are intact in the browser history, and the POST parameters will not be retained.
-
GET request transmitted in the URL parameters are limited length, without the POST.
-
The data type of the parameter, GET accepts only ASCII characters, but there is no limit POST.
-
GET more secure than POST, because the parameters directly exposed on the URL, it can not be used to transmit sensitive information.
-
GET parameters passed via the URL, POST Request body in place.
(The above is the answer from W3CSchool)
In addition, there are some differences:
- GET request generates a TCP packet, the TCP POST request generating two packets (header are transmitted and body).
- In the method will first send a request custom request header OPTIONS request to the server transmits server supports the presence of a complex request or a POST request. (Why would send OPTIONS request may be reading this: https: //juejin.im/post/5cb3eedcf265da038f7734c4)
2. find out about cookie security-related attributes?
Detailed answers, including other browser stores (localStorage, sessionStorage, IndexedDB, etc.) venue: HTTPS: //github.com/ljianshu/Blog/issues/25
the cookie security-related attributes:
the cookie flaw:
- cookie is too small, only about 4k
- Excessive cookie will bring a huge waste of performance
- Because plain text transmission, so security is a problem, unless you are using HTTPS
3. CSRF (cross-site request forgery)
this problem can be said that the failure of this interview, originally knowledge will be, but here came a cropper.
Cross-site request forgery can occur under what circumstances it?
As can be seen from the figure, to complete a CSRF attack, the victim must complete two steps in sequence:
- Login trusted site A, and generates Cookie locally.
- In the case of A is not out of, access to dangerous websites B.
See here, you might say: "If I do not satisfy more than one of the two conditions, I would not be CSRF attacks." Yes, it does, but you can not guarantee that the situation will not occur:
- You can not guarantee that you log on a web site, the page will not open a tab and visit another site.
- You can not guarantee that after you close your browser, your local Cookie expire immediately, your last session has ended. (In fact, close your browser can not end a conversation, but most people will mistakenly believe that the browser is closed is equivalent to Log / end the session up ...)
- The figure above the so-called attack site, a site may be frequently accessed trusted person other vulnerabilities exist.
How to protect CSRF?
- Use JSON API
using JavaScript AJAX request is to limit cross-domain, and not by a simple<form>form to send JSON, therefore, may very likely prevent CSRF attacks by receiving only JSON. - Join HTTP Referer field
when a user initiates a request by hackers site to legitimate sites, only through the construction site request hacker, then verify HTTP Referer field is a pointer to a hacker site. If the user sends a request through legitimate Web site, the HTTP Referer is pointing to a legitimate site, the server may be considered that the request is legitimate. - Add takon address verification request in
a CSRF attack's success is because hackers can forge entirely the user's request, the request for all user authentication information is present in a cookie, so hackers can not know where the authentication information under the direct use cookie to the user's own security through authentication. To resist CSRF, wherein the key information into the hackers can not be forged in the request, and the information is not present in the cookie. May be added token randomly generated as a parameter in the HTTP request, and the establishment of an interceptor server side to authenticate the token, if the request is not token or token not correct, it is considered likely CSRF attacks reject the request .
This method is safer than some of the Referer check, token can be generated and placed into the session after the user has logged out of the session and then the token at each request, to compare with the request token.
4. In your project, you think the most interesting is a project which?
This problem made clear that the interviewer wanted to test my thinking on the project, but I think the project really is a bad place to do the project yourself feel only two points:
- Did not do a particularly large number of security, protection simply a XSS (cross site scripting)
- No architecture well organized code (document classification more chaos, and that the route organization duplicate)
The interviewer raises cookie and security related properties and CSRF two issues from the first security, then I only know the result of the cookie part of the security attributes.
In fact, part of the back-end security is done using a token verification request is legitimate and login state maintained, but the front end of the design process because the team communication problems, leading to back-end design of the token, and the front end only after the completion of most of the know token, the ultimate front-end to maintain login state can only be done by setting a cookie expiration time, there is no way to verify the request.
to sum up
Inadequate preparation only major problem, at that time the interviewer called to ask what time the interview can sometimes loose tongue, said today on the line, there is no ill-prepared, had not normal. Recent studies really busy, coursework examination pressure big. In this way it will only continue to work hard.
Life is like Inner Challenge, I am also a pedestrian.