Discover Top Posts Tagged with #jsdom

Popular Recent

Do you ask yourself if there is a better testing framework for your Angular applications? Use Angular with Jest and make your tests simpler and faster!

Do you ask yourself if there is a better testing framework for your Angular applications? Use Angular with Jest and make your tests simpler and faster! In this post we migrate an example project and discuss the main advantages I found.

#angular #jest #unit test #jsdom #snapshot testing

Arbitrary File Read in Mailtrain by RTFM

A while ago I reported some security issues in Mailtrain, an open source self hosted newsletter app running on Node.js. This is a very brief write-up on one of the issues I found, which highlights why it’s important as a developer to understand how third-party libraries used by your application actually works.

Jsdom and the jsdom.env API

Mailtrain supports sending HTML email and allows administrators to create their own HTML templates. To implement this functionality, the application uses Jsdom and the jsdom.env API. Jsdom is a JavaScript implementation of the WHATWG DOM and HTML standards, for use with Node.js. The jsdom.env API is jsdom’s “easy mode” which is described like this in its GitHub readme:

“jsdom.env is an API that allows you to throw a bunch of stuff at it, and it will generally do the right thing.”

Calling jsdom.env flexible is something of an understatement, as its whole purpose is that you can just pass something to it and it will automatically detect what it is and then perform its magic accordingly.

When editing a campaign HTML template in Mailtrain, the content of the template is passed to the system in a parameter called html. This content is then passed to the prepareHtml() function of the application, which in turn passes it to jsdom.env.

This got me interested as I hoped to be able to get the application to execute the injected HTML and JavaScript on the server-side. Unfortunately this was not possible, although stored XSS was trivial as there are no restrictions on the input. As admin is the only role available within the application, this was not terribly exciting as it would basically just amount to self-XSS. However, in the description above it also states that URLs and file names can be used.

Unintended functionality

As it turns out, simply passing a URL or a path to a file in the html parameter will cause the server to make a request to a server or read a file on the file system, and then store the result within the database. The database entry will then be read and used as a template when the campaign email is sent out, resulting in SSRF or arbitrary file read from the server.

This was obviously something the Mailtrain developers had not considered, and the issue has been fixed so that the input is now checked before being passed to jsdom.env.

Exploitability

As previously mentioned, the only available role in Mailtrain is admin and only admins can create and update campaigns. There is however (at least) one stored XSS that is exploitable by an unauthenticated user and which could be leveraged to make the admin perform the necessary actions on behalf of the attacker. But that is another story.

#mailtrain #jsdom #security #node.js

[nodejs][jsdom]Get JSON Japan Pref info from Wikipedia table

nodejs上でjsdomをつかってWikipediaをスクレイピングして、都道府県別の統計データをJSONで出力するスクリプト。

#javascript #programming #nodejs #jsdom

React component unit testing using shallow rendering

React 0.14 release introduced shallow rendering which is a great for unit testing a React component. Prior to shallow rendering, unit testing React components on nodejs server involved using jsdom to create a mock dom so that React can render a component into the dom. Test utils provides methods to do this, and there are some great blog posts on this. - http://reactjsnews.com/testing-in-react/

Example unit test case when jsdom is present -

let component = TestUtils.renderIntoDocument(<NavBar/>); let links = TestUtils.scryRenderedDOMComponentsWithTag(component, 'li'); expect(links.length).to.equal(2);

But advantage of shallow rendering is it does not require a DOM and child components are not rendered. They exist in vdom by their name and we can examine their properties. This implicit mocking of child components gives ability to do true unit testing a component.

Same test case above using shallow rendering

let renderer = TestUtils.createRenderer(); renderer.render(<NavBar/>); let result = renderer.getRenderOutput(); expect(result.props.children.length).to.equal(2);

With shallow rendering we are dealing with pure js objects. But it is a bit verbose and Facebook hasn't released nice API's around shallow rendering. Their documentation says it's an experimental feature. There are couple of libraries which are trying to fill in this gap. And the one I love is skin-deep

With skin-deep the above code block becomes

let tree = sd.shallowRender(<NavBar />); let links = tree.everySubTree('li'); expect(links.length).to.equal(2);

which is a lot nicer abstraction. skin-deep also provides api's to test the React component instance directly, which gives us capability to unit test Component methods. Also shallow rendering is not tied to any particular testing framework. (unlike another TestUtils API mockComponent() which needs jest). All this works nicely with my unit test setup which includes mocha, chai and sinon

#react #unit testing #jsdom #skin-deep

JSDOM, A Test Harness

Over the last few days, I've made a few mistakes and been reminded not to reinvent the wheel.

I thought that bootstrapping a DOM would be simple, despite explicit warnings. I also didn't search hard enough for a pre-built solution, or a starting point at least.

I've found some interesting stuff now though:

https://github.com/ember-backstop-book/EmberTrackr https://github.com/fuseelements/ember-brunch-skeleton http://brunch.io/

Now, a quick lunch and then back to work.

#jsdom #tdd #bdd

#cheerio #jsdom #javascript #js #scrapper

续： jsdom 内存使用的实验

前文：jsdom 内存使用的实验

在发现了上文中描述的 jsdom + jQuery 的内存泄露后，周日对 HackBack 项目的 crawler 部分进行了重写。既然 jQuery 不能用，那就只好用 DOM 访问了。好在 HackerNews 的页面结构不算太复杂，基本代码量没有变化。

近两天下来，结果是这样的。

» vmc stats hackback +----------+-------------+----------------+--------------+----------------+ | Instance | CPU (Cores) | Memory (limit) | Disk (limit) | Uptime | +----------+-------------+----------------+--------------+----------------+ | 0 | 0.6% (4) | 24.6M (512M) | 12.4M (2G) | 1d:19h:58m:34s | +----------+-------------+----------------+--------------+----------------+

app 启动时的内存占用是 20.0M，显然还是存在轻微的内存泄露，不过按照目前这种泄露的速度，512M 的上限可以坚持很久。与其刨根问底，我选择去做一些更有创造性的东西。let it go ^_^

#node.js #jsdom #jquery #memory leak #hackback

jsdom 内存使用的实验

之前做的去 HackerNews 的书签 HackBack 运行在 VMWare 的 PaaS 服务 CloudFoundry.com 上，其中获取 HackerNews 的内容的部分是用 jsdom 写的一个爬虫。一切工作的非常完美，速度也很棒。但这个程序有一个致命的问题：隔三差五这个整个 webapp 就会完全无法使用。在尝试了各种可能性之后，终于找到了幕后的黑手（之一？）

这是一段测试代码：

跑下来的结果是，

node test.js - 内存最大使用 55MB，之后 gc 到 17MB

node test.js with_jquery - 内存最大使用 240MB，无法 gc

那怪每次看 HackBack 的系统在线时间都只有短短的几小时了，想必 CloudFoundry 已经自动重启程序 n 次才让 HackBack 有了目前 1－2 天左右的在线时间。再之后可能自动重启次数过多，HackBack 就 404 了。

解决方法还在摸索中。。。

#jsdom #node.js