Removing the Browser

Does it work to make platforms file look like this (without browser)?:


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.

1 Like

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?

Looks like we’ll have to use package scoping then.

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!

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.

Oh my bad… I mis-read it. I though you were asking how you could have two separate servers and how to make the server ‘headless’ without any browser.

I split up the Blonk app onto a separate server and client codebases and it works pretty well.

Why would it be a real issue in this case? You app is only being used with Cordova as I understand the initial question.

  • You could just use a unknown url which is inside the app, so nobody will request it.
  • You could route / to a redirect (server side) so it even then won’t load your app.

Put your app on and you should be just fine?

Any normal user would just go to your normal website and never get at the meteor app url in the first place?

@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 “” on the server, and call next() in the server-side router only if the client is cordova. Else, redirect to “”.

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.

Why doesn’t that prevent the user from using the app in the browser?

If you block all requests with a token and you hardcode the token in the app it will be quite impossible for them to use the app in browser?

Nothing stops them from hacking the hardcoded token in their client source.

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.

1 Like

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.

1 Like

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.

1 Like

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 ?