Does it work to make platforms file look like this (without browser)?:
android
ios
server
I tried it, and it didn’t work. That said, is there a preferred way to isolate an app to only work on cordova, and not on the browser? I would rather not have to wrap all of my offending code in Meteor.isCordova – this is not a realistic solution for massive code bases. Am I going to have scope my code into packages? That’s OK, but I’d like to know if there’s an easier way.
There is currently no way to skip the browser platform. Building for the browser is hard coded and does not rely on the contents of the platforms file.
I don’t think we have a good solution for your use case at the moment, but maybe someone else has dealt with this before?
Not sure if this is exactly what you’re looking for, but we achieved this by running an onBefore action in the router that checked for Meteor.isCordova, otherwise redirected to our homepage.
@flintchip that’s exactly what I’m doing! But I don’t like it, because it
requires sending all of the code to the client, which is why I’m after a
deeper solution. I started by doing it in an onBeforeAction (actually, a
trigger – I use FlowRouter, but it is the same idea). I changed it to
execute in client/lib/a_firstFileToRun.js, before any of the other stuff
gets initialized.
I know that we can load code in Cordova exclusively using packages, so I’ll
look into that as a more thorough solution. I hope this helps you, also!
Thanks.
You can by individually adding in packages manually but it’s generally not worth it. If anything adding the static html package will remove blaze from the build and will just sever an empty page.
@SkinnyGeek1010 interesting, I’ve not heard of that before. ideally, I
could serve an empty app and then perform the redirect to my main website
in client/lib, which directs the user to download the app. or could just
show them that page… if only mdg made it easier to decouple this. why
these are coupled I’m not sure.
@lucfranken I would rather not rely on obfuscation, as it is not a substitute for security.
I do like your second suggestion. Lately, I’ve been playing around with meteorhacks:picker. I could filter all client requests to “https://my-app-only-for-cordova.myapp.com” on the server, and call next() in the server-side router only if the client is cordova. Else, redirect to “https://myapp.com”.
The problem is that anyone can hack their own request to mimic cordova, or a bot, or anything for that matter, making this insecure. I guess this is an unavoidable hole.
Only way to solve your final issue is using a token which you embed in a native app and use to do the requests. Then they would have to reverse engineer the app. Still possible but not doable without the actual app.
I would for sure not see any of this as a security measure, they will get the client side code anyway.
Btw I was saying just host your app separately at a subdomain. So don’t filter but really keep website and app separate.
That’s what I’m doing, but that doesn’t prevent people from using the app
from the browser. I think the redirect is a simple solution which does the
job for now.
Exactly it’s not a real security measure but makes it more difficult.
You can expand on this:
Refresh the token on every update
Do some kind of signing of the token
Do something native to generate the code etc
They would have to write some code / browser plugin to handle all that stuff to keep it working.
But anyway what’s the use? A normal user just gets the source files just as he downloads the app. And since it’s client code it’s open, that’s just how it works.
Reminds me of those movies where hacker A tries to obfuscate what they are doing faster than hacker B can undo them…
Anyways, I think you’re right – it seems like all I can do is hide the loophole and not really get rid of it. I might as well just stick with the redirect. It’s one of those apps which relies on users not hacking their location, but I guess anyone can do this anyways if they are determined. It’s better to ignore outlying data on my server than to try and prevent it.
I think you should separate secrets and tools. In general your data and server side code should be secret but the client side code is just a tool to show and/or use the secrets.
Definitely, but the client is also a tool to tell the server what to do, so it must be throttled. But this throttling can only be 100% secure if it is on the server. Else, the user can examine the client side code and call internal functions directly, bypassing any error checking, etc.
Correct, that’s how you should see it. Check directly when a request gets to the server all your desired rules.
Still for the average user it can be great to limit things also on the client. Like prevent them from sending a form multiple times. Because they will not bypass your security rule and it will prevent unnecessary requests to the server. So both have their use case.
I’m having the same conundrum now, I’m working on a WebGL Game, I’ve already put in it ~3 weeks and I still think I’ll put 2-3 months more.
And just serving it on the client for anyone to copy is a crying shame, at least in a cordova app on ios or android that client code is more protected. But from what I read above, Is it more protected? Can someone easily access that client code, or they need to reverse engineer the app to ‘crack’ it ?