Updated: September 18, 2020
foreword
Since the blogger wrote this article, many friends have come to ask me questions, and I am constantly trying to develop it myself. Now I will summarize the problems I have encountered from 17 years to the present, the problems encountered by friends and some data summary.
material
①: 3.0 development kit: https://download.csdn.net/download/yeyunfancy/9980157
②: 1.0.6 and 1.0.9 plug-ins and key code files: https://cloud.189.cn/t/JZ3yUv7BVzay
③: Fully compatible development kit: https://www.cnblogs.com/huangwei1061047046/p/11190514.html
④: node proxy: https://cloud.189.cn/t/NraieamEvAFf
The download address here is permanently valid except on csdn.
version difference
1. Version 1.0.6 is compatible with dual-core browsers. However, the plug-in and the code need to be consistent. For details, please refer to the remarks in Data 2.
2. 1.0.9 only supports IE core browser
3. Fully compatible development kit: support IE or Google or Firefox. Use websocket to fetch stream and session authentication in non-IE browsers . This enables plug-in-free development. But one thing to note is that the fully compatible development kit requires hardware support. That is to say, if the hard disk drive and camera do not support websocket streaming and session authentication , they cannot be used under non-IE browsers.
problem and solution
Question: Why does the non-full compatibility package not work on Google.
Solution: Because Google removed the support of NAAPI technology after version 70 (if I remember correctly), non-compatible plug-ins need to rely on NAAPI technology, so Google cannot use this plug-in.
Question: Why the capture function and video recording function cannot be used, and the function always returns undefined.
Solution: Because the version of the WebComponentsKit.exe plug-in is too high. Maybe you have browsed the official web terminal, and the downloaded WebComponentsKit.exe must be the latest version, but the latest version of WebComponentsKit.exe is not compatible with 1.0.6 webVideoCtrl.js. After testing, I have downloaded [ 3.0.6.1 ] and [ 3.0.6.2 ] two versions. Only version 3.0.6.1 is compatible with webVideoCtrl.js of 1.0.6. If you have installed a new version of WebComponentsKit, please uninstall and install the old version. The WebComponentsKit in Data Download ① is 3.0.6.1. Therefore, during the development process, the code for plug-in version monitoring needs to be removed. Each webVideoCtrl.js has a corresponding WebComponentsKit.exe plug-in. Readers are asked to pay attention when developing.
Use of fully compatible development kits
1. Simple development and use
The development kit contains the nginx program. Developers can run nginx, and then access the page by visiting 127.0.0.1. After filling in the correct information, it can be used normally. The premise here is that the front-end address you visit needs to pass through nginx, so as not to trigger cross-domain problems.
2. Secondary development
If you want to perform secondary development on the basis of demo, for example, use vue, webpack or other methods. When developing, developers should first encounter a 404 problem or a cross-domain problem. Here is the solution.
1), 404 problem . This will appear when the /ISAPI/Security/sessionLogin/ interface is called. This problem is because the webVideoCtrl.js file redirects the request address before initiating the request. You can avoid this by modifying the t and n parameters around line 220 of this file. The IP and port here are generally the login IP and port filled in your page.
The blogger here explains that the webVideoCtrl.js used by the blogger is the file in the development package in the above material 3, but I have seen another webVideoCtrl.js code in other friends' projects. In that code, a proxyAddress parameter is extended to the WebVideoCtrl.I_InitPlugin function. This parameter can modify the request IP+port without modifying the webVideoCtrl.js file. So developers can pay attention to whether the webVideoCtrl.js they use can use proxyAddress when modifying.ProxyAddress is not recommended here. In Google mode, after successful login, the video stream is obtained through websocket. When you use proxyAddress for xmlhttprequest proxy, websocket will be forced to proxy by the way, making websocket unusable. Therefore, it is recommended that users modify it directly in webVideoCtrl, or add a field dedicated to ajax proxy in webVideoCtrl.
se = function (e) {
var t = location.hostname, n = location.port || "80";
return /^(http|https):\/\/([^\/]+)(.+)$/.test(e) && (e = e.replace(RegExp.$2, t + ":" + n)), f.cookie("webVideoCtrlProxy", RegExp.$2, {raw: !0}), e
// return e;
}2) Cross-domain issues . After the above 404 problem is modified by IP. Developers will be prompted with a cross-domain issue after using the call method. Why cross-domain? That's because the address you requested is not of the same origin as your page address, and the browser prohibits your access based on the same-origin policy. There is one thing to say here: In the case of no plug-in development, the address requested by webVideoCtrl is the IP of the Hikvision HDD. Unless you can make your page have the same origin as the Haikang hard drive and the IP: port accessed, otherwise, without the help of a third party, basically the cross-domain problem cannot be solved. So here are two options.
2.1) Use Nginx as a proxy. This blogger has conducted a certain degree of testing, but it has not been able to be used. It's not clear why.
2.2) Use Node to write proxy services. The source code of the node proxy service is located in Document 4. This is a simple code written by the blogger himself. It can allow you to access across domains, and successfully log in and obtain channel information. The following is a general description based on the node service.
The main files of node service are serverConfig.js and app.js. Among them, some configurations for cross-domain processing are performed in serverConfig.js.
module.exports = {
port:54684, // node代理服务启动端口.可以修改为任意你需要的端口
proxy:{
'/':{
target:"http://192.168.4.167:80", // 页面登录时填写的IP和端口，也就是网络硬盘机访问的IP+端口。
changeOrigin:true,
ws:true,// 是否允许websocket
pathRewrite:{
}
}
}
}
In app.js, the key thing to pay attention to is cross-domain processing. First, you need to allow the Origin parameter. Here, this parameter cannot be configured with "*" , but needs to change dynamically according to the access address. The specific reasons will be discussed later. Secondly, headers also need to list the involved request headers, instead of using "*" configuration . Because when Origin is a detailed domain name, headers cannot use "*". Credentials allows browsers to carry cross-domain cookies.
// 不完全跨域处理代码
app.all('*', function(req, res, next) {
res.header("Access-Control-Allow-Origin", req.headers['origin']);
res.header("Access-Control-Allow-Headers", "X-Requested-With, If-Modified-Since, content-type,deviceidentify");
res.header("Access-Control-Allow-Credentials", "true");
res.header("Access-Control-Allow-Methods", "*");
});At this point, we execute npm run start to run the node service, and then change the address IP and port requested by the front end to 127.0.0.1:54684. Then we enter the login information and click Login. Through the network panel of F12, we can see that the interface /ISAPI/Security/sessionLogin/capabilitie can be requested normally, but when requesting the interface /ISAPI/Security/sessionLogin, the browser reports an error and prompts 400. why is that? This is because the hard drive does not respond to the options precheck sent by the browser. Therefore, we need to uniformly process the pre-check operation of options on the node server.
// 完整跨域处理
app.all('*', function(req, res, next) {
res.header("Access-Control-Allow-Origin", req.headers['origin']);
res.header("Access-Control-Allow-Headers", "X-Requested-With, If-Modified-Since, content-type,deviceidentify");
res.header("Access-Control-Allow-Credentials", "true");
res.header("Access-Control-Allow-Methods", "*");
if(req.method=="OPTIONS") res.sendStatus(200);/*让options请求快速返回*/
else next();
});When we pass the above processing, re-run. Now the login is successful, but there is a problem when obtaining the interface. The interface is crazily reporting 401 errors. What's wrong with this? The reason for this is: when webVideoCtrl initiates XMLHttpRequest, the cookie information does not follow the request, which leads to the failure of the hard drive permission determination. How to deal with it? In addition to enabling Access-Control-Allow-Credentials: true in node cross-domain, this process also needs to be around line 1007 of webVideoCtrl. After s.open(), add s.withCredentials=true. Allow XMLHttpRequest to carry cookies when making cross-domain requests. code show as below.
s.open(this.options.type, r, this.options.async),
s.setRequestHeader("X-Requested-With", "XMLHttpRequest"),
s.setRequestHeader("If-Modified-Since", "0"),
s.withCredentials = true,
s.send(this.options.data || null);If your webVideoCtrl can configure the proxyAddress parameter, then the above modification position is around line 1826. code show as below:
s.open(this.options.type, r, this.options.async);
if (p.proxyAddress) {
s.withCredentials = !0;
var o = (e = this.options.url, /^(http|https):\/\/([^\/]+)(.+)$/.test(e) ? RegExp.$2: "");
s.setRequestHeader("deviceIdentify", o)
}
s.setRequestHeader("X-Requested-With", "XMLHttpRequest"),
s.setRequestHeader("If-Modified-Since", "0"),
s.withCredentials = true,
s.send(this.options.data || null);At this point, after re-running the front end and node end, you will find that you can now log in and obtain channel information normally. However, since the blogger's Hikvision device does not support websocket streaming, it is impossible to test the subsequent functions. Therefore, whether it can be used normally in the future needs to be tested by yourself.
-------------------------------------------- The following is an old article, the above shall prevail -----------------------------------------
The project needs to use Hikvision's web plug-in for secondary development, but encountered many problems during the development process. Here are a few typical problems and solutions. Will add to it if there is more to come.
Download:
①: 3.0 development kit -----> http://download.csdn.net/download/yeyunfancy/9980157
②: version 1.0.6 webVideoCtrl.js. ------>http://39.108.169.199:8080/webVideoCtrl.js
1. Why the web terminal provided by Haikang’s official website can run in any mode of the dual-core browser, but the web3.0 development kit I downloaded cannot, and the Google kernel prompts that NAAPI is not supported.
Solution: Because of the webVideoCtrl.js version problem, format the code and pull it down to the bottom, and you will find that its version should be 1.0.9. What I downloaded is the development kit in Data Download ①, because 1.0.9 uses NAAPI, but this technology has been removed by most browsers due to security issues. So if you want to be compatible with dual modes, download the js file of ②, and replace the js file in the development kit.
2. Why the capture function and video recording function cannot be used, and the function always returns undefined.
Solution: Because the version of the WebComponentsKit.exe plug-in is too high. Maybe you have browsed the official web terminal, and the downloaded WebComponentsKit.exe must be the latest version, but the latest version of WebComponentsKit.exe is not compatible with 1.0.6 webVideoCtrl.js. After testing, I have downloaded [ 3.0.6.1 ] and [ 3.0.6.2 ] two versions. Only version 3.0.6.1 is compatible with webVideoCtrl.js of 1.0.6. If you have installed a new version of WebComponentsKit, please uninstall and install the old version. The WebComponentsKit in Data Download ① is 3.0.6.1. Therefore, during the development process, the code for plug-in version monitoring needs to be removed.
Updated: October 25, 2019 11:06:41
1.0.6 webvIdeoCtrl.js download address: http://119.23.216.213/file/webVideoCtrl.js
Here is a new version of the plug-in address --- the new version of the plug-in download address , this plug-in is compatible with IE, Firefox, Google, 360 mainstream browsers. During the testing process, the poster found that the reason why it is more compatible than the old version is because he uses websocket to fetch streams and session authentication in non-IE browsers . This enables plug-in-free development. But it is a pity that it has requirements for the model and version of the hard drive device. After contacting Hikvision Technology, Hikvision Technology said that this plug-in only supports a few hard drive devices at this stage. That is to say, basically most devices cannot use this new version of the plug-in. Communicate with technology as follows:
If you want to try, you can try it yourself. During the test, if you encounter the problem of prompting /ISAPI/Security/sessionLogin/ 404, the reason for this problem is that when the plug-in makes a request without a plug-in, it forcefully changes your request IP. The location is around line 220 of webVideoCtrl.js.
se = function (e) {
var t = location.hostname, n = location.port || "80";
return /^(http|https):\/\/([^\/]+)(.+)$/.test(e) && (e = e.replace(RegExp.$2, t + ":" + n)), f.cookie("webVideoCtrlProxy", RegExp.$2, {raw: !0}), e
// return e;
}That's the code above. You just need to set t and n to the IP and port you need to request.
------------------------------------------ Updated: May 14, 2020 10:33:57 ---------------------------------
Update the address of the shared file above, this address will be permanently valid: https://cloud.189.cn/t/JZ3yUv7BVzay