Ability to update collections on front-end in Meteor - meteor

I'm struggling to get my head around the ability to edit any collection that's available to the front-end, and how to prevent it - and if this is a feature only available to Mongol.
Mongol states:
… because Mongol is a debugOnly package, it does not compile to production code.
Which is great, but as I'm new to Meteor I'm not sure if Mongol is just an interface in this scenario, or if the ability to update is something always available to the front-end (and Mongol is just making it easier).
My scenario is that I have a form submission page that grabs the profile of an associated Meteor.user to display their name along with the form:
HTML
<template name="form">
<h2>Submission for: {{ user.profile.name }}</h2>
<form id="brief">
…
</form>
</template>
Route
Router.route('/form/:_id', {
loadingTemplate: 'loading',
waitOn: function () {
return Meteor.subscribe('forms', this.params._id);
},
action: function () {
this.render('form', {
data: {
_id: this.params._id,
form: function() {
return Forms.findOne({});
},
user: function() {
return Meteor.users.findOne({});
}
}
});
}
});
Publication
Meteor.publishComposite('forms', function(formId) {
return {
find: function() {
return Forms.find({_id: formId});
},
children: [
{
find: function(form) {
return Meteor.users.find({_id: form.userId}, {fields: {profile:1}});
}
}
]
};
});
This works perfectly - however using the Mongol console I can update, duplicate and remove the user. Naturally in a production environment I wouldn't want this to be possible - is this something only available because Mongol is there, or could a determined user achieve the same thing without Mongol?
If they can, how do I prevent/work with it?
Edit: It's also elaborated on here: https://github.com/msavin/Mongol/blob/master/documentation/SECURITY.md
Given how they refer to 'special methods' I'm assuming that's what allows this to happen, and that the ability to directly update the fields isn't ordinarily available to the front-end. If anyone's able to confirm that would be ace!

Yes, Mongol uses a backdoor solution (in debug/dev only) to access and change your mongo docs in the db. This means it wont be included in your production code. As far as client side operations on the DB, Meteor restricts updating, removing, and inserting to the server although you can use Meteor's allow/deny rules to allow the client to update a DB collection. However, allow/deny rules need to be very tight to ensure the client can not alter data they should not be able to. For this reason, most people stick to using server side DB changes that are fired by meteor.methods that the client can initialize.

Since it is a debugOnly package as long as you don't deploy to production in "debug mode" it is safe.

Related

MeteorJS - List item Not updating after implementing publish / subscribe and methods / calls

Ok so this is a little weird...
I got these methods on server side ...
Meteor.publish('todos', function () {
return Todos.find({userId: this.userId},{sort:{createdAt:-1}});
});
Meteor.methods({
editTodo: function(todoId) {
Todos.update(todoId, {$set: {checked: !this.checked}});
}
});
And here is the invocation on client side ....
Template.list.helpers({
todos: function(){
Meteor.subscribe('todos');
return Todos.find({});
}
});
Template.list.events({
"click .toggle-check": function(){
Meteor.call('editTodo',this._id);
}});
The problem is that when the click on ".toggle-check" occurs ... the 'checked' boolean is triggered on but never comes off .... is this.checked (in {checked: !this.checked}) not referring to field immediately read from the collection?
Or maybe I am implementing something wrong when subscribing to the data?
Please help!
I believe the issue relates to the registration of the subscription as you suggested - more specifically that your Meteor.subscribe() is being called from within a Template.helpers function.
Try moving your subscription to an earlier page or template event such as Template.body.onCreated() or Template.list.onCreated() (depending on your requirements).
There is a good example in the Meteor documentation: https://www.meteor.com/tutorials/blaze/publish-and-subscribe (see section 10.3).

Meteor performance: not sure if publication is causing the lag

My Meteor app runs slowly in the beginning for about ten seconds, and then becomes fast again. I am trying to improve the performance but having troubles to find the real cause.
I thought the problem was that I am publishing all the course information like following:
if (Meteor.isServer) {
Meteor.publish("courses", function() {
return Courses.find();
});
}
I tried using Kadira to monitor exactly what's happening. However, looking at the result, I am starting to think maybe it's not the real problem.
If it only takes 292ms for pubsub response time, it shouldn't feel that laggy but I cannot think of any other reason why the app would be so slow in the beginning and become fast again. Can an expert point me to the redirection?
UPDATE:
I could improve the duration of lagginess in the beginning by making the following changes:
in /server/publications.js
if (Meteor.isServer) {
Meteor.publish("courses", function() {
// since we only need these two fields for the search bar's autocomplete feature
return Courses.find({}, {fields: {'catalog':1, 'titleLong':1}});
});
Meteor.publish("courseCatalog", function(catalog) {
// publish specific information only when needed
return Courses.find({"catalog": catalog});
});
}
and in router.js I made changes accordingly so I subscribe based on specific pages. But there's still some lag in the beginning and I wonder if I can make more optimizations, and what is the real cause of the slowness in the beginning.
UPDATE2:
I followed the suggestion and made changes like below:
Session.set('coursesReady', false); on startup.
and in router:
Router.route('/', function () {
Meteor.subscribe("courses", function(err) {
if (!err) {
console.log("course data is ready")
Session.set('coursesReady', true);
}
});
....
and in /lib/helpers.js which returns data for typeahead library
if (Meteor.isClient) {
Template.registerHelper("course_data", function() {
console.log("course_data helper is called");
if (Session.get('coursesReady')) {
var courses = Courses.find().fetch();
return [
{
name: 'course-info1',
valueKey: 'titleLong',
local: function() {
return Courses.find().fetch();
},
template: 'Course'
},
But now the problem is that when the helper function is called, the data is never ready. The console print:
Q: How do I ensure that the helper function is called only after the data is ready, OR called again when the data is ready? Since Session is reactive, shouldn't it be called again automatically?
I can't check this right now, but I believe your issue might be that the course_data helper is being run multiple times before all 1000+ documents in the subscription are ready, causing the typeahead package to re-run some expensive calculations. Try something like this:
/client/views/global/helpers.js
Template.registerHelper("course_data", function() {
if (!Session.get('coursesReady')) return [];
return [ //...
/client/subscriptions.js
Meteor.subscribe("courses", function(error) {
if (!error) Session.set('coursesReady', true);
});
Update:
Really, Meteor's new features this.subscribe() and Template.instance().subscriptionsReady() are ideal for this. Session isn't really the right choice, but it should still be reactively updating (not sure why it isn't for you). Try instead making the following changes to /client/views/navwithsearch.js (and main, though ideally both templates should share a single search template):
Template.NavWithSearch.onCreated(function() {
this.subscribe('courses');
});
Template.NavWithSearch.onRendered(function() {
this.autorun(function() {
if (Template.instance().subscriptionsReady()) {
Meteor.typeahead.inject();
}
});
});
The idea is to tie the lifecycle of the subscription to the view that will actually be using that subscription. This should delay the typeahead injection until the subscription is completely ready.

Route returning blank page [METEOR]

I am trying to create a route for a user profile page, but when I visit the route it shows up as a completely blank page and with no errors in the terminal. Nothing whatsoever is shown, including static HTML. Here's the code:
routes.js
Router.route('/user/:_id', function () {
this.render('user');
}, {
name: 'user',
data: function(){
return Users.findOne({_id: this.params._id})
}
});
user.html
<template name="user">
<p>hello</p>
</template>
At the moment, I am using the default user accounts package and have not added any publication or subscription code.
Are you sure Users is an existing collection?
At the moment, I am using the default user accounts package and have
not added any publication or subscription code.
In that case, with autopublish enabled, your problem is probably solved by changing
data: function(){
return Users.findOne({_id: this.params._id})
}
into:
data: function(){
return Meteor.users.findOne({_id: this.params._id})
}
although it's strange this doesn't throw an error in your console...
Not sure if this is the reason, but I think that with multiple options for the route, you should incapsulate this.render in an action parameter. Something like this:
Router.route('/user/:_id', {
name: 'user',
data: function() {
return Users.findOne({_id: this.params._id})
},
action: function () {
this.render('user');
}
});
Source
I get an error in the terminal: "Users is not defined":
http://meteorpad.com/pad/eciFidhwHmLhjWmF3/Leaderboard
In your data function, try substituting Meteor.users.findOne({_id: this.params._id})
If you fix the HackPad I listed, Meteor.users won't work since the current version of HackPad doesn't support a late enough version of Meteor with Meteor.users. However, if you comment out your data function, you should at least see the page.

Publishing all Meteor.users doesn't work

I'm trying to publish all the usernames to the clients, even if not signed in. For that, on the server I have:
Meteor.publish("users", function() {
return Meteor.users.find({}, {fields : { username : 1 } });
});
And on the client:
Meteor.subscribe("users");
However, when I try to access the Meteor.users collection, I find nothing there.
(This is essentially the same as the question here: Listing of all users in the users collection not working first time with meteor js, only without checking the roles for admin first. Still doesn't seem to work..)
I'm probably missing something silly..
I find the same issue, and after doing a research i find this package, i think it may should help you.
Take a look and hope it help you
Update
First move the subscription to the /lib folder, just to make sure its the first thing meteor do when start, also change a little bit the subscription like this on the /lib, folder.
Tracker.autorun(function() {
if(Meteor.isClient) {
if (!Meteor.user()) {
console.log("sorry you need to be logged in to subscribe this collection")
}else{
Meteor.subscribe('users');
}
}
});
For better security we just subscribe to the users collection when the client its logged in
This code outputs all the usernames to the clients, even if not signed in (in this case on /users page):
server/publications.js:
Meteor.publish("userlist", function () {
return Meteor.users.find({},{fields:{username:1}});
});
client/users_list.js:
Template.usersList.helpers({
users: function () {
return Meteor.users.find();
}
});
client/users_list.html:
<template name="usersList">
{{#each users}}
{{username}}
{{/each}}
</template>
lib/router.js (using iron:router package):
Router.route('/users', {
name: 'usersList',
waitOn: function(){
return Meteor.subscribe("userlist");
}
});
Hope it helps.

Client-side-only reactivity with Meteor?

I have a collection published on the server and auto-subscribed on the client. I'd like to set the 'selected' item on the session and have the template update to display only the selected item, but it seems this can only be done with a roundtrip to the server (which is totally unnecessary).
Common:
var Missions = new Meteor.Collection('missions');
Client:
Template.missionList.missions = function() {
var currMission = Session.get('selectedMission');
var searchMission = {};
if(currMission)
{
searchMission['_id'] = currMission;
}
return Missions.find(searchMission);
};
Template.missionList.events({
'click div.mission': function (e, t) {
Session.set('selectedMission',
this._id == Session.get('selectedMission') ? null : this._id
);
}
});
Template.mission.isSelected = function() {
return this._id == Session.get('selectedMission');
};
Meteor.autosubscribe(function () {
Meteor.subscribe("missions");
});
Server:
Meteor.publish('missions', function() {
// there are really some filters here, but removed for simplicity
return Missions.find();
});
Template:
<template name="missionList">
<div class="missionList">
{{#each missions}}
{{> mission}}
{{/each}}
</div>
</template>
<template name="mission">
<div class="mission{{#if isSelected}} selected{{/if}}">details</div>
</template>
My requirement is for the Missions.find() in Template.missionList.missions to filter the client-side cached results, rather than to re-request from the server, but I can't seem to find a flag or settings to allow me to tell minimongo to only use the currently available data.
I'm also not entirely sure if this is what I should be doing, I started out just using jQuery to hide the non-selected missions but getting my head round Meteor and it seems a natural fit to use the data and reactivity to drive selection/local-filtering.
Is there any way the roundtrip can be avoided or am I just using it wrong?
By setting up a publish / subscribe relationship, you are creating a simplified form of database replication. Minimongo will have a copy of the data locally and execute the find() locally without a server roundtrip. If you are seeing network activity or calls to the server code, it is because meteor is regularly working behind the scenes to keep the subscription in sync with the server, not for your specific find.
This also means you have to wary of sending too much data to the client, so your server side publish function may want to filter by the specific fields needed by client, in addition to existing your selection criteria.

Resources