I'm working on an app written in Codename One together with the parse4cn1 library, the combination of which is a real pleasure to use. However, I need support for a few things in parse4cn1 that are not implemented, most importantly ACL and was wondering if Chidiebere has any hints on how to do this (e.g. how did you implement parse4cn1 yourself - from scratch or copying the open source Parse SDK for Android)? If I manage to do something of a decent quality I will try to share back. Thanks in advance
I never got around implementing ACLs (it's still on the TODO list). parse4cn1's interface closes resembles the Parse Android SDK interface and I'll like it to stay that way for convenience. In this case, the interface of interest would be the ParseACL which is documented here.
The actual implementation will need to be done via REST API calls.
Things to bear in mind:
We use the Android SDK API simply for defining methods and signatures for the corresponding class in ParseACL but do not use the SDKs for anything can be be done via REST.
By design, any calls requiring the master key will not be supported in parse4cn1 due to security considerations. If really needed, the functionality should be exposed via server-side cloud code.
Pull requests without unit tests for the added functionality or breaking existing tests will be rejected.
See also the Contributions section of the parse4cn1 github repo.
Good luck with your implementation and I hope to see a PR from you soon ;)
It was implemented from a Java port on top of the REST API's here but was later modified to use the SDK's to allow things like push (which are now no longer relevant).
In the past I just contributed pull a request to the project to get the fixes/features I needed. It was really easy to work with and compile.
Related
In a nutshell, my project consists of:
A secure RESTful API web service (hosted on Heroku), handling requests/responses for a database. It accepts & returns JSON data
A Unity desktop application, which doubles as a Twitch API chat bot, and communicates with the webservice to update the state of the game, as well as the state of the database.
IMPORTANT: This game is meant to be run by Twitch streamers, and played by users in Twitch chat
So my question is... Even though my web service is secure, what can I do to ensure that someone won't simply reverse engineer my Unity application to figure out how to properly communicate with my web server?
Encrypted HTTP traffic stops packet sniffing, but is a moot service if you can still use the same methods the application uses to interact with the data. Perhaps I'm being too paranoid, but there are plenty of tools out there that specifically target Unity & C# projects, so it really wouldn't take much effort.
One idea I had was to use the Twitch API to check if the user is actively streaming the game, and only allow them to start the game if the web service can't find a duplicate IP address in the database with an "isStreaming" flag set. This works in theory... but in practice, anyone can set up a fake Twitch account and a fake or "blank" stream on their machine, and then run some reverse-engineered code from the game.
Is there anything else I could do to minimize a hacker's ability to interact with my database?
The Simple Answer
Unity-compatible Code Obfuscation
Thanks to Unity's plugin system, there are actually some decent options for this. Some are paid options that exist in the Asset Store, as well as some 3rd party paid/free options that are simply unrelated to Unity (but could still work). Some of the free options, such as ConfuserEx, are also open source, allowing you to make custom code changes to how your work can be obfuscated.
The More Complex Answer
I made a simple C# Class Library and filled it with some pointless functionality (for testing)
I compiled a release build of the library
I obfuscated it through ConfuserEx using Aggressive settings (Maximum settings had Unity spitting out Invalid IL code errors)
I added an Assets/Plugins folder to my Unity project, and placed the compiled library there
I created a new C# script to test the library from within Unity
... And although the decompiled code was unintelligible, it still worked as expected within Unity. I used an IL/C# decompiler tool (such as JustDecompile) to compare the differences between the obfuscated binary and the original binary.
So if I really wanted to, I could follow these very same steps for all of my important bits of code (or even for the majority of my client project), as well as implementing any aforementioned security measures... And so hopefully, it's now going to be too much of a chore for anyone to understand the inner-workings of my project.
I was starting to write a multi-Map JS library, but I see that Mapstraction does that exactly..
I really would like to use Maptraction but it looks a little old (The commit's on GITHUB) (Not a issue if it is still "supported"), also The tutorial page, the Maps do not show up in my browsers.
Any input is highly appreciated.
Thanks
Kim
Depends what your use case is - if you don't want to be tied in to any one map provider and only need standard features then, yes.
Version 2.1 of Mapstraction is currently being prepared (on the release-2.1 branch) which brings some improvements in behavioural consistency across the providers.
Because of the nature of the library development isn't continuous and tends to be reactive to changes in the underlying providers or issues being raised. That said the community is fairly active and you can sign up to the mailing list via the site.
I'm working on a very simple web app, written in Go language.
I have a standalone version and now port it to GAE. It seems like there is very small changes, mainly concerning datastore API (in the standalone version I need just files).
I also need to include appengine packages and use init() instead of main().
Is there any simple way to merge both versions? As there is no preprocessor in Go, it seems like I must write a GAE-compatible API for the standalone version and use this mock module for standalone build and use real API for GAE version. But it sounds like an overkill to me.
Another problem is that GAE might be using older Go version (e.g. now recent Go release uses new template package, but GAE uses older one, and they are incompatible). So, is there any change to handle such differences at build time or on runtime?
Thanks,
Serge
UPD: Now GAE uses the same Go version (r60), as the stable standalone compiler, so the abstraction level is really simple now.
In broad terms, use abstraction. Provide interfaces for persistence, and write two implementations for that, one based on the datastore, and one based on local files. Then, write a separate main/init module for each platform, which instantiates the appropriate persistence interface, and passes it to your main application to use.
My immediate answer would be (if you want to maintain both GAE and non-GAE versions) that you use a reliable VCS which is good at merging (probably git or hg), and maintain separate branches for each version. The GAE API fits in reasonably well with Go, so there shouldn't be too many changes.
As for the issue of different versions, you should probably maintain code in the GAE version and use gofix (which is unfortunately one-way) to make a release-compatible version. The only place where this is likely to cause trouble is if you use the template package, which is in the process of being deprecated; if necessary you could include the new template package in your GAE bundle.
If you end up with GAE code which you don't want to run on Google's servers, you can also look into AppScale.
I'm evaluating Backbone.js for keeping data and UI synchronized in my web app. However, much of Backbone's value seems to lie in its use of RESTful interfaces. Though I may add server-side backup in the future, my primary use case involves storing all data offline using HTML5 local storage.
Is Backbone overkill for such a use case? If so, is there a better solution, focused solely on updating UI when data changes, and vice versa? (I'm also looking into Knockout and Javascript MVC.)
EDIT: I'm also now looking into Angular.js and jQuery Data Link.
Backbone.js works just as well with local storage as it does with RESTful queries.
I'm a learn-by-example kind of guy so here are some links to get you started:
Todos, a todo application
that uses local storage and
backbone.js, check out the annotated
source to see how it works.
The localStorage adapter is
all you need to get started, take a
look at the annotated source of
that too.
In the past weeks I have evaluated different solution for a scenario close to yours; being a project done in my personal free time and not being a good Javascript programmer, all I needed was something easy to learn to avoid starting from scratch.
Not surprisingly, I had the same candidate: Backbone.js, Javascript MVC and Knockout.js.
Backbone.js won:
I wasn't be required to follow conventions or replace what was already in place
I've easly hacked in its codebase to understand what wasn't clear from the documentation
I've successfully ignored a large amount of its features that was not interesting for me
It gave acceptable performance on busy pages
It works
Backbone.js is lightweight and relatively magic-free; you will probably use a small subset of its feature but it provieds a solid base to develop your solution.
I know it's been a while but you may want to check out backbone-offline project on github: https://github.com/Ask11/backbone.offline
You can also take a look at AFrameJS. I have created a bare-bones proof of concept note-taking app that works offline using HTML5 WebSQL spec, but also want to create an adapter that uses localStorage as well. My personal opinion (and I am biased) is that using an MVC library of any sorts is going to help you in the long run - the value of libraries such as Backbone, Knockout, and AFrame lie in their ability to reduce the cognitive load of the developer by enforcing a good separation of concerns. Data related functionality reside in models, displaying that data resides in Views, and the glue is kept in Controllers. Separating these three concepts might seem pedantic at first, but the end result is code that is easier to develop, easier to test, easier to maintain, and easier to reuse. A basic tutorial on using AFrameJS can be found on my site at: http://www.shanetomlinson.com/2011/aframejs-tutorial-for-noobs/
We have a library with very complex logic implemented in C. It has a command line interface with not too complex string-based arguments. In order to access this, we would like to wrap the library so that it can be accessed with simple XML RPC or even straightforward HTTP POST calls.
Having some experience with Java, my first idea would be
Wrap the library in JNI/JNA
Use a thin WS stack and a servlet engine
Proxy requests through Apache to the servlet engine
I believe there should already be something simple that could be used, so I am posting this question here. A solution has the following requirements
It should be deployable to a current linux distribution, preferrably already available via package management
It should integrate with a standard web server (as in my example Apache)
Small changes to the library's interface should be manageable
End-to-end (HTTP-WS-library-WS-HTTP) the solution should not incur too much overhead, but reliability is very important
Alternatively to the JNI/JNA proposal, I think in the C# world it should not be too difficult to write a web service and call this unmanaged code module, but I hope someone can give me some pointers that are feasible in regards to the requirements.
If you're going with web services, perhaps Soaplab would be useful. It's basically a tool to wrap existing command line applications in SOAP web services. The web services it generates look a bit weird but it is quite a popular way to make something like this work.
Creating an apache module is quite easy and since your familiar with xmlrpc you should check out mod-xmlrpc2. You can easily add your C code to this apache module and have a running xmlrpc server in minutes
I think you may also publish it as a SOAP based web service. gSoap can be used to provide the service interface out of the library. Have you explored gSOAP? See http://www.cs.fsu.edu/~engelen/soap.html
Regards,
Kangkan
Depends what technology you're comfortable with, what you already have installed and working on your servers, and what your load requirements are.
How about raw CGI? Assuming the C code is stateless between requests, you can do this without modifying the library at all. Write a simple script which pulls the request parameters out of the CGI environment, perhaps sanitises the input, calls the library via the command-line interface, and packages the result into whatever HTTP response you want. Then configure Apache to dispatch the relevant URL(s) to this script. Python, for example, has library support for XML-RPC, and so does every other scripting language used on the web.
Servlets sound like overkill, but for instance if you want multiple requests per CGI process instantiation, and don't feel like getting involved in Apache configuration, then it might be easiest to stick with what you know.
I'm doing a similar thing with C++ at the moment. In my case, I'm writing a PHP module to allow PHP scripts to access the logic in my C++ library.
I can then use whatever format I want to allow the rest of the world to see it - initially it will just be through a PHP web application but I'll also be developing an XML-RPC interface.
If you're going down the JNI route, check out SWIG.
http://www.swig.org/Doc1.3/Java.html
Assuming you have headers to project bindings with, swig is pretty easy to work with.