We are using Sheetjs in Salesforce, and are planning to get the pro version. Before using this library in production I just wanted to know if there are any security vulnerabilities for this library in the past. And is there any potential data threat as a result of using this library?
I tried searching on the web for any vulnerabilities reported in the past, but did not get proper information i needed. Could someone tell me if you've faced any potential data issues/security issues of using this library with Salesforce LWC components. Does Salesforce scans/checks the libraries we use in the components while deploying?
Related
We are creating a Web component that will be available via a self-hosted CDN in Europe.
The idea is to make it as easy as possible for developers to integrate the Web component in a Website.
One of those ways is to publish it on npm.
The question now is:
Since the project underlies very strict Data privacy requirements:
Could one make the case that npm is unsafe from the perspective of data privacy?
In other words: Does the act of publishing an npm package cause a data privacy issue for the consuming developer or more specifically Enduser using the Webcomponent in the browser?
Of course, this question excludes issues with the Web Component itself, since they can cause an issue on their own. I am only interested in hosting a package on npm.
Upon some investigating: I am from Germany and data privacy and data protection seem to translate to the same word (Datenschutz). So in this question both is meant.
I would not use StackOverflow to seek advice on complying with data privacy laws or regulations. I am not a lawyer and I doubt very many people on here are. That said, there are some generalities that can be made that may or may not apply to your specific case. Again, I am not a lawyer, and this is not legal advice.
I'm not sure if you are talking about the public npm registry or a private one.
In terms of data privacy, publishing your code to the public npm registry isn't much different from publishing it to GitHub or to a blog. If the code, examples, documentation, and various configuration files do not contain sensitive data, publishing them to the public npm registry won't create issues. If one or more files that you publish do contain sensitive data, then publishing them to the npm registry will pose similar risks to posting them to GitHub or a blog.
If you are using a private npm registry, things might be a lot more complicated and I would not trust an answer on StackOverflow. Get your data security folks talking to your developers and the people who are doing the registry hosting.
My app was rejected due to this ,Please help me to resolve this .This issue is new to me .
Guideline 2.5.1 - Performance - Software Requirements
Your app uses or references the following non-public APIs:
"_IOObjectRelease, IOServiceGetMatchingService, IOServiceMatching
The use of non-public APIs is not permitted on the App Store because it can lead to a poor user experience should these APIs change. Continuing to use or conceal non-public APIs in future submissions of this app may result in the termination of your Apple Developer account, as well as removal of all associated apps from the App Store.
Next Steps
If you are using third-party libraries, please update to the most recent version of those libraries. If you do not have access to the libraries' source, you may be able to search the compiled binary using the "strings" or "otool" command line tools. The "strings" tool can output a list of the methods that the library calls and "otool -ov" will output the Objective-C class structures and their defined methods. These tools can help you narrow down where the problematic code resides. You could also use the "nm" tool to verify if any third-party libraries are calling these APIs.
Resources
For information on the "nm" tool, please review the "nm tool" Xcode manual page. If there are no alternatives for providing the functionality your app requires, you can file an enhancement request.
Thanks in Advance !!!
I'm searching for a well documented XACML3-Framework in the open source world. I tried AuthZForce and AT&T XACML. Both seems to have many features. The problem: to get them running, I have to read the source code or find test-classes. There are no examples or anything else, that helps to understand the functionality of the framework. I thought XACML is the future of authorization but at the bottom there is no real community.
Is there an XACML-alternative for ABAC-implementations or is there no other way and I must use RBAC with programmed constraints?
Regarding AuthzForce Core (Java library), you have a tutorial on the home page of the github project: Getting started; and an example of usage with a PEP in a real-world scenario. If you are missing info on something, feel free to contact us on our support mailing list. I also emphasize the fact that all Java classes have Javadoc and Javadoc artifacts are published on Maven Central with every release. You can download them manually or make sure your IDE is properly set up to automatically download them when you use Maven dependencies in your Java project.
WSO2 IS can help (opensource):
https://docs.wso2.com/display/IS510/XACML+Architecture
http://wso2.com/library/tutorials/2016/02/tutorial-how-to-enable-role-based-access-control-for-wso2-api-manager-using-xacml/
Policy handling can be done via web interface (Carbon).
As a jQuery user, I link the remote library from Google using
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
which is very clever because it's already loaded in the brower cache if the reader visited another site that did the same.
As I discover Phaser, I was hoping to see people on the web doing the same with
<script src="https://raw.githubusercontent.com/photonstorm/phaser/master/build/phaser.min.js"></script>
or any library hoster, but apparently no one does.
Is there a reason why Phaser users don't do that?
I would strongly advise against linking to the master release as it will absolutely break your games over time. Most of the 2.0.x updates have been non-API changing, but 2.1 and above will be altering some core aspects of Phaser. You should only ever link to specific versions.
For a similar service to the Google hosted APIs (of which they only host very specific libraries that they've selected) we use CDN.js, which offers the same thing. You can find details in the Phaser README or just go to http://cdnjs.com/ and search for Phaser.
There is as such no issue if you link to a specific version. But you don't want the latest build, as this can potentially break your site by making changes.
I don't know Github's policies on referencing their site like this.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We are planning to built cross platform desktop application. We found that Node-Webkit is a perfect choice for us. But GitHub developed their own framework called Electron instead of using Node-Webkit.
What is the difference between them?
Electron has a page explaining the differences with nwjs.
Like NW.js, Electron provides a platform to write desktop applications
with web technologies. Both platforms enable developers to utilize
HTML, JavaScript, and Node.js. On the surface, they seem very similar.
There are however fundamental differences between the two projects
that make Electron a completely separate product from NW.js.
Entry of Application In NW.js, the main entry point of an
application can be an HTML web page. In that case, NW.js will open the
given entry point in a browser window.
In Electron, the entry point is always a JavaScript script. Instead of
providing a URL directly, you manually create a browser window and
load an HTML file using the API. You also need to listen to window
events to decide when to quit the application.
Electron works more like the Node.js runtime. Electron's APIs are
lower level so you can use it for browser testing in place of
PhantomJS.
Node Integration In NW.js, the Node integration in web pages
requires patching Chromium to work, while in Electron we chose a
different way to integrate the libuv loop with each platform's message
loop to avoid hacking Chromium. See the node_bindings code for how
that was done.
JavaScript Contexts If you are an experienced NW.js user, you
should be familiar with the concept of Node context and web context.
These concepts were invented because of how NW.js was implemented.
By using the multi-context feature of Node, Electron doesn't introduce
a new JavaScript context in web pages.
Note: NW.js has optionally supported multi-context since 0.13.
Legacy Support NW.js still offers a "legacy release" that supports
Windows XP. It doesn't receive security updates.
Given that hardware manufacturers, Microsoft, Chromium, and Node.js
haven't released even critical security updates for that system, we
have to warn you that using Windows XP is wildly insecure and outright
irresponsible.
However, we understand that requirements outside our wildest
imagination may exist, so if you're looking for something like
Electron that runs on Windows XP, the NW.js legacy release might be
the right fit for you.
Features There are numerous differences in the amount of supported
features. Electron has a bigger community, more production apps using
it, and a large amount of userland modules available on npm.
As an example, Electron has built-in support for automatic updates and
countless tools that make the creation of installers easier. As an
example in favor of NW.js, NW.js supports more Chrome.* APIs for the
development of Chrome Apps.
Naturally, we believe that Electron is the better platform for
polished production applications built with web technologies (like
Visual Studio Code, Slack, or Facebook Messenger); however, we want to
be fair to our web technology friends. If you have feature needs that
Electron does not meet, you might want to try NW.js.
Keep in mind this may be biased- it is from Electron's wiki page.
Electron doesn't introduce
a new JavaScript context in web pages.
Source code protection
Electron is packaging its applications with asar, which contains the applications' unprotected source code. This makes it possible for application 1 to extract application 2 and inject vulnerable scripts, without the user knowing it. You can checkout this project on GitHub to see an example of how to manipulate the Slack app for an example. As for now, the Electron team don't have any plans to implement support for source code protection.
NW.js has built in support for compiling your source code to protected binaries.