While reading the article library tour of Dart, I've just discovered that some libraries cannot be used in web apps and other libraries cannot be used or are not available for command-line apps, while all of these mentioned libraries belonging to the standard library.
For example, dart:io cannot be used for web apps, but only for command-line apps. Similarly, only web apps can use dart:html, but not command-line ones.
I understood that what dart:html offers is more suitable for writing web apps, but I don't understand why there's this restriction of not being able to use some of the services provided by dart:html in command-line apps.
Of course, these statements assume that when writing an application in Dart, we have to clearly differentiate between command-line and web apps. Is this true? If yes, are the restrictions above really strict or they are actually recommendations? If they are real restrictions, what was the purpose of designing Dart and its standard library in this way?
dart:html talks to a DOM. There is no DOM in a VM. Similarly, dart:io talks to the operating system in a manner that a browser cannot. (Your browser cannot launch processes, open files, or set up sockets other than AJAX and WebSockets.) The separation makes sense.
Related
I have written a UI in Electron and I would like to connect it with my C++ code. However, I will be selling this product and so I would like to know if this makes it easier for people to crack my C++ code? Obviously I know compiled C++ can be cracked anyway, but does this affect it in any way?
Additionally, what is the best way to go about this while preserving maximum possible security?
Thanks.
EDIT: How about this? Is it possible to use c++ as back-end for Electron.js?
EDIT2: To clarify, my Electron app will be showing the status of operations being performed in the C++ program. As such, I will need to send lists, dictionaries, strings etc. from C++ to JS which will then render it. Additionally, buttons on my Electron app need to trigger actions in the C++ code, such as stopping or starting certain parts of the program.
I have written a UI in Electron and I would like to connect it with my C++ code ...
I would like to know if this makes it easier for people to crack my C++ code?
Using electron does not make any meaningful difference for protecting the C++ source code. (Your intellectual property)
The Javascript code running in electron will be very easy to reverse engineer though, which gives users a head start on experimenting with your C++ binary. Using minification and obfuscation tools can at least make that harder.
For the C++ side, connecting C++ to Electron can be done in at least these two ways:
By dynamically linking to a shared library (Node.js C++ Addons)
In this case your C++ API would be functions that get exported by the shared library. There are many tools to inspect shared libraries (DLLs) and view these functions.
By communicating with another process using some sort of Inter-process communication.
In this case your API would depend on the IPC method used. If it was TCP/UDP messages you could use Wireshark to inspect the packets between the processes. There are ways to inspect messages going over any type of IPC.
Either way, your application must be delivered to the end-user with a compiled binary. Preventing reverse engineering of the binary itself is impossible if you actually give the binary to your users.
You should also expect that a savvy end-user will have access to other tools that can inspect the API and implement third-party code that talks to that API.
Additionally, what is the best way to go about this while preserving maximum possible security?
By "maximum possible security", I will assume you are referring to preventing unauthorized use of the C++ code with other applications.
You would need a licensing system that can authenticate the application that is using your C++ binary's API. Explaining what that would be exactly is probably too large of an answer for a Stack Overflow, and you will have to do some research on how licensing systems are implemented.
It may be theoretically impossible to develop a perfect licensing system though. Look at the gaming industry, it takes just a matter of days to for the licensing software become circumvented for every new game that is released. The only software architecture that cracks haven't completely conquered are cloud-based applications, which don't actually deliver compiled code with their business logic to the end-user's computer.
I am familiar with the Concept of amazon SWF . I can see many SDK in different languages to use SWF services. Also, amazon Flow Framework is a set of library to implement distributed applications . Currently this Flow Framework is available in Java and Ruby . Then how can we write distributed applications using SWF in other languages like python , php etc. Does this mean amazon provides the framework in Java and Ruby only , rest of the languages have other vendor's libraries ? Please explain .
You are right that AWS currently only provides high-level frameworks for Ruby and Java ("Flow" frameworks). Low-level access to SWF is available in most (all?) official SDKs though: boto2/3 for Python, go-sdk, etc.
When using SWF, you'll find yourself implementing mainly two types of programs: "activity workers" and "deciders" (http://docs.aws.amazon.com/amazonswf/latest/developerguide/swf-dev-actors.html).
Using the Flow framework is not mandatory, but it helps implementing deciders by providing high-level abstractions for describing synchronisation points, defining which tasks can be run in parallel, retries, etc. There are also non-official libraries (I'm personally maintaining one for my company, "simpleflow").
If you want to use other languages for deciders, I recommend you try to use an existing framework first, then see if you want to implement this yourself (it's not trivial from my experience).
If you want to implement activities in other languages, I recommend you start using the Flow framework end-to-end, and then you can either 1/ fork and use your favorite language as a subprocess of Ruby/Java Flow workers, or 2/ mimic the serialisation logic of the Flow framework and implement workers directly yourself with low-level APIs (which is simple: poll for an activity, do work, then respond to SWF with the result).
How does AppDynamics and similar problems retrieve data from apps ? I read somewhere here on SO that it is based on bytecode injection, but is there some official or reliable source to this information ?
Data retrieval by APM tools is done in several ways, each one with its pros and cons
Bytecode injection (for both Java and .NET) is one technique, which is somewhat intrusive but allows you to get data from places the application owner (or even 3rd party frameworks) did not intend to allow.
Native function interception is similar to bytecode injection, but allows you to intercept unmanaged code
Application plugins - some applications (e.g. Apache, IIS) give access to monitoring and application information via a well-documented APIs and plugin architecture
Network sniffing allows you to see all the communication to/from the monitored machine
OS specific un/documented APIs - just like application plugins, but for the Windows/*nix
Disclaimer : I work for Correlsense, provider of APM software SharePath, which uses all of the above methods to give you complete end-to-end transaction visibility.
Is there a way to prevent access to certain libraries in dart? The reason why is I want to allow a scripting language in my application. It looked like dart would make that easy, by just limiting what libraries one could import and defining my own libraries. Is this a viable option? For example, I would want to completely remove access to dart:html so that why the scripts can't mess with the DOM.
There was a discussion recently about this feature request https://code.google.com/p/dart/issues/detail?id=16373
This is for isolates spawned from Dart code.
I don't know about it when hosting Dart in your application.
See also this question Embedding Dart into application
I'm currently starting to integrate "Delphi Web Script" in my application basically only as a scripting engine (interfacing with functions, classes, etc.); awesome software for the standard delphi open source quality in my opinion, but just for curiosity,
What's exactly the "web part" of the project?
How is intended to be used?
It was used somewhere with some success commercially?
Thanks!
As ain said, the original use was for PHP-like, ASP-like server-side web-page generation, but it was also capable of general purpose use, which is what I used it for. And as I did not use the "web" side of DWScript, most of the "web-oriented" features haven't been ported over (only the HTML Filter was ported actually).
The Web functionality is still available in the SourceForge repository, if someone wants to tackle the port. Though, they may be outdated beyond simple renamed methods and classes, as since DWSII, the script engine has gained various features. For instance, it is now capable of multiple thread-safe executions of a single compiled script, while the old codebase is built around the limitation that a compiled script can be executed by only one thread at a time.
On the other hand, there are some new features that could simplify the porting, the simple WebServer demo recently added uses RTTI to expose TWebResponse & TWebRequest f.i. (was manually exposed in DWSII). On the down side, that's only possible with recent Delphi versions.
AFAIK the main focus of the original author of this scripting engine was to make it possible to embed Pascal scripts into HTML pages, just like ie PHP does it. Hence the name "Delphi Web Script". While the focus of the current maintainer, Eric Grange, is on using it as a general purpose scripting engine, it should still be possible to use it for web purposes as well - for that you use the "filters" feature of the library. Check out the dwsHtmlFilter unit for HTML filter.