Dexguard is currently too expensive for me as I seek to protect my Android app. I'm considering LIAPP (https://liapp.lockincomp.com/), but would like to know what others think of its effectiveness in protecting my app's assets and in protecting against hacking and reverse engineering.
I tested LIAPP on my app, and it worked, so I've now purchased it.
Related
As I heard that there are many things need to be considered before Deploying a Meteor App, However, it's still quite vague. Anyone please give me some opinions about this issue. Thanks
This is probably the wrong forum for this type of question, since it's highly opinionated and not really in the Q&A format, but I'll give you some of my personal opinions.
Where am I hosting my app?
This has a lot to do with what your app is (Web-based app, Android-only), how many users you plan to have, if this is a public app or something private, how much you have to spend, and many other factors. Options include:
Host it yourself - Could be on a VPS (Virtual Private Server, like Digital Ocean and others), some cloud offering (AWS or similar), or a bare-metal server you have hosted somewhere (like in your closet).
Pay for dedicated hosting - Several out there that offer many different features, like Galaxy or Modulus, etc.
If you host it yourself, then you have to maintain the hosting solution, I.E you need to support it all on your own. This may mean provisioning/installing the OS, installing and configuring the server apps (MongoDB, Node.js, web servers, etc), and maintaining everything over time. The benefits, however, are potentially cheaper hosting costs (although this could be debated) and custom setups/architectures. If you are creating an app that should remain private (I.E. not a public app) you may want to consider this option so you can host it internal to the company and not make it public-facing. There are some tools out there that can ease the process of setting up the server, for instance MUP/MUPX.
For dedicated Meteor hosting, the benefit is that someone else does the installation, configuration, and maintenance of the core apps, and all you have to do is push the button to move your code in. These options can be more pricey as they are covering the IT costs of supporting the environment, but they usually come with the benefit that a) You don't have to install all that stuff yourself, b) you don't have to be an expert at all the "plumbing", c) You don't have to hire a staff of people to support your infrastructure, d) These hosting services usually know how to optimize things properly to get better performance for your app.
Do I deploy manually or do I use some tool?
This depends highly on the answer to #1, as your hosting decision may come with it's own set of tools used to deploy (ex. Galaxy), or you may need to shop around for the best tool for you. For manual deploys, I'd suggest looking at MUP/MUPX, which can automate the deployment of your app, even configuring the web server, DB server, and setting up everything as Docker images. Or, if you want to have more control, maybe take a look at something like Grunt or Gulp, which are more build-scripting solutions (similar to ANT/Maven/Gradle are for Java).
Do I expect a fast growth, or a slow trickle?
Again, this has a lot to do with where you plan to host. Lots of cloud services make it easy to grow/shrink your cluster of servers based on load, but this takes a LOT of configuration past just installing an OS. VPS and bare-metal solutions will be the hardest to expand. Dedicated hosting will depend on the provider.
You need to serious need to think about how you might handle a fast-growth situation, even if you don't think your app will take off. The internet is riddled with apps that failed because they didn't think they would be as successful as they were. It only takes one mention on something like Reddit, Y Combinator, or Product Hunt for your app to get a sudden and unexpected rush of traffic that takes down the server(s). If you know your growth will be controlled in some way, like if you have a private app with a pre-set number of users, then you might not need to worry about it.
Do I need to monitor my app?
The answer to this is always "Yes", but to what extent? Do you need to provide 24x7 uptime? Would an outage cost you lots of money, make you loose your biggest client, etc? Can the users live without service for a little while if it goes down, or would I loose face and customers? Depending on how serious you need to be, you should consider some sort of monitoring of your infrastructure and app. Again, there are LOTS of options here, and your decision might be swayed quite a bit by the answer to the first question.
I am sure there are other questions, but these are the biggest I could come up with.
I was looking at some larger scale Meteor applications and was wondering why some of the initial sites do not seem to use meteor.
As an example when you go to classcraft and look at the main website you notice it is not using meteor.
Then when you go to their actual application (click signup for example) you can see it uses Meteor.
So they make a clear separation in terms of technology. Can someone explain the reasons? Is it not as efficient / clean to just use Meteor for the whole thing.
Thanks,
Jean
Each company makes their own decisions on how/when/where to use technologies. In the case of meteor, the really strong part of meteor is that it's real-time updating. That means things like messaging systems, getting updates out quickly, etc. good uses for meteor.
It appears as though classcraft has decided they don't need that capability on the home page. There's also some concerns with SEO and meteor that perhaps classcraft didn't want to deal with.
Finally the home page not being built in meteor shields the DB from public view, which is not a huge security advantage, but may be one they considered.
This is all me finding reasons for them as I don't know why they'd make that decision. I don't make that decision for my sites/apps but that doesn't mean others might not see things differently.
I'm the founder of Classcraft. To answer your question, it's because we didn't need everything Meteor had to offer for the front-facing website : reactivity, flexible templates, a database, etc. Meteor is amazing for building apps, but it's overkill for a static website. Also, if the front-facing website was built within the game app, it'd mean that any copy changes or tweaks to the front-facing would cause us to have to redeploy the app, which means some downtime (not much, but still) for our users. Keeping them separate also allows marketing people (who aren't developers) to tinker with it without going into the code base for the game.
We decided to build the front-facing website using middleman. Middleman allows you to generate a precompiled static website, which allows for amazing speed and simple server configuration (it's served from S3, which means it's super fast).
I'm sure the reasons are different for everybody, but that's what it was for us.
Shawn
I am a big fan of Firebird DB, I am using it since 1.5.0 version, but I am curious why FB is not that much popular as web sites back-end DB. I would like to use embedded Firebird DB on my websites (after 2.5 version improvements), advantages are obvious (no need to install anything, all dll-s you can put in your web site bin folder and FDB in App_Data – I am using asp.net technology).
My question is: does anybody has some experiences with this approach (Medium Trust shared hosting), and what limitation I might expect? How many concurrent users can be acceptable in such scenario, are there some known issues I need to be aware of and so? Is lack of security mechanism in embedded that big disadvantage for this approach?
Thanks in advance.
First off, I do not have any experience with Firebird. When googling though, I do see reports of problems using it in medium trust. But if you want to know for sure, just try! It might well be that the information I'm reading is old.
Concurrent users is a difficult question to be fairly honest. I suppose it (how many) depends on too many factors to give a good answer. But the most important thing you want to look at is concurrent writing. For example SQL Lite does not support this (afaik), and in a web application this is bound to happen. I think FB supports this, but you might want to check this to be sure.
About security; as far as I know FB does not support encryption nor password protection. This is a valid concern you express, if anyone compromises your server the FB file is there for grabbing. Methods to work around this are not pretty (encrypting before insert/update and decrypting at retrieval, or filesystem encryption), so if security is important this will be your biggest concern.
I'd like to state again that I do not have experience with FB myself, I just express the concerns I would have myself when thinking of such a scenario and try to get some information on the internet.
I'm making an asp.net web application which will run locally on IIS
for a single user
I don't want this user to access my application files (in the www root ) or bring another programmer and steal my code
I just want the user to have the ability to access the website only and
stop any programmer from knowing my source code
I heard about an USB security system called "Dongle" but can it be used in a situation like this ?
any Ideas ?
thanks in advance
The website is just running code, but like anything, once the user has it they can do what they like to it, whether you like it or not. That's why there is a multi-million {currency} industry around securing applications.
You could use dongles but they're expensive and not trivial to implement. As #volleyball said, obfuscation would slow down most people from decompiling your app. without odfucation any licensing or dongles could just be patched out of your code.
Your most secure route would be to not give it to them. It's a web app, host it. This may not of course not meet your requirements.
Simon
I have never heard of a web application that uses a dongle. This is normally reserved for regular windows apps; and even then it's falling out of vogue. Generally speaking some of the more expensive software packages still use them.
However, the cost of duplicating a dongle is pretty low. Combined with the fact that getting around such security is relatively easy anyway and you have a situation in which you really shouldn't bother.
As Simon said, if it's a web app host it. Otherwise obfuscate it.
If neither of those are possible, then I'd recommend you change your licensing deal with your client to include the possibility of them going elsewhere. Perhaps for an additional charge you'll give them a non-exclusive site license permitting them to do whatever they want with the code short of selling it or giving it to another entity.
did you look at obfuscators. They do a good job at encrypting code. 99% of the time your code cannot be reverse engineered. But if someone sits on your stolen code they can reverse engineer.. In the sense that ordinary people may not obfuscate it. If the person is very intellingent, he will not reverse engineer he will write better code.
What do people consider scalability? I've always hear people talk about writing scalable apps. But as a developer, I've never really saw any pointers/tips in an article that normal developers dont know. Such as caching db calls, etc. Mostly what I see are options that are configured by system admins or anyone dealing directly with the servers.
So my question is, from a developers perspective, do we really have much effect on a website's scalability? If so, could we be pointed towards articles that aids us on the .net framework. (ASP.NET MVC)
Also, do we have to write our apps differently if we were to accommodate adding new hardware, such as another webserver. (or is it the same app, but more instance of it?)
You can maybe gather some input from here on SO:
What does scalability mean to you?
Engineering scalability into an application
Design Patterns (or techniques) for Scalability