I am newbie in meteor. I planned to develop a mobile app in meteor with existing mongodb. Is it safe/secure to build mobile app in meteor?. where database credentials will be stored, mobile or server?
The database credentials will be stored in the server. The user's login credentials will also be encrypted before being sent to the server.
Anything you want to be server-side only you should put under your /server directory. Everything else is potentially visible client-side.
to avoid problems you have to take care of two default settings which are active for development - but need to be switched of for production:
By default, Meteor makes all of the data inside our database available to our users. This is convenient during development but a big security hole that needs to be plugged.
This default functionality is contained within an autopublish package. To remove it use: meteor remove autopublish but it also breaks and needs to be fixed.
The first step in fixing the application is using a Meteor.publish function inside the isServer conditional to decide what data should be available.
Because Meteor.publish function executes on the server, it continues to have access to all of our data. This is because code on the server is inherently trusted.
The second step in fixing the application is using a Meteor.subscribe function from within the isClient conditional to reference the publish function.
Inside the publish function, we can’t use the Meteor.userId() function. We can, however, achieve the same thing with this.userId .
By default, it’s possible for users to insert, update, and remove data from a collection using the JavaScript Console. This is convenient for development but a big security risk for a live application.
The solution is to move the database-related code to the trusted environment of the server. There, users don’t have any direct control.
To first remove the security risk, with meteor remove insecure -> remove the insecure package from the project. The application will become much more secure but our application will break. None of the database-related features will work.
By using methods, you are able to write code that runs on the server after it’s triggered from the client. This is how to fix the application.
To create methods, use a methods block on the server, and then trigger methods with the Meteor.call function.
You can pass data from the Meteor.call function and into the method, allowing us to still use data from our submitted form on the server.
(Answers party copied from "Your First Meteor Application", David Turnbull)
Hope that helps to get the concept.
Michael
Related
We are building an app for our teams out in the field that they collect their daily information using Firebase. However one of our concerns is poor connectivity. We are looking to build an Online/Offline button they can click to essentially work offline for when things slow down. We've built a workflow in which we query all the relevant information from Firestore.
I wanted to know if there was a way to tell Firestore to work directly on the cache only and not try to hit the servers directly. I don't want Firestore attempting to make server calls until they enable online again.
You shouldn't need to do this. If you use realtime listeners, they will already first return the data from the local cache, and only then reach out to the server to check for updates.
If you are performing one-time reads, the SDK will by default try to reach the server first (since it has only one chance to give you a value). If you want it to only check the local cache, you can pass an argument to the get call to do so.
You can also disable the network completely, in which case the client will never call on the network and only serve from the local cache. I recommend reading about that and more in the documentation on using Firestore offline.
Still quite new to meteor/coding and I have a question on how to connect meteor to a live api that uses websocket.
The api is from bittrex (exchange for cryptocurrency) and there is a node js package that gives a "subscribtion" to the api in order to get live data:
https://github.com/dparlevliet/node.bittrex.api
I manage to have it run with node with no problem but I would ideally like to connect it to Meteor in order to present the data nicely. The props should be updated live with the data received. (nb: there is a lot of data, it is continuously coming).
Is there a good way to do this or is meteor not suitable for this. It means the props would change continuously.
Would a node/react solution only be better ?
This question might get closed because it's a bit opinion based but...
You have a streaming data source providing data over ws. You could:
(a) have all your clients subscribe directly to that source and not involve your server at all. In this case you'd be just using React on the client and basically ignoring Meteor (even though you'd be building the UI in a Meteor app). I don't know how bitrex charges for access or how they scale across many connections so that may be an issue if there are many connections.
(b) use your Meteor app to proxy then fan-out the bitrex data. In this case you would:
subscribe to the bitrex data source from your server
copy the data into a mongo collection
publish that data using a Meteor publication.
Your clients would subscribe to the Meteor publication and on the front end you would get reactive data updates like any other Meteor app.
The benefits of (b) are that bitrex only sees one subscriber and your app looks like a pretty vanilla Meteor app. Also if you have to use any kind of api key or secret to access bitrex then that key doesn't need to be shared with the client side.
I want to setup a public form to write to Firebase via the Angular Firebase plugin AngularFire but it feels like there needs to be some security added so that data is only posted from that form, I can't see any interface to Whitelist a Domain/URL. Is there a way to only accept writes from a specific Form/URL without getting the User to login first?
Nope.
But it wouldn't help in your scenario anyway: when you're using Angular, all code is running in the user's browser. It might be served from your domain into that browser first, but just as easily the user might have saved the HTML locally and started running it that way.
It sounds like you're trying to secure things so that only your code can modify them, probably because you think that your code is the only thing that can be trusted to follow some of your application-specific business rules. Instead of trying to limit access to just your code, I'd instead recommend capturing the business rules server-side. Firebase has a very powerful security and data validation model just for that purpose. See https://www.firebase.com/docs/security/guide/
Once you enforce these business rules on the server, it doesn't matter how someone access your data. They could be using your code - or somebody could have taken your code (or an API that you've documented) and written a third-party application. Either way: the (security and validation) rules will be enforced by Firebase, so your data will stay valid and secure.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm building my first app with Meteor and I'd like to know the best security measures to take in a couple of situations...
How do I ensure users are not submitting commands like drop table to my forms? Do I have to manually sanitize somehow or is this automatically handled?
Normally I would use a GET on forms if it asks the user for sensitive information, however I'm confused how Meteor handles inserting items to the db. Is the info submitted through forms secure or is it being passed over somewhere people can it?
If I have removed the autopublish and the insecure packages it means users cannot just query for other user information, is that correct?
Sorry, if these are noob questions. I haven't quite wrapped my head around how the security of an app all fits in but any help would be much appreciated :)
Here is a quick rundown of the basics of securing your meteor app:
Transmit everything over HTTPS.
Separate your client and server code into their own directories. A great way to keep your server-side secrets safe is to never send them to the client in the first place.
Remove the insecure package.
Remove the autopublish package.
Add the audit-argument-checks package and add checks to all methods and publish functions.
Add the browser-policy package (after completing all of the above).
Here are some answers to your questions:
If insecure is removed and you don't have any allow rules, then users can't remove anything. Regardless, documents on the client can only be removed or updated by id, so you can't drop a collection with a single command.
With the proper allow rules specified, then the client can execute an insert/update. Otherwise, you can use a meteor method to have the server perform an insert/update for you. e.g. you can specify a method like postsInsert on the server. Messages will be passed between the client and the server in the clear unless you use SSL.
Correct. With autopublish off, you need to specify which documents are published to the client - otherwise the client will not have read access to any documents.
If you don't want your users to perform certain operations, you don't allow them to do so. The only commands your users are able to perform on the database are those you specify : when you remove the insecure package, typing Collection.remove({}); in the browser console won't drop the entire collection, users will have to Meteor.call certain allowed operations (through Meteor.methods) to perform authenticated-only stuff.
Generally, you want the OWNER of a resource to be able to edit/delete it, but other people shouldn't be able to modify it.
If you have an edit form for one of your collection, you will likely have corresponding Meteor.methods to edit/delete it.
Inside a Meteor.method, you can check the passed arguments received from the client to validate data correctness, you can also verify if the call was issued from an allowed user (typically the owner of the document).
Hopefully, Meteor comes with a Match framework to test parameters sent to Meteor.methods.
// define a test to check if a document is editable by a certain user
EditableDocument=function(userId){
return Match.Where(function(documentId){
var document=Collection.findOne(documentId);
if(!document){
throw new Meteor.Error(500,"Document doesn't exist !");
}
if(userId!=document.creator._id){
throw new Meteor.Error(500,"Can't update a document you don't own.");
}
return true;
});
};
Meteor.methods({
updateCollection:function(documentId,fields){
check(documentId,EditableDocument(this.userId));
check(fields,{
field1:Match.Optional(String),
field2:Match.OneOf(Number,Boolean),
field3:Match.Any
});
// if the tests pass, do your thing
...
}
});
To communicate form data between the client and the server, Meteor uses DDP (Data Distributed Protocol) with a technique known as Remote Method Invocation.
A client can Meteor.call a Meteor.method declared in the server and get a response asynchronously.
This is different from classic form submition manipulation techniques which is done using HTTP, and can use its secure counterpart HTTPS, to encrypt data between a client and the server, avoiding data sniffing issues.
DDP supports data encryption and every *.meteor.com hosted sites are using meteor.com certificate to ensure that all traffic is properly encrypted using SSL.
On your own hosting solution, you will have to handle this yourself though.
https://groups.google.com/forum/#!topic/meteor-core/a9dPA1-mgXA
After removing autopublish, every server resources won't be published to all clients no more, meaning that one can't just query your collections to get other users documents access.
Be sure to read the docs at least once to fully understand Meteor related aspects of web development.
I'm working on rewriting an existing application with Meteor that has two fairly distinct use cases (an administrator account and user account). Both could be considered separate apps in terms of functionality, but share the same back end database.
Is there any way to "namespace" or otherwise define separate clients so that Meteor only packages and sends assets for the client that's being accessed. For ie. the meteor-router could push different clients for the /admin* space and the /user* space, that way there's no unnecessary overhead downloaded for either client.
I expect this is outside the scope of what's within the means of a Meteor smart package like meteor-router.
You can always create two applications that connect to the same database. Shared server code may be put in a package and included in both, so there will be no need to repeat it.