They are not safe for spaces in paths. There might be other places to look for trouble.
I've run the following command to produce this commit: (on OS X, copy-and-pasting the below exactly)
find . -type f -name '*.sh' -print0 | # Find all .sh files
xargs -0 fgrep -H -- '`' | # See all places with backticks in them
fgrep 'cd `dirname $0' | # I deemed these problematic (variable assignments are safe)
cut -d ':' -f 1 | # Take the <file> from <file>:<line> produced by "grep -H"
tr '\n' '\0' | # Also here, spaces can be problematic - always do "xargs -0"!
xargs -0 -- sed -i '' 's/cd `dirname $0`/cd "`dirname "$0"`"/g'
The significance of adding the two levels of "'s can be verified by running the following in your Terminal:
$ node -e 'console.log(process.argv.splice(1))' -- `echo 1 2`
[ '1', '2' ]
$ node -e 'console.log(process.argv.splice(1))' -- "`echo 1 2`"
[ '1 2' ]
$ node -e 'console.log(process.argv.splice(1))' -- "`echo "1 2"`"
[ '1 2' ]
It was flaky before because template rendered callbacks get called
after flush time, but not if the template got destroyed in the meanwhile.
The way this test was written, if the client managed to respond to the server
rejecting the method before the client's flush cycle, the rendered callback
would never fire. Thus it would hang, since that callback was wrapped
in an expect.
Now we define a method on the client only, which makes it run as a stub
without the server rejecting the method (ever).
Follow-up to 63b3119; further addresses #2095.
There were a few problems here:
- We didn't check that the argument to insert was a document. (EJSON
custom types don't count as documents, because they don't have _ids!)
- The check to see if something coming from the database was an EJSON
custom type didn't match the check in ejson.js (specifically, it was
missing size===2). This made it sort of look like you could use EJSON
custom types as top-level documents, until a change in the MongoDB
driver made made that coincidental almost-working code stop working.
- The replaceNames function wasn't documented as only taking pure JSON,
so it wasn't obvious that "it throws when there's a Buffer" was a bug
in the caller rather than a bug in replaceNames.
This should all be resolved now. Use cases like CollectionFS which were
mislead by these bugs into believing that an EJSON custom type could be
a document should move their custom type into a field.
mongodb 1.4.0-rc9 has a `binId` field of type Buffer on ObjectIDs, which
caused Meteor to crash when retrieving a document that was made up of
just an EJSON user-defined type. (Which should not necessarily be
supported, but `replaceNames` should probably treat Buffers as Arrays
regardless.)
Fixes#2095.
This was a regression in 0.8.1 which caused client-specified `_id` to
always be ignored for collections with at least one allow/deny rule.
Fixes#2097. Fixes#2099.
This was a regression in 0.8.1 which caused client-specified `_id` to
always be ignored for collections with at least one allow/deny rule.
Fixes#2097. Fixes#2099.
Before this, we could see the "non-null user observe" error if:
- One login method ran (eg login) and it called _setLoginToken.
It stored null in userObservesForConnections and gets to the
defer/observe part
- Another login method ran (eg getNewToken) and it called
_setLoginToken. The call to removeTokenFromConnection at the top
clears the null from userObservesForConnections, and it then
stores its own null in userObservesForConnections, and defers
- One of them finishes the observe and puts its observe in
userObservesForConnections, overwriting the null which it thinks
is its alone
- The other one gets there and throws
Also, consistently use _.has when checking if userObservesForConnections
has an element.
We now wait for subscriptions to be ready before calling
methods that affect those collections. Otherwise, when the
callback fires the documents in those collections aren't
guaranteed to be available on the client.
This lets you still use C.insert from the client but reject arbitrary
client-set _id's (as opposed to _id's generated using the Random.id()
algorithm with a client-determined _id).
If you don't want clients to be able to have any control over the _id at
all for inserts, then you'll have to forbid all direct inserts and use
your own methods which explicitly do `C.insert({_id: Random.id(), ...})`
Note that allow/deny rules with transforms still see an _id, because
transforms need to have (and preserve) _id. This means that if you
really want to see the server-generated _id, you can just specify an
identity transform for your allow/deny rule.
Duplicate keys aren't expected, but in case something weird happens,
just override the previous information associated with that key. We
simply insert nothing for non-string keys (e.g. an OAuth flow with no
`state` parameter, which should never happen normally).
