In my publish methods should I be throwing an error if an unauthed user tries to subscribe to a publication or should i be returning this.ready() . (in coffeescript)
this:
Meteor.publish "secretInfo", ->
return #error(new Meteor.Error(422, "Permission denied")) unless #userId
return Secrets.find({})
or that:
Meteor.publish "secretInfo", ->
return #ready() unless #userId
return Secrets.find({})
The generally accepted solution is the latter:
return #ready() unless #userId
I try to avoid throwing errors in publications because the UI can (depending on how you implemented it) get stuck in a loading state unless your publishers eventually call ready() (either explicitly, or implicitly if you return a cursor or other valid value).
This is also pointed out in the guide:
In the case of a logged-out user, we explicitly call this.ready(), which indicates to the subscription that we’ve sent all the data we are initially going to send (in this case none). It’s important to know that if you don’t return a cursor from the publication or call this.ready(), the user’s subscription will never become ready, and they will likely see a loading state forever.
Related
I have removed the auto-publish package from my Meteor app and I have also created a publication on my server:
Meteor.publish("userData", function () {
return Meteor.users.find(
{_id: this.userId},
{fields: {'profile': 0}}
);
});
As you can see above I have set the profile to 0 which means I would like to exclude it. However...
On my client I have this code:
Meteor.subscribe("userData", (param) => {
console.log( Meteor.users.find(Meteor.userId()).fetch() )
})
and the output still includes the profile:
createdAt: Sat May 19 2018 11:16:25 GMT+0800 (+08) {}
emails: [{…}]
profile: {name: "Second Second"}
services: {password: {…}, resume: {…}}
username: "seconduser"
_id: "ESmRokNscFcBA9yN4"
__proto__: Object
length: 1
__proto__: Array(0)
What's the reason for this?
It is possible that some other subscription has subscribed to the profile field of the user.
You can find out if this is the case by looking at the information sent over the websocket.
Open the debugger,
find a "networking" tab,
find the websocket connection,
find the content or "frames".
There you can see which subs have been made and which updates the server publishes to a collection. See what it looks like without your sub; maybe the user doc is published already.
You see the profile field on the client since you have already edited and thus enabled this special field of the User object while creating or updating user. In order to secure this object from client-side modifications you can deny all writes from the client with the following server-side code.
// Deny all client-side updates to user documents
Meteor.users.deny({
update () { return true; },
});
So, even though the profile field is be available on the client within the Meteor.user() object, no modification can be made by the client.
If it is a custom data that you publish than you can control its exposition in your way. For example, let's assume that we introduce a new field customProfile into the user object, than with the following code, the customProfile will not be visible to the client.
Meteor.publish("userData", function () {
console.log('publishing userData with id', this.userId);
return Meteor.users.find(
{_id: this.userId},
{fields: {'customProfile': 0}}
);
});
You may find more information in the guide.
First of all, make sure whether you want to use Meteor.subscribe() or you want to use this.subscribe(). There is a lot of difference between them.
Meteor.subscribe() will keep subscription undestroyed when you change between screens/routes/UI.
this.subscribe() will have the scope of subscription till the life of Template exists. When you switch to other routes/path/UI, the subscription will be destroyed. This is used in a specific case when you have multiple kinds of subscription among consecutive transitions of the screen and problem occurs for unwanted data shown in UI despite filtering in Collection Query.
For more insight, click here.
Comming to your exact question, well when Meteor knows that you are a valid and logged in user, it sends entire Users specific collection fields _id, emails, profile, username on UI. So, it is recommended that you put only the required data into the User collection. Whether or not you make special kind of subscription to self-data, you will always be able to access your own data on UI, even on production build. You can check by putting console.log(Meteor.user()); in chrome console. This is how Meteor.user() is made, whether you like it or not. It was assumed by MDG (Meteor Development Group) that when the user has logged in, a user can fully access his/her own data at UI as it is safe and valid.
see below image for reference,
I have a publication that returns a cursor that looks like this:
// Publication RETURNS THIS QUERY
Notepads.find({_id: notepadId, $or: [{userId: this.userId}, {'collaborators.userId': this.userId}], archived: false})
As you can see the query is unique to the user since it includes this.userId
I use this.userId in the publication as a form of security. You will only get back data if you are associated with that particular notepad.
In my app, multiple people can collaborate on a single notepad. So to make the observer more reusable will this adjustment help my app?
// Optimized publication
notepad = Notepads.findOne({_id: notepadId, $or: [{userId: #userId}, {'collaborators.userId': #userId}], archived: false})
if notepad?
// Optimized publication RETURNS THIS QUERY
return Notepads.find({_id: notepad._id, archived: false})
else
return
I think this is what observer reuse means. That the publication returns the exact same query for any user that subscribes to it. So is this correct, is this optimization worth the change?
There are problem with your optimized version that is it is not reactive. Because you use Notepads.findOne as a security check to make sure user have access to the document.
Inside publication .findOne is not reactive, say at the time the publication is executed user have no access to the document so nothing is sent to client, then user is added as an collaborator but that makes no change because the publication will re re-run.
Quoting from kadira.io on How Observers are Handled in Meteor:
In order to create identical observers, you need to create cursors
with:
the same collection
the same selector (query)
the same set of options (including sort, limit, etc.)
In your example the selector is not the same for different users.
Selectors are Object Literals and are evaluated before being passed into the .find call. This means that {_id: notepad._id, archived: false} becomes
{_id: 'myNotebookID', archived: false}, or
{_id: 'anotherNotebookId', archived: false}.
As you can see, these are different selectors after you resolve notepad._id, and this happens before being passed to .find().
If your first db query had returned the same notepad because your second user was a collaborator on the first user's notebook, you would end up with the same selector, and a single cursor / observable. However for most apps this is not likely to be common enough to optimise for, especially as (as #Khang points out) you are going to lose reactivity.
So, it's not the same query, it's not going to reuse the observer, and is not worth the change.
Been digging around for a solution but none for Meteor. If any, please let me know. I want to check if a username is already taken.
I understand that this only works on the server side only:
u = Accounts.findUserByUsername('foo');
console.log(u.username); #=> foo
I cant get my head around their pub/sub as I can only see information based on the current user. Is meteor saying that what I want is not possible?
When a user is filling out their details upon registration, I want them to be alerted (as they type) if the username they are using is already taken. But that logic I can easily code but need to know how to talk to the server to tell me the information.
You could write a Meteor method for that:
Meteor.methods({
doesUserExist(name) {
return Accounts.findUserByUsername(name) != null;
}
});
Note that you have to define this method on the server but not on the client (e.g., by defining it in a file inside the server directory). That way Meteor won't try to simulate it on the client (which would fail because Accounts.findUserByUsername is not defined there).
Call the method as the user types:
Meteor.call('doesUserExist', name, function(error, result) {
// `result` is true if the user exists.
});
I understand that when writing code that depends on the collection being loaded into the client minimongo, that you should explicitly subscribe to the collection and pass in the appropriate callback for when it is finished loading.
My problem is that I store a lot of important subdocuments that my page needs to access in the users collection. I am using Meteor Accounts, and am trying to figure out a similar way to wait until the entire logged in user document is available. When using this to test:
console.log(Meteor.user());
the logged in case, it seems like it first registers an object with just the _id, and then sends the other fields later (I know I have to explicitly add other fields to publish from the server beyond email, etc.).
Is there a way for me to wait for the logged in user document to load completely before executing my code?
Thanks!
Deps.autorun (previously Meteor.autorun) reruns when something reactive changes, which might fit your use case:
Client js
Deps.autorun(function () {
if(Meteor.user() {
//Collection available
}
});
If you're using a subscription you can also use its callback. Have a read about it on the docs as you might have to customize it a bit, and remove the autopublish package as well as get your other collections set up to subscriptions
Server js:
Meteor.publish("userdata", function () {
//You might want to alter this depending on what you want to send down
return Meteor.users.find({}, {}});
});
Client js
Meteor.subscribe("userdata", function() {
//Collection available
});
I am trying to implement something like this:
/* We use the command pattern to encode actions in
a 'command' object. This allows us to keep an audit trail
and is required to support 'undo' in the client app. */
CommandQueue.insert(command);
/* Queuing a command should trigger its execution. We use
an observer for this. */
CommandQueue
.find({...})
.observe({
added: function(command) {
/* While executing the action encoded by 'command'
we usually want to insert objects into other collections. */
OtherCollection.insert(...)
}
});
Unfortunately it seems that meteor keeps the prior state of the OtherCollection while executing the transaction on CommandQueue. Changes are made temporarily to the OtherCollection. As soon as the transaction on CommandQueue finishes, the prior state of the OtherCollection will be restored, though, and our changes disappear.
Any ideas why this is happening? Is this intended behaviour or a bug?
This is the expected behavior, though it is a little subtle, and not guaranteed (just an implementation detail).
The callback to observe fires immediately when the command is inserted into CommandQueue. So the insert to OtherCollection happens while the CommandQueue.insert method is running, as part of the same call stack. This means the OtherCollection insert is considered part of the local 'simulation' of the CommandQueue insert, and is not sent to the server. The server runs the CommandQueue insert and sends the result back, at which point the client discards the results of the simulation and applies the results sent from the server, making the OtherCollection change disappear.
A better way to do this would be to write a custom method. Something like:
Meteor.methods({
auditedCommand: function (command) {
CommandQueue.insert(command);
var whatever = someProcessing(command)
OtherCollection.insert(whatever);
}
});
Then:
Meteor.call('auditedCommand', command);
This will show up immediately on the client (latency compensation) and is more secure as clients can't insert to CommandQueue without also adding to OtherCollection.
EDIT: this will probably change. The added callback shouldn't really be considered part of the local simulation of CommandQueue.insert. Thats just the way it works now. That said, a custom method is probably still a better approach for this, it will work even if other people add commands to the command queue, and is more secure.
I'm not sure about your observe behavior but we accomplished the same thing using a server-side allow method:
CommandQueue.allow ({
insert: function (userId, doc) {
OtherCollection.insert(...);
return (userId && doc.owner === userId);
}
});
This is also more secure than putting this logic client side.