window is not defined (adyen.encrypt.nodom.js:130) about adyen-cse-web HOT 12 CLOSED

As is, this package is challenging to integrate into any universal app. Unguarded access of properties of document, window, and navigator require those objects to be shimmed under test at the very least. We're just starting integration with our universal app now and this is a bit of a speed bump for us in leveraging this library.

I would highly recommend publishing the package with universal support, ideally offering a version that doesn't already include browser polyfills for when a consumer already has polyfills set up.

from adyen-cse-web.

It's really useful to be able to load this library under node.js for unit testing purposes. A simple workaround is to add empty window and navigator objects to node's global object.

global.window = {}
global.navigator = {}

from adyen-cse-web.

For testing reasons I expected to be able to create a token via the terminal. I thought because there's NPM support that it would work with node. I understand this dependency on window because you shouldn't be creating these tokens on the server anyway.

from adyen-cse-web.

Hi reggi,

We are doing our best to make the nodom variation not fail in the absense of window or document. I'll try if there are some fixes I can make when we are adding new functionality to the library.

• Arnoud

from adyen-cse-web.

I found this version that works on node, It would be nice if you guys had a supported version.

https://www.npmjs.com/package/adyen-encryption

from adyen-cse-web.

The adyen library is (and will not) intended to be running on Node JS. The only thing we should be taking care of is a context in which you load the library while window and document might be re-assigned.

If you run the library from NodeJS, that would require card details to be allowed to reach your NodeJS server, which would be a violation of PCI.

So the only scenario in which the library needs to run from NodeJS is a testing scenario, in which case I would argue it should be fairly viable to mock the window and document object, to "exist".

from adyen-cse-web.

I'm experiencing something similar, when bundling my project through Webpack. If i'm importing adyen-cse-js in the top of my file, i get this error:

ReferenceError: navigator is not defined  at <project-path>/node_modules/adyen-cse-js/js/adyen.encrypt.nodom.js:139:840

I realize it's not the exact same as the issue creator experienced, but my debugging shows that this issue is also related to the time of compilation. If i start a --watch process of Webpack and then import the module at the of my file, it works fine (because navigator is defined at that point, i assume), and also if fetch the module through a require-statement, and hence is able to move the require until it's actually needed (my project is based on React, so i moved the require statement to my form submission function).

I'm not sure if the above belong in a separate issue, but since both relates to handling undefined objects (window, navigator) in compilation, i figured this might be the place? If not, please let me know, and i'll submit my own issue.

from adyen-cse-web.

Technically the code should be safeguarded against any undefined property so I will look into this eventually.
However nodom does not mean no browser. It only means that this package is setup for when you maintain a custom UI and want to have a smaller library which does not include all of Adyen's UI logic.

from adyen-cse-web.

Yes i'm perfectly aware, that nodom and no browser isn't the same, and that the library isn't meant for server side use. But for instance in my use case, i'm using the library client side (as part of a React Component), but import statements from ES6 syntax must be at the top of your document, which leads to the error, as navigator is undefined at the time Webpack and Babel reaches the dependency.
So basically - i totally agree with your proposal, that any undefined property should be safeguarded, to get rid of bugs in common transpilling tasks. But achieving actual node js support isn't really a goal/use case for the library

Anyway, thanks for paying attention to this. In the meantime i'll suffice by invoking the library via require statement at a time where navigator is not undefined. Have a nice day :-)

from adyen-cse-web.

Also consider that it might make sense to load the library only on demand as probably payments happen on a low percentage of user flows. There is no need to overload visitors with 50kb of encryption logic they will use rarely. However that statement includes quite few assumptions that might not be true.

from adyen-cse-web.

Same problem here..
navigator is part of the dom. https://developer.mozilla.org/en-US/docs/Web/API/Navigator

"However that statement includes quite few assumptions that might not be true." #AlternativeFacts?

from adyen-cse-web.

@gilbarbara "#AlternativeFacts?" Nope.

The assumption I made is that payments is an important but not frequently (< once a week) happening shopper flow. This will not be the case for every merchant.

In the context of CSE no dom means that we allow the merchant to build their own UI and not hard bind to input elements or events happening in the browser from the library itself. We still assume a browser context, as there is no integration I can think of (no PCI compliant one) in which this CSE implementation is used without a browser.

So we can argue that we should not related to anything a browser context supplies. But know that one real business issue with the current nodom implementation already is that as a merchant you won't get device finger printing out of the box any more, unless you do an add on custom integration. From a fraud perspective this reduces the tools to prevent fraud. So naturally business asks how to add finger printing. So this results in developers and business ask for a "no dom CSE, which can still do device fingerprinting".

I am not sure how we can fix this library to suit both needs. Don't use navigator and window because then it will compile with webpack, but prevent less fraud. Or have more difficulties with web pack, and/or having merchant developers been forced to use lazy loading, but prevent more fraud.

Personally I am seeking to actually re-adding the device fingerprinting to no-dom in upcoming releases.

However knowing this issue is also still happening it will be tricky to make this work.

If you have suggestions, please let me know.

from adyen-cse-web.