I am using a MeteorJS to create an app for mobile phone. it will be deployed to iOS and Android.
I know the autopublish package is used to simplify database management, but it may also introduce some security concerns when using MeteorJS as a website where the endpoint is the browser and the database is on the remote server. to get around this problem you can remove the autopublish package and make better use of the Meteor.methods() function.
I was wondering if this is relevent on meteor 'native' mobile deployments, where the full stack is deployed to the device. so if a user was to load up a javascript console for the webview in the native wrapper of the standalone app on a device, the user would only be able to affect change to the device's local database (unlike the browser based version where there is a shared database).
Does that make sense? i am very new to Meteor, so i hope im not misunderstanding the concept of how Meteor works.
"'native' mobile deployments, where the full stack is deployed to the device" do not exist. When you deploy to ios or android, it is your client code that is wrapped with Cordova/Phonegap and deployed, your server must be deployed the same as for a browser client.
You should always remove the autopublish and insecure packages before deploying to production, for both browser and mobile clients.
The situation is the same for both browser and mobile clients. Neither have access to a 'shared' database, both use the minimongo in memory database, which is kept updated by the ddp pub/sub protocol.
It is a credit to the Meteor developers that the developer experience using it makes it seem like you (almost) have direct access to the server db.
This is in line with standard secure coding principles
Publications publish subsets of the server db data for 2 reasons: Security and Performance. While there may be corner cases where you genuinely do want to publish everything, in real world apps this is likely leaking (sensitive) data, and slowing down your app by sending more than is required.
The insecure package must also be removed for the same reason, as if left in place you are allowing an attacker read/write access to your server data.
Related
I am building a desktop application and added support for the Firebase realtime database. Because I am running a desktop application users will run different versions of my app.
As my app evolves, new features will be added and may require an update to the database schema as well. But I can't do this as I need to keep all client versions compatible.
For example, I have projects saved in the database at project/${uid}/${projectName}. Imagine in the future projects are not anymore tied to a user because I implement "collaboration" and want to change this path. How would I do this to keep all my clients up running?
You could store that path in realtime database and fetching the URL on client as required. I'm not sure what you mean by implement "collaboration" but if you want all the users to be on same version of your application then you would have to store the latest version in DB and verify the version yourself on client.
projects are not anymore tied to a user
In my opinion, if you could store a list of user UIDs who are a part of that project then that would be easier instead of structuring your app as projects/${uid}/projectname. If it is something like /projects/${projectId} then storing that list of authorized users would be much more easier.
There's Remote Config.
Firebase Remote Config is a cloud service that lets you change the behavior and appearance of your app without requiring users to download an app update.
You may have to use the REST API if your are building apps for desktop. Also as #Doug mentioned in comments, it may not synchronize all clients at same time.
I see this question has already been asked but not all that recently so I am bringing it up again.
How do you hide your firebaseConfig file, or any secret key, in an expo application? (For production, not dev).
As far as I can tell, there is no way to properly hide the firebase config file with API keys etc in a react-native expo app.
Being that I have already built my entire app around interacting with firestore, I am a bit perplexed as to how to proceed forward.
If I eject, is there a way to properly hide my API key in a non-expo react-native-app? Or will I still face the same problem? Everything is working smoothly and I would prefer not to eject.
I have some experience using node.js/express.js as a backend (only ever in a development setting). Should I build myself a server and then serve the config info from there?
If I want to deploy a 'demo' app, is there a way to hide the keys while still using expo?
Any insight into this would be so helpful.
As far as I am aware there is no 'dotenv' package compatible with expo.
Also I have zero experience in deploying mobile apps, and very little in deploying web apps. I have not yet had to deal with securing keys in deployment.
Any help would be so appreciated.
It's not possible to effectively hide your Firebase config information. The best you can do is make it more difficult for someone to find them. Since all the JavaScript code is running on a computer or device that you don't control, you can't ensure that any of it is hidden from view.
In fact, you don't need to hide any of that. I suggest reading this: Is it safe to expose Firebase apiKey to the public?
If you're using Realtime Database, Firestore, or Cloud Storage, you should be using security rules to protect data so that only authorized users can access it.
While googling for the confusion of mine, I didn't found the satisfactory resource.
so the question which I was searching for was, What is the difference between offline-first approached mobile apps and PWAs.
As to my level of understanding any mobile app lets say; a react-native app with redux in use or with SQLITE or with realm can be made as a offline-first approached app.
And with PWAs the service worker(of which i have less knowledge) makes all the offline user-interaction and at last when the net connectivity is confirmed the data is fetch or retrieved as required by PWAs.
Though I am not mentioning about other features PWAs can perform(again of which I have less knowledge). And even when the modern browser can only support for PWAs, why there is a hype of PWAs in todays trends?
Please guide me through with any mistake with my question. Any kind of information, knowledge or link to answer my query is much appreciated.
You can read the first of a series of articles about PWAs to get more details about PWAs features and their benefits.
The two concepts are not mutual exclusive. PWAs, thanks to the Service Worker and caching strategies, are able to implement/provide an offline first approach by caching target assets or data responses.
You can however provide an offline first approach also by using other technologies, without introducing a PWA.
The hype behind PWAs is due to the many extra functionalities we can add to a web app, making it behave and look like a native solution. Think just to the advantages of having your frontend team developing a web app that with very little efforts seems almost entirely a native app. And this without having to hire a dedicated native team (iOS/Android).
However PWAs are not the silver bullet for any scenario. They still have limitations that only native apps can provide (eg. SMS capabilities and accessing to the device contacts), even if there are different APIs that aim to solve these gaps, like Google Contact Picker API.
Most of the major apps till recent times was targeted towards countries having decent internet connections. With access to internet spiking in developing countries, most untapped market is coming to light. Though these parts have internet access now , the connectivity problems are plenty. So, to give the best experience for this new brand of customers, we need apps that can run offline
Offline First Approach :
This approach mostly caters to any device which can run offline until a reliable connection is interfaced. As developers , this would mean build the capabiltity to store information in the device through databases, caches or any other local storage approach.
And then when the user opens the app (desktop/mobile) , these run as normal as possible. Just give the user a heads-up that it is not in sync with the latest.
So, an offline first approach can be
Android native app with an offline capability
IOS App w/ offline features
Internet dependent Desktop app w/ offline support
WebApp w/ offline functionality : PWA is the latest
PWA (Progressive Web Apps) :
A PWA is a Web App which has the capability to run offline. With low cost devices (memory deficient, low processing power ) used by many of these users, it's imperative that people installing new native apps will reduce. Also, it's hard to convince people to download and install a new app.
That is where a Web app can be the game changer. A Progressive Web App which has native experience and offline capabilities could drive more users to try a new offering. Adding to that, without forcing a user to install one more app , a link can be easily marketed.
A Progressive Web App is a subset of the offline first approach. With browsers adding more capabilities to access native functions like Contacts as #Francesco pointed out , PWA might will be the first step towards modern app development to release any new feature.
Why is the difference between using a simple phonegap browser app pointed at your site vs using meteor's mobile build options?
a simple phonegap browser app pointed at your site
Not sure exactly why you would be ready to use this option, compared to a simple shortcut / link to your site, or even an "installable" Web App.
Anyway, since you point at your site, it means you require an Internet connection whenever you open your app, and you are limited by what a website can access to on your device.
meteor's mobile build options
It becomes similar to a native app (it is actually called a "hybrid" app), so you can use it totally offline, and you can access more device functionalities (file system, notifications, etc.).
Nothing really specific to Meteor here, it is rather why using a hybrid app v.s. a shortcut.
In the end, you should base your decision on your requirements:
Do you need to access your app while offline?
Is your app primary functionality accessing "real time" content that makes no sense using your app while offline? (like news, forums, etc.)
Do you need to access specific device functionalities, that are not accessible by a normal website?
You should have plenty resources on that topic on the Internet.
Your question might rather be: what is the difference between a standard hybrid app (typically built through Cordova / Phonegap) and one built through Meteor?
In that case, you are asking what Meteor brings specifically? (as it uses Cordova under the hood to build the app)
First of all, you have all advantages of Meteor framework for normal website (minimongo, isomorphic methods, etc.)
You also have by default the Hot Code Push functionality. You can also set it up on your Cordova / Phonegap app, but you will have to configure it yourself, whereas Meteor does everything for you.
Finally, you might benefit from Meteor packages that bring Cordova plugin + client code + server code, something unique to Meteor as it is a full-stack framework.
I'm investigating the possibility of building a chrome app for a specific enterprise customer. This app would only be used by that customer (ie, it is not a general purpose app).
Among the use cases described on the Technical Overview are the ability to replace "Legacy desktop applications" and "enterprise applications that require heavy computation" - the solution I'm considering fits into both these gaps, as we have some mathematical libraries that we'd like to incorporate into a client-side web app.
Later on in the same document, however, it indicates that you can only deploy native client apps that are deployed on chrome webstore, as clarified by the https://developers.google.com/native-client/devguide/distributing document (and various developer scenarios).
Question: Is it possible to have build a web-app that uses Native Client, and distribute that to users worldwide, but without using Chrome Webstore (ie, using an internal server)?
Note: I've seen this document about creating a private chrome app collection on webstore, but this seems to be specific to ChromeOS. I'm interested in deploying to users that have the latest stable build of Chrome.
It is absolutely possible to run a Native Client app without hosting it on the Chrome Webstore -- otherwise, it would be very difficult to develop an NaCl app in the first place. It is possible for end users to use an NaCl app hosted on any random site. The catch is that the user needs to specifically enable the feature in their Chrome browser. It looks like the current way to enable this is to visit the "chrome://plugins/" page (or "about:plugins" page, same thing), and check the "Enabled" box under "Native Client".
Perhaps enterprise-level administration makes this easier to roll out, or perhaps allow finer-grained control so that only NaCl apps within the corporate intranet are trusted while not allowing stuff from the broader internet (NaCl is supposed to be safe and sandboxed, but Google is still playing it safe and paranoid, just in case).
For a public example of a self-hosted NaCl app, check out NaClBox, a Native Client port of the venerable Dosbox emulator. While it is also hosted in the Chrome Webstore, their support page describes how to run it directly from their site.