皮皮网

【免费安卓手机棋牌源码】【频率估计 源码 matlab】【寻模板整站源码】node 源码保护

时间:2024-12-26 03:30:37 来源:PHP驾校系统源码 作者:远程列表源码

1.抽丝剥茧:Electron与Node.js的源码奇葩Bug
2.Node.JS中调用JShaman,加密JS代码
3.node-http-proxy 源码解读
4.node-pre-gyp以及node-gyp的保护源码简单解析(以安装sqlite3为例)
5.nodejs原理&源码赏析(7)Node.js中的事件循环,定时器和process.nextTick
6.如何修改node_modules里的源码文件

node 源码保护

抽丝剥茧:Electron与Node.js的奇葩Bug

       起因是最近在用Electron开发一个桌面端项目,有个需求是保护需要遍历某个文件夹下的所有JavaScript文件,对它进行AST词法语法分析,源码解析出元数据并写入到某个文件里。保护免费安卓手机棋牌源码需求整体不复杂,源码只是保护细节有些麻烦,当我以为开发的源码差不多时,注意到一个匪夷所思的保护问题,查的源码我快怀疑人生。

       缘起

       什么问题呢?

       原来这个需求一开始仅是保护遍历当前文件夹下的文件,我的源码获取所有JS文件的代码是这样的:

       后来需求改为要包含文件夹的子文件夹,那就需要进行递归遍历。保护按照我以前的源码做法,当然是手撸一个递归,代码并不复杂,缺点是递归可能会导致堆栈溢出:

       但做为一个紧跟时代浪潮的开发者,我知道Node.js的fs.readdir API中加了一个参数recursive,表示可以进行递归,人家代码的鲁棒性肯定比我的好多了:

       只改了一行代码,美滋滋~

       兼容性怎么样呢?我们到Node.js的API文档里看下:

       是从v..0添加的,而我本地使用的Node.js版本正是这个(好巧),我们Electron中的Node.js版本是多少呢?先看到electron的版本是.0.4:

       在Electron的 发布页上能找到这个版本对应的是..1,比我本地的还要多一个小版本号:

       这里需要说明一下,Electron之所以优于WebView方案,是因为它内置了Chrome浏览器和Node.js,锁定了前端与后端的版本号,这样只要Chrome和Node.js本身的跨平台没有问题,理论上Electron在各个平台上都能获得统一的UI与功能体验。 而以Tauri为代表的WebView方案,则是不内置浏览器,应用程序使用宿主机的浏览器内核,开发包的体积大大减小,比如我做过的同样功能的一个项目,Electron版本有M+,而Tauri的只有4M左右。虽然体积可以这么小,又有Rust这个性能大杀器,频率估计 源码 matlab但在实际工作中的技术选型上,想想各种浏览器与不同版本的兼容性,换我也不敢头铁地用啊! 所以,尽管Electron有这样那样的缺点,仍是我们开发客户端的不二之选。 之所以提这个,是因为读者朋友需要明白实际项目运行的是Electron内部的Node.js,而我们本机的Node.js只负责启动Electron这个工程。

       以上只是为了说明,我这里使用fs.readdir这个API新特性是没有问题的。

       排查

       为方便排查,我将代码再度简化,提取一个单独的文件中,被Electron的Node.js端引用:

       能看到控制台打印的 Node.js 版本与我们刚才查到的是一样的,文件数量为2:

       同样的代码使用本机的Node.js执行:

       难道是这个小版本的锅?按理说不应该。但为了排除干扰,我将本机的Node.js也升级为..1:

       这下就有些懵逼了!

       追踪

       目前来看,锅应该是Electron的。那么第一思路是什么?是不是人家已经解决了啊?我要不要先升个级?

       没毛病。

       升级Electron

       将Electron的版本号换成最新版本v.1.0:

       再看效果:

       我去,正常了!

       不过,这个包的升级不能太草率,尤其正值发版前夕,所以还是先改代码吧,除了我上面手撸的代码外,还有个包readdirp也可以做同样的事情:

       这两种方式,在原版本的Electron下都没有问题。

       GitHub上搜索

       下来接着排查。

       Electron是不是有人发现了这个Bug,才进行的修复呢?

       去 GitHub issue里瞅一瞅:

       没有,已经关闭的问题都是年提的问题,而我们使用的Electron的版本是年月日发布的。 那么就去 代码提交记录里查下(GitHub这个功能还是很好用的):

       符合条件的就一条,打开看下:

       修复的这个瞅着跟我们的递归没有什么关系嘛。

       等等,寻模板整站源码这个文件是什么鬼?

       心血来潮的收获

       我们找到这个文件,目录在lib下:

       从命名上看,这个文件是对Node.js的fs模块的一个包装。如果你对Electron有了解的话,仔细一思索,就能理解为什么会有这么个文件了。我们开发时,项目里会有许多的资源,Electron的Node.js端读取内置的文件,与正常Node.js无异,但事实上,当我们的项目打包为APP后,文件的路径与开发状态下完全不一样了。所以Electron针对打包后的文件处理,重写了fs的各个方法。

       这段代码中重写readdir的部分如下:

       上面的判断isAsar就是判断是否打包后的归档文件,来判断是否要经Electron特殊处理。如果要处理的话,会调用Electron内部的C++代码方法进行处理。

       我发现,这里Electron并没有对打包后的归档文件处理递归参数recursive,岂不是又一个Bug?应该提个issue提醒下。

       不过,我们目前的问题,并不是它造成的,因为现在是开发状态下,上面代码可以简化为:

       对Promise了如指掌的我怎么看这代码也不会有问题,只是心血来潮执行了一下:

       我去,差点儿脑溢血!

       好的一点是,曙光似乎就在眼前了!事实证明,心血来潮是有用的!

       Node.js的源码

       这时不能慌,本地切换Node.js版本为v,同样的代码再执行下:

       这说明Electron是被冤枉的,锅还是Node.js的!

       Node.js你这个浓眉大眼的cp源码是什么,居然也有Bug!呃,还偷偷修复了!

       上面的情况,其实是说原生的fs.readdir有问题:

       也就是说,fs.promises.readdir并不是用util.promisify(fs.readdir)实现的!

       换成同步的代码readdirSync,效果也是一样:

       我们来到Node.js的GitHub地址,进行 搜索:

       打开这两个文件,能发现,二者确实是不同的实现,不是简单地使用util.promisify进行转换。

       fs.js

       我们先看 lib/fs.js。

       当recursive为true时,调用了一个readdirSyncRecursive函数,从这个命名上似乎可以看出有性能上的隐患。正常来说,这个函数是异步的,不应该调用同步的方法,如果文件数量过多,会把主进程占用,影响性能。

       如果没有recursive,则是原来的代码,我们看到binding readdir这个函数,凡是binding的代码,应该就是调用了C++的底层库,进行了一次『过桥』交互。

       我们接着看readdirSyncRecursive,它的命名果然没有毛病,binding readdir没有第4个参数,是完全同步的,这个风险是显而易见的:

       fs/promises.js

       在lib/internal/fs/promises.js中,我们看到binding readdir的第4个参数是kUsePromises,表明是个异步的处理。

       当传递了recursive参数时,将调用readdirRecursive,而readdirRecursive的测试 小程序 源码代码与readdirSyncRecursive的大同小异,有兴趣的可以读一读:

       fs.js的提交记录

       我们搜索readdir的提交记录,能发现这两篇都与深度遍历有关:

       其中 下面的这个,正是我们这次问题的罪魁祸首。

       刚才看到的fs.js中的readdirSyncRecursive里这段长长的注释,正是这次提交里添加的:

       从代码对比上,我们就能看出为什么我们的代码遍历的程序为2了,因为readdirResult是个二维数组,它的长度就是2啊。取它的第一个元素的长度才是正解。坑爹!

       也就是说,如果不使用withFileTypes这个参数,得到的结果是没有问题的:

       发版记录

       我们在Node.js的发版记录中,找到这条提交记录,也就是说,v..0才修复这个问题。

       而Electron只有Node.js更新到v后,这个功能才修复。

       而从Electron与Node.js的版本对应上来看,得更新到v了。

       只是需要注意的是,像前文提过的,如果是遍历的是当前项目的内置文件,Electron并没有支持这个新的参数,在打包后会出现Bug。

       fs的同步阻塞

       其实有人提过一个 issue:

       确实是个风险点。所以,建议Node.js开发者老老实实使用fs/promises代替fs,而Electron用户由于坑爹的fs包裹,还是不要用这个特性了。

       总结

       本次问题的起因是我的一个Electron项目,使用了一个Node.js fs API的一个新参数recursive递归遍历文件夹,偶然间发现返回的文件数量不对,就开始排查问题。

       首先,我选择了升级Electron的包版本,发现从v.0.4升级到最新版本v.1.0后,问题解决了。但由于发版在即,不能冒然升级这么大件的东西,所以先使用readdirp这个第三方包处理。

       接着排查问题出现的原因。我到Electron的GitHub上搜索issue,只找到一条近期的提交,但看提交信息,不像是我们的目标。我注意到这条提交的修改文件(asar-fs-wrapper.ts),是Electron针对Node.js的fs API的包装,意识到这是Electron为了解决打包前后内置文件路径的问题,心血来潮之下,将其中核心代码简化后,测试发现问题出在fs.promises readdir的重写上,继而锁定了Node.js版本v..1的fs.readdir有Bug。

       下一步,继续看Node.js的源码,确定了fs.promises与fs是两套不同的实现,不是简单地使用util.promisify进行转换。并在fs的代码找到关于recursive递归的核心代码readdirSyncRecursive。又在提交记录里,找到这段代码的修复记录。仔细阅读代码对比后,找到了返回数量为2的真正原因。

       我们在Node.js的发版记录中,找到了这条记录的信息,确定了v..0才修复这个问题。而内嵌Node.js的Electron,只有v版本起才修复。

       不过需要注意的是,如果是遍历的是当前项目的内置文件,由于Electron并没有支持这个新的参数,在打包后会出现Bug。而且由于fs.readdir使用recursive时是同步的,Electron重写的fs.promises readdir最终调用的是它,可能会有隐性的性能风险。

       本次定位问题走了些弯路,一开始将目标锁定到Electron上,主要是它重写fs的锅,如果我在代码中用的fs.readdirSync,那么可能会更早在Node.js上查起。谁能想到我调用的fs.promises readdir不是真正的fs.promises readdir呢?

       最后,针对此次问题,我们有以下启示:

       PS:我给Electron提了个 issue,一是让他们给fs.readdir添加recursive参数的实现,二是让他们注意下重写时fs.promises readdir的性能风险。

Node.JS中调用JShaman,加密JS代码

       在Node.js开发环境中,JShaman的Web API接口被用来实现JS代码的混淆加密处理,以增强代码的保护性。其目标在于提升代码安全性,以下是几个关键原因:

       避免代码被盗用:混淆加密有助于防止他人直接复制和粘贴你的代码,对于全客户端项目,如HTML5游戏,这一点尤为重要。

       简化代码结构:去除不必要的注释和空白,使代码加载更快,理解难度增加,不易被轻易解读。

       保护未付款项目:即使在展示工作给客户时,也能确保他们无法获取源代码,直到付款确认。

       在本示例中,我们利用的是JShaman的英文版接口,它作为国内知名JS代码保护服务供应商,其英文版与中文版在功能设置上有所差异。具体的功能配置对比和详细信息,建议直接访问JShaman的官方网站获取官方指导。

node-mon.setupOutgoing的实现;其次,stream的实现;最后,查看源码了解web-outgoing模块对代理响应的处理。setRedirectHostRewrite函数的代码实现也在这里。

       在websocket请求中,this.wsPasses任务队列包含四种处理函数:checkMethodAndHeader, XHeaders, stream。stream函数的处理流程同上。

       http-proxy-middleware和nokit-filter-proxy库都使用了node-http-proxy来实现服务器代理功能。http-proxy-middleware库的源码解读可以参考相关文章。nokit-filter-proxy库用于为nokit服务器添加代理功能,它是通过绑定onRequest事件函数来实现请求的拦截和转发的。

       这两篇文章都是在作者整理完proxy设计模式后整理的。由于作者水平有限,文章中可能存在错误或不足之处,欢迎读者批评指正。

node-pre-gyp以及node-gyp的源码简单解析(以安装sqlite3为例)

       在Node.js开发中,确保模块跨平台性至关重要,尤其当涉及到使用C/C++原生代码的模块,如SQLite3。让我们通过一个实例来理解安装这种原生模块的过程,以SQLite3为例。

       项目初始化

       首先,创建一个基础的Node.js项目,我们开始安装SQLite3。

       安装SQLite3

       执行安装命令后,你会看到命令行输出关键信息:

       node-pre-gyp的引入

       在安装过程中,你会遇到node-pre-gyp,这个工具与node-gyp和gyp紧密相关。gyp是一个用于生成项目文件的构建工具,它为Chromium项目生成IDE项目文件,如Visual Studio和Xcode。而node-gyp则是专为Node.js Addons(原生模块)编译设计的,它允许在本地编译C/C++代码。

       node-pre-gyp的作用

       为了简化每次安装时的平台编译工作,node-pre-gyp允许预先为常见平台生成二进制文件。当项目尝试安装时,它会优先查找预编译的二进制包,如果找不到,才会转而依赖node-gyp进行源码编译。

       安装流程

       当我们使用`npm install sqlite3`时,实际上执行了`node-pre-gyp install --fallback-to-build`。安装流程包括:

       检查node-pre-gyp是否已安装,如果没有,npm会自动安装。

       node-pre-gyp查找预编译二进制包,如果存在,则直接使用。

       如果没有找到,使用node-gyp进行源码编译。

       深入了解SQLite3安装

       查看sqlite3的package.json,`scripts`部分包含了`node-pre-gyp install`命令。npm会根据这个脚本执行安装过程。

       源码编译与node-gyp

       node-gyp的`build.js`负责执行编译任务,通过`gyp`工具生成特定平台的项目文件,如Windows的vcxproj,然后使用MSBuild编译。

       node-pre-gyp与node-gyp的交互

       node-pre-gyp的`do_build`模块调用node-gyp build,执行具体的编译操作,确保模块能在目标平台上正确工作。

nodejs原理&源码赏析(7)Node.js中的事件循环,定时器和process.nextTick

       事件循环是Node.js的核心机制,确保了其非阻塞I/O模型的实现。尽管JavaScript在Node.js中是单线程运行的,它却能利用系统内核的多线程特性处理并发任务。Node.js在开始执行时初始化事件循环,处理脚本文件或REPL环境中的异步调用。事件循环通过检查异步I/O、定时器和process.nextTick调用,然后进入各个阶段,处理回调函数。每个阶段维护一个先进先出的回调队列,处理与阶段相关操作后执行队列中的回调,直至队列为空或达到最大函数执行数量。系统操作回调、定时器和处理关闭回调的阶段各有功能。setImmediate()与setTimeout()相似,但执行顺序受调用上下文影响,setImmediate()在I/O周期中通常优先执行。process.nextTick()则在当前操作执行后立即执行回调,不受事件循环阶段限制,但需谨慎使用以防阻塞事件循环。

如何修改node_modules里的文件

       在项目开发过程中,有时我们发现从npm安装的某个包存在bug,需要对源码进行修改以解决特定问题。直接在本地项目中的node_modules目录下修改源码通常不可行,因为更新依赖时这部分修改会丢失。解决此问题有两种常用方法:

       方法一:使用webpack alias来覆盖源码路径。首先,找到需要修改的模块代码,并将其复制到项目中。接下来,修改代码中的引用路径,使用webpack alias将它们替换为指向自定义文件的路径。配置webpack alias后,通过修改这些别名,可以实现对源码的间接覆盖,无需每次都手动更新代码。打包后的项目仍然可以正常运行。

       方法二:使用patch-package工具。通过安装patch-package,我们可以在项目postinstall阶段自动更新特定包的源码,避免每次手动修改。配置package.json文件,添加postinstall脚本执行自动覆盖命令。执行此命令后,修改的文件会被保存到patches目录,以便在包更新时自动应用修改。这种做法更加自动化,且不影响依赖包的正常更新。

       在应用这些方法时,需注意它们的局限性,如依赖于特定的开发环境和工具支持。尽管如此,它们提供了灵活的解决方案,允许我们在不破坏项目依赖的情况下进行源码修改。探索和使用这些工具,可以提高开发效率,解决特定问题。欢迎指出任何疑问或错误,共同进步。

关键词:在线打包源码

copyright © 2016 powered by 皮皮网   sitemap