Please help test Meteor 0.7.1 release candidates

[Emily Stark]

Hi all,

We're gearing up to release Meteor 0.7.1 and would love your help testing release candidates! We've just built RC0, and you can give it a whirl in your apps by running:

    meteor --release 0.7.1-rc0

If you deploy apps to meteor.com hosting using this release, you'll be prompted to create a Meteor developer account. With this release, developer accounts are replacing passwords on `meteor deploy`. (See my earlier email from when we merged to devel for more information.)

Also in this release: lots of oplog and minimongo improvements, client IP and HTTP headers on `this.connection`, and more. See the rough-draft History file for more.

Please let us know how it goes for you! Thanks,

Emily

[Okada]

In template-engine-preview-10.1 I define global helpers:

Handlebars.registerHelper("edit", function (field, options) {...}

that I could use like this:

{{>edit "value" class="myclass"}}

and get the string "value" in field and "myclass" in options.hash.class

In release 0.7.1-rc0 I get this error:

Expecting 'CLOSE', 'ID', got 'STRING'

What is the correct way to define global helpers and how can I pass parameters to them?

[Iain Shigeoka]

Hi,

I tried it out and found a bug in the deploy command (when it's used without an arg) - it dumps a stack trace rather than prints a nice helpful error message:

> meteor --release 0.7.1-rc0 deploy

/Users/ion/.meteor/tools/7dbd16e45f/tools/main.js:956

}).run();

   ^

TypeError: Cannot call method 'indexOf' of undefined

    at qualifySitename (/Users/ion/.meteor/tools/7dbd16e45f/tools/commands.js:28:12)

    at main.registerCommand.name [as func] (/Users/ion/.meteor/tools/7dbd16e45f/tools/commands.js:794:14)

    at /Users/ion/.meteor/tools/7dbd16e45f/tools/main.js:927:23

I deployed an app (the parties example), followed the link to set a password on the meteor website for me developer account, then ran 'authorized --list' and 'deploy' again and both succeeded and neither prompted me for the password. Should they have asked for a password?

Thanks

-iain

[Iain Shigeoka]

Ah, I discovered that you stay/become logged in when you first create your account and setting a password doesn't affect your login state. How long do you stay logged in - does it time out at some point or once you login to a meteor project do you stay logged in until you explicitly logout? Thanks

-iain

> --
> You received this message because you are subscribed to a topic in the Google Groups "meteor-core" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-core/xFmGbAsmIck/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to meteor-core...@googlegroups.com.
> To post to this group, send email to meteo...@googlegroups.com.
> Visit this group at http://groups.google.com/group/meteor-core.
> For more options, visit https://groups.google.com/groups/opt_out.

[Michael Lazarski]

hey,

I wanted to test the rc0 but meteor is hanging here:

http://i.imgur.com/AvJhErF.png

when i go back to to 0.7.0.1 rls everything works fine.

I wanted for about 10 minutes and nothing happened.

Is there a way to make meteor output more? Or how i can debug that now?

Thanks for help

[Okada]

Ok, found detailed documentation in packages/spacebars/README.md.

I'm not sure it was ever supposed to work the way I did. It seems the right way is to pass every parameter as keyword arguments. Spacebar will create a object with the arguments and set it as the data context. I have to use the .. notation in order to get access to the parent data context to do the job, but it should work.

[mk_too]

Small thing.  The deprecation of 'Accounts.loginServiceConfiguration' did not go smoothly.  Once I found and added the new package, 'service-configuration', the old code continued to fail.

This was fixed by replacing the collection 'Accounts.loginServiceConfiguration' lines with 'ServiceConfiguration.configurations'. Not sure if this was necessary since it looked like account-base/accounts-common.js tries to point the old name to the new name. But for me that was necessary to fix it so I thought I would mention it here.

The error thrown is "TypeError: Cannot call method 'remove' of undefined".  Creating a new project adding 'account-base' and 'service-configuration' packages and calling ' Accounts.loginServiceConfiguration.remove( {services: "google"}); ' also throws the error.

[Dirk Stevens]

Hey Emily ...just moved my logic to the shark branch to anticipate shark merge into release - any idea when that may happen?

Can we expect an update shark branch?

[Emily Stark]

Hi Iain,

Thanks for the report about 'meteor deploy' without a sitename -- that should indeed print a nice error instead of a stack trace.

And when you log in with 'meteor login', you won't have to type a password to deploy again, and you stay logged in until you explicitly log out on the command line.

Emily

[Emily Stark]

Thanks Michael -- we'll look into this.

[Emily Stark]

Hello -- is this something that you started seeing specifically after updating to 0.7.1-rc0? As far as I know, there are no changes to `Accounts.loginServiceConfiguration` in this release. Note that `Accounts.loginServiceConfiguration` is defined in a `Meteor.startup` block, so any application code that uses `Accounts.loginServiceConfiguration` has to run after that (e.g., not in top-level code).

Thanks,

Emily

[Emily Stark]

Hi Dirk -- I'm actually not sure! I'll check with Avi or David Greenspan today to see if they plan to merge release-0.7.1 into shark anytime soon.

Emily

[Avital Oliver]

Yeah, we'll merge release-0.7.1 into shark prior to the upcoming blaze-rc0 release.

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.

[mk_too]

Moving the Accounts.loginServiceConfiguration() inside a Meteor.startup() block also fixes the issue. 

Yes, the error only occurred when testing in 0.7.1-rc0.  Reproduction with on new project also runs fine if launched with meteor --release 0.7.0.1.

[David Glasser]

Hi Michael. A couple questions:

(a) When you try running it again (with the --release flag), does it
work this time?
(b) If it doesn't work this time, even after waiting a few minutes...
can you still try going to your app, and seeing if it works? ie, is
it possible that the bug is just "meteor does not properly print the
'your app is started' line", and not that it's actually hanging?
(there's some new clever stuff about how we print lines during
startup, which is why I'm curious.)

> --
> You received this message because you are subscribed to the Google Groups

> "meteor-core" group.

> To unsubscribe from this group and stop receiving emails from it, send an

> email to meteor-core...@googlegroups.com.
> To post to this group, send email to meteo...@googlegroups.com.
> Visit this group at http://groups.google.com/group/meteor-core.

[mk_too]

No.  No changes to error.  It is there if I run with --release 0.7.1-rc0 and not there if I run with --release 0.7.0.1.  Waiting didn't change anything and going to localhost:3000 in the browser also shows the error.

I looked at accounts-base/accounts-common.js in the repositories tagged 0.7.1-rc0 and 0.7.0.1 and the handling of the deprecated Accounts.loginServiceConfiguration have just been moved inside of a Meteor.startup() block.  So as Emily pointed out,  Accounts.loginServiceConfiguration will not work in top-level code.  I think that explains the errors I have seen as well as the fixes. 

cheers,

Mike

[Emily Stark]

Mike -- I think David Glasser was responding to a different user's problem. :)

--
You received this message because you are subscribed to a topic in the Google Groups "meteor-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-talk/xFmGbAsmIck/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meteor-talk...@googlegroups.com.

[Michael Lazarski]

hey Emily and David,

(a) no the browser is wainting for the host but nothing happens

(b) when i restart the app i get: => Starting your app... and firefox/chrome are wainting for the host. When I kill meteor they say that the connection was reseted.

Screenshot: http://i.imgur.com/nEDxb0Y.png

I Hope that helps!

If I can debug it somehow i would like to help!

[Michael Lazarski]

checked it against the shark branch and there is everything okay (Besides that iron router is making problems).

When I wait a little bit longer chrome just goes: No Data received. Error code: ERR_EMPTY_RESPONSE

Am Mittwoch, 19. Februar 2014 02:42:47 UTC+1 schrieb David Glasser:

[Marc d'Entremont]

Hey Michael,

Could the ctrl-c during the upgrade have anything to do with the problem? Maybe the upgrade didn't complete?

Marc

You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.

[Michael Lazarski]

oh hi Marc, (The Room ref. :) )

No the first time it was running for about 20 minutes and nothing happend.

then i went back to the "normal" meteor and it was ready after <1 minuten.

[David Glasser]

Ok, is it possible you can make your project available to git clone so we can test it ourselves?

[Michael Lazarski]

sadly i can't :(

[Emily Stark]

Thanks to everyone who tested out rc0! We just built 0.7.1-rc1. If you haven't tried out the RC yet, please do so with 0.7.1-rc1 instead of -rc0.

If you've already tested your app with rc0, the main change is that we upgraded jquery from 1.10.2 to 1.11.0, so you might want to re-test your app if you use jquery. There are also some small bug fixes in this RC.

Thanks!

Emily

[Emily Stark]

Also: we expect to build another RC relatively soon (tonight or tomorrow); the diff will be mostly developer accounts UX tweaks in the command-line tool.

[Geoff Jacobsen]

Testing is mostly going fine for my two apps.

One problem I found was with .less files:

If you have an empty file, or a file with no css modifications (#id {}) and/or a file with just @import "foo.lessimport"; (the import files are just less rules) 

then meteor silently hangs on start up.

Cheers

Geoff

[Tim Haines]

Hi Emily and Meteor DG,

I just tried running our apps against 0.7.1-rc1.  We have some problems related to the jquery update that we need to fix.  Dropping in jquery-migrate got our app to a loadable state and gave a lot of helpful warnings in the console, but there are still a few problems.   https://github.com/jquery/jquery-migrate/

I noticed a problem with spiderable/phantomjs too, when I was spoofing facebook's external hit user agent*, but didn't dig into that too much.  The error says: "spiderable: phantomjs failed: { [Error: Command failed: ] killed: true, code: null, signal: 'SIGTERM' }"

Apart from the jquery update, the app appears to be working okay.

Tim.

* facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)

On Wed, Feb 19, 2014 at 2:26 PM, Emily Stark <em...@meteor.com> wrote:

[David Glasser]

When you say you had problems relating to the jquery update, do you
just mean "We needed to make changes to our app because of the jquery
update, and the upgrade guide at http://jquery.com/upgrade-guide/1.9/
would have been sufficient to help us do it", or something deeper?

[Tim Haines]

Hey David,

I'm not sure if the upgrade guide is sufficient yet.  I think we'll have a crack at sorting it out in the next day or two and will get back to you.  There's some obvious things that the upgrade guide does discuss, such as $.browser being gone, but there's a couple of other things which I don't understand yet, but suspect they're related to jquery changes.

FWIW, rolling back to 0.7.0.1 fixed the spiderable issues too - so it seems like there is a bug there.

Tim.

[Slava Kim]

Hi Geoff

thanks for the report, this bug is confirmed.

Slava

[Nick Martin]

Hi Tim,

I tried digging in to the spiderable issue you mention, but I wasn't able to reproduce it. Could you provide a little more info on your setup and what you're seeing?

Here's what I did:

meteor --release 0.7.1-rc1 create --example parties

cd parties

meteor add spiderable

meteor

curl "http://localhost:3000/"

- see empty body

curl "http://localhost:3000/?_escaped_fragment_="

- see full body

curl -H "User-Agent: facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "http://localhost:3000/"

- see full body

Thanks,

-- Nick

On Wed, Feb 19, 2014 at 5:32 PM, Tim Haines <tmha...@gmail.com> wrote:

[Tim Haines]

Hi Nick,

It's actually the images that's causing spiderable to choke.

Using your parties step, then:

curl -H "User-Agent: facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "http://localhost:3000/soma.png"

Causes:

 spiderable: phantomjs failed: { [Error: Command failed: ] killed: true, code: null, signal: 'SIGTERM' }

This is with phantomjs 1.9.7 installed via brew.

Tim.

[Nick Martin]

Aha! Replicated and confirmed this is different from 0.7.0.1. Thanks! I'll look into it.

[Tim Haines]

Hey David,

We've updated our app for the new jquery now.  It was reasonably straight forward once Phil (who does most of our UI) got his hand on it.  Now those are fixed, the other odd UI bugs went away too - so all good.

With the exception of spiderable, which Nick has reproduced.

Tim

On Wed, Feb 19, 2014 at 5:41 PM, David Glasser <gla...@meteor.com> wrote:

[Emily Stark]

0.7.1-rc2 is out! Bug fixes:

* The LESS bug that Geoff Jacobsen reported
* Spiderable errors thrown on static assets that Tim Haines reported

If you haven't tested an RC yet, please give your app a whirl using
'meteor --release 0.7.1-rc2'. And if you observed a bug when running
with RC1, we'd very much appreciate if you could verify that it's gone
when you run with 0.7.1-rc2.

Thanks!
Emily

[Tim Haines]

Hey Emily,

I just tried starting 2 apps with this at the same time, and got an odd error.  I'm guessing this may be because Meteor doesn't like running the installation process twice concurrently?  On the third retry it worked fine (after the other install process had finished).

$ meteor --release 0.7.1-rc2 -p 9000

Installing Meteor 0.7.1-rc2:

 * 'meteor' build tool (version 69d805bf1c)

 * Package updates: accounts-ui less oauth webapp

/Users/tim/.meteor/tools/09b63f1ed5/lib/node_modules/fibers/future.js:206

throw(ex);

     ^

Error: ENOENT, no such file or directory '/Users/tim/.meteor/tools/69d805bf1c/.fresh'

    at Object.fs.unlinkSync (fs.js:760:18)

    at Object._.extend._populateWarehouseForRelease (/Users/tim/.meteor/tools/09b63f1ed5/tools/warehouse.js:329:12)

    at Object._.extend.ensureReleaseExistsAndReturnManifest (/Users/tim/.meteor/tools/09b63f1ed5/tools/warehouse.js:85:22)

    at setReleaseVersion (/Users/tim/.meteor/tools/09b63f1ed5/tools/meteor.js:215:19)

    at calculateContext (/Users/tim/.meteor/tools/09b63f1ed5/tools/meteor.js:136:5)

    at main (/Users/tim/.meteor/tools/09b63f1ed5/tools/meteor.js:1439:5)

    at /Users/tim/.meteor/tools/09b63f1ed5/tools/meteor.js:1487:3

Tim.

[Emily Stark]

Hi Michael -- we think this may have been the LESS bug that we fixed
in the latest RC. Can you try running your app with release 0.7.1-rc2
and see if it's fixed there?
Thanks,
Emily

> You received this message because you are subscribed to a topic in the

> Google Groups "meteor-talk" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/meteor-talk/xFmGbAsmIck/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> meteor-talk...@googlegroups.com.

[Michael Lazarski]

hey Emily,

I debuged meteor 

and i found out that the problem was a empty less file

https://groups.google.com/d/msg/meteor-core/xFmGbAsmIck/MgzIjFpVOIAJ

and Slava fixed it :)

But i run rc2 against my project and yes its fixed !

[Donny Winston]

I have an error using `meteor --release 0.7.1-rc2`. It worked fine with just `meteor` moments before...

pushpickup dwinston$ meteor --release 0.7.1-rc2

Installing Meteor 0.7.1-rc2:

 * 'meteor' build tool (version 69d805bf1c)

 * Package updates: accounts-base accounts-facebook accounts-github

   accounts-google accounts-meetup accounts-meteor-developer accounts-oauth

   accounts-password accounts-twitter accounts-ui accounts-ui-unstyled

   accounts-weibo amplify appcache application-configuration

   audit-argument-checks autopublish autoupdate backbone bootstrap

   browser-policy browser-policy-common browser-policy-content

   browser-policy-framing check code-prettify coffeescript

   coffeescript-test-helper cookies ctl ctl-helper d3 deps dev-bundle-fetcher

   disable-oplog domutils ejson email facebook facts follower-livedata force-ssl

   geojson-utils github google handlebars htmljs http insecure jquery

   jquery-history jquery-layout jquery-waypoints js-analyze-tests json jsparse

   less livedata liverange localstorage logging madewith meetup meteor

   meteor-developer meyerweb-reset minifiers minimongo mongo-livedata oauth

   oauth1 oauth2 ordered-dict preserve-inputs random reactive-dict reload retry

   routepolicy service-configuration session showdown spark spiderable srp

   standard-app-packages star-translate startup stylus templating test-helpers

   test-in-browser test-in-console tinytest twitter underscore underscore-tests

   universal-events webapp weibo

=> Using Meteor 0.7.1-rc2 as requested (overriding Meteor 0.7.0.1)

[[[[[ ~/Dropbox/meteor_projects/pushpickup ]]]]]

=> Started proxy.

=> Started MongoDB.

iron-router: updating npm dependencies -- connect...

/Users/dwinston/.meteor/tools/69d805bf1c/lib/node_modules/fibers/future.js:173

throw(ex);

     ^

Error: No element indexed by 1

  at ArraySet_at [as at] (/Users/dwinston/.meteor/tools/69d805bf1c/lib/node_modules/source-map/lib/source-map/array-set.js:83:11)

  at SourceMapConsumer_parseMappings [as _parseMappings] (/Users/dwinston/.meteor/tools/69d805bf1c/lib/node_modules/source-map/lib/source-map/source-map-consumer.js:220:44)

  at SourceMapConsumer.Object.defineProperty.get (/Users/dwinston/.meteor/tools/69d805bf1c/lib/node_modules/source-map/lib/source-map/source-map-consumer.js:160:14)

  at SourceMapConsumer_originalPositionFor [as originalPositionFor] (/Users/dwinston/.meteor/tools/69d805bf1c/lib/node_modules/source-map/lib/source-map/source-map-consumer.js:311:43)

  at SourceMapGenerator.<anonymous> (/Users/dwinston/.meteor/tools/69d805bf1c/lib/node_modules/source-map/lib/source-map/source-map-generator.js:176:45)

  at Array.forEach (native)

  at SourceMapGenerator_applySourceMap [as applySourceMap] (/Users/dwinston/.meteor/tools/69d805bf1c/lib/node_modules/source-map/lib/source-map/source-map-generator.js:173:22)

  at /Users/dwinston/.meteor/tools/69d805bf1c/tools/bundler.js:843:14

  at Function._.each._.forEach (/Users/dwinston/.meteor/tools/69d805bf1c/lib/node_modules/underscore/underscore.js:87:22)

  at [object Object]._.extend.mergeCss (/Users/dwinston/.meteor/tools/69d805bf1c/tools/bundler.js:840:7)

  at [object Object]._.extend.make (/Users/dwinston/.meteor/tools/69d805bf1c/tools/bundler.js:464:12)

  at makeClientTarget (/Users/dwinston/.meteor/tools/69d805bf1c/tools/bundler.js:1701:14)

  at /Users/dwinston/.meteor/tools/69d805bf1c/tools/bundler.js:1757:20

  at Object.capture (/Users/dwinston/.meteor/tools/69d805bf1c/tools/buildmessage.js:191:5)

  at Object.exports.bundle (/Users/dwinston/.meteor/tools/69d805bf1c/tools/bundler.js:1689:31)

  at [object Object]._.extend._runOnce (/Users/dwinston/.meteor/tools/69d805bf1c/tools/run-app.js:396:32)

  at [object Object]._.extend._fiber (/Users/dwinston/.meteor/tools/69d805bf1c/tools/run-app.js:520:28)

  at /Users/dwinston/.meteor/tools/69d805bf1c/tools/run-app.js:340:12

And then, trying just `meteor` afterwards:

Unexpected mongo exit code 100. Restarting.

Unexpected mongo exit code 100. Restarting.

Unexpected mongo exit code 100. Restarting.

Can't start mongod

MongoDB had an unspecified uncaught exception.

This can be caused by MongoDB being unable to write to a local database.

Check that you have permissions to write to .meteor/local. MongoDB does

not support filesystems like NFS that do not allow file locking.

[Emily Stark]

Hi Donny,
Thanks for the report. Would you be able to provide us with a
reproduction? Is your app available somewhere that we can git clone?
Emily

[Donny Winston]

https://github.com/dwinston/pushpickup

[Eric Dobbertin]

Hi Emily,

Testing with rc2, there seems to be a weird issue where some server side `console.log` are not logged or are not logged immediately. Then when one does get logged, sometimes that seems to "kick start" the others and they start appearing, but not always. Also, when I make a change causing a server restart, then some of the missing logs appear in the terminal just before it restarts.

I haven't tried reproducing with a small app, but I can create one if you need me to.

Thanks!

Eric

[Eric Dobbertin]

Hmm, nevermind. It was a combination of confusions on my part. When you call `console.log` in a startup function on the server, the logged info now appears *before* the "=> Meteor server restarted" line in the terminal. Confused me since everything used to appear after that line.

[Geoff Jacobsen]

I can confirm that Donny's issue occurs with both my projects. I'll try and track down the cause...

[Geoff Jacobsen]

I have reduced/simplified the problem down to the following:

client/css/bar.lessimport:

  .bar {

    padding: 0;

  }

client/css/foo.less:

@import "foo.lessimport";

#foo {

  .bar;

}

Hope that helps

Geoff

[Slava Kim]

Thank you Geoff! It will be really helpful!

You received this message because you are subscribed to a topic in the Google Groups "meteor-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-core/xFmGbAsmIck/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meteor-core...@googlegroups.com.

To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.

[Geoff Jacobsen]

oops, that should read @import "bar.lessimport"; not *foo*

[Nick Martin]

Thanks for the reproductions, Donny and Geoff. It's very helpful, and much appreciated!

-- Nick

You received this message because you are subscribed to the Google Groups "meteor-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core...@googlegroups.com.

To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.

[Donny Winston]

Well done, Geoff -- I created a fresh project with just that code and got the same error as I reported above.

[Denis Gorbachev]

I think I've got a bug.

starfall@nx:~/workspace/pintask$ meteor reset --settings settings/dev.json --release 0.7.1-rc2

--settings: unknown option.

Usage: meteor reset

Reset the current project to a fresh state. Removes all local

data.

starfall@nx:~/workspace/pintask$ meteor run --settings settings/dev.json --release 0.7.1-rc2

=> Using Meteor 0.7.1-rc2 as requested (overriding Meteor 0.7.0.1)

[[[[[ ~/workspace/pintask ]]]]]

=> Started proxy.

=> Started MongoDB.     

=> Starting your app...

/home/starfall/.meteor/tools/69d805bf1c/lib/node_modules/fibers/future.js:173

throw(ex);

     ^

Error: No element indexed by 1

  at ArraySet_at [as at] (/home/starfall/.meteor/tools/69d805bf1c/lib/node_modules/source-map/lib/source-map/array-set.js:83:11)

  at SourceMapConsumer_parseMappings [as _parseMappings] (/home/starfall/.meteor/tools/69d805bf1c/lib/node_modules/source-map/lib/source-map/source-map-consumer.js:220:44)

  at SourceMapConsumer.Object.defineProperty.get (/home/starfall/.meteor/tools/69d805bf1c/lib/node_modules/source-map/lib/source-map/source-map-consumer.js:160:14)

  at SourceMapConsumer_originalPositionFor [as originalPositionFor] (/home/starfall/.meteor/tools/69d805bf1c/lib/node_modules/source-map/lib/source-map/source-map-consumer.js:311:43)

  at SourceMapGenerator.<anonymous> (/home/starfall/.meteor/tools/69d805bf1c/lib/node_modules/source-map/lib/source-map/source-map-generator.js:176:45)

  at Array.forEach (native)

  at SourceMapGenerator_applySourceMap [as applySourceMap] (/home/starfall/.meteor/tools/69d805bf1c/lib/node_modules/source-map/lib/source-map/source-map-generator.js:173:22)

  at /home/starfall/.meteor/tools/69d805bf1c/tools/bundler.js:843:14

  at Function._.each._.forEach (/home/starfall/.meteor/tools/69d805bf1c/lib/node_modules/underscore/underscore.js:87:22)

  at [object Object]._.extend.mergeCss (/home/starfall/.meteor/tools/69d805bf1c/tools/bundler.js:840:7)

  at [object Object]._.extend.make (/home/starfall/.meteor/tools/69d805bf1c/tools/bundler.js:464:12)

  at makeClientTarget (/home/starfall/.meteor/tools/69d805bf1c/tools/bundler.js:1701:14)

  at /home/starfall/.meteor/tools/69d805bf1c/tools/bundler.js:1757:20

  at Object.capture (/home/starfall/.meteor/tools/69d805bf1c/tools/buildmessage.js:191:5)

  at Object.exports.bundle (/home/starfall/.meteor/tools/69d805bf1c/tools/bundler.js:1689:31)

  at [object Object]._.extend._runOnce (/home/starfall/.meteor/tools/69d805bf1c/tools/run-app.js:396:32)

  at [object Object]._.extend._fiber (/home/starfall/.meteor/tools/69d805bf1c/tools/run-app.js:520:28)

  at /home/starfall/.meteor/tools/69d805bf1c/tools/run-app.js:340:12

I've got a large application with many dependencies. Is there any advice on how to narrow it down?

Also, note that in "meteor reset" the "data" word is on the next line. Weird.

[Emily Stark]

Hi Denis,

Thanks for reporting back!. The first thing I don't think is a bug;
--settings is indeed an unknown options for 'meteor reset'. Or am I
missing the point?

The second thing "No element indexed by 1" has been reported already;
we're working on it.

Emily

[Denis Gorbachev]

Hi Emily,

Yes, --settings is an unknown option, that's not a bug. Just the "No element indexed by 1" and the minor "'data' word gets carried to the next line".

--

Denis Gorbachev
CEO, Faster Than Wind
http://www.faster-than-wind.ru/
+7 919 968-00-40

[Denis Gorbachev]

For the record: I've removed all empty *.less files (find . -type f -iname "*.less" -empty -delete) and the problem "Error: No element indexed by 1" still persists.

On Thu, Feb 20, 2014 at 10:14 AM, Michael Lazarski <mgol...@gmail.com> wrote:

Hey,

after debugging i found the problem why the app wasn't starting.

when i create a empty .less file and run meteor it hangs on the bundling process.

There must be at least one .class or #id tag in the less file. Something like @base: #f938ab; was still hanging.

I was looking a little bit into and problem is somwhere in the compile-less.js file.

it waits in line 53) var sourceMap = JSON.parse(cssFuture.wait());

I tested that on a new project.

meteor create

meteor add less

mkdir client; cd client; touch empty.less

meteor 0.7.0.1: worked

meteor 0.7.1-rc1: hangs

meteor git devel: hangs

I hope that helps!

--
You received this message because you are subscribed to a topic in the Google Groups "meteor-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-talk/xFmGbAsmIck/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meteor-talk...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Emily Stark]

Thanks Michael. Now that the problem is fixed on 0.7.1-rc2 I don't think we
need any more information about this bug. The fix will make its way
back to the devel branch once as finish the release process.

[Emily Stark]

Hi all,

We've just built 0.7.1-rc3, for your weekend enjoyment. The bug fixes are:

* Fix the crash that Tim Haines reported when you are installing the
same release twice at the same time. This wasn't a regression, but,
hey, David Glasser fixed it anyway.

* The less source maps bug ("No element indexed by 1") should no
longer prevent your app from bundling or running. Slava thinks this
might be a less or source-maps bug on certain files, so for now we're
just ignoring source maps that fail to be applied.

If you haven't tried the RC yet, please run your app with 'meteor
--release 0.7.1-rc3'.

Thanks,
Emily

[Denis Gorbachev]

Hi Emily,

I confirm: 0.7.1-rc3 works fine. Thank you!

--
You received this message because you are subscribed to a topic in the Google Groups "meteor-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-talk/xFmGbAsmIck/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meteor-talk...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Aaron Judd]

I can confirm that RC3 is working with our app (reaction-commerce).  We were getting the error  ("No element indexed by 1")  in RC2 as well.

[emgee3]

Any suggestions for this error message:

205:textomatic mg$ meteor --release 0.7.1-rc3

=> Using Meteor 0.7.1-rc3 as requested (overriding Meteor 0.7.0.1)

[[[[[ ~/Meteor/textomatic/textomatic ]]]]]

=> Started proxy.

=> Started MongoDB.     

W20140221-21:44:28.209(-8)? (STDERR) 

W20140221-21:44:28.315(-8)? (STDERR) /Users/mg/.meteor/tools/37d30283b6/lib/node_modules/fibers/future.js:173

W20140221-21:44:28.315(-8)? (STDERR)            throw(ex);

W20140221-21:44:28.315(-8)? (STDERR)                  ^

W20140221-21:44:28.315(-8)? (STDERR) Error: Can't call yield in a noYieldsAllowed block!

W20140221-21:44:28.317(-8)? (STDERR)     at Function.Fiber.yield (packages/meteor/fiber_helpers.js:11)

W20140221-21:44:28.317(-8)? (STDERR)     at Function.wait (/Users/mg/.meteor/tools/37d30283b6/lib/node_modules/fibers/future.js:111:14)

W20140221-21:44:28.317(-8)? (STDERR)     at Object.Future.wait (/Users/mg/.meteor/tools/37d30283b6/lib/node_modules/fibers/future.js:325:10)

W20140221-21:44:28.317(-8)? (STDERR)     at _.extend.count (packages/mongo-livedata/mongo_driver.js:871)

W20140221-21:44:28.317(-8)? (STDERR)     at Cursor.(anonymous function) [as count] (packages/mongo-livedata/mongo_driver.js:695)

W20140221-21:44:28.318(-8)? (STDERR)     at null.<anonymous> (app/server/server.js:56:29)

W20140221-21:44:28.318(-8)? (STDERR)     at Object.Meteor._noYieldsAllowed (packages/meteor/fiber_helpers.js:15)

W20140221-21:44:28.318(-8)? (STDERR)     at null._func (packages/deps/deps.js:290)

W20140221-21:44:28.318(-8)? (STDERR)     at _.extend._compute (packages/deps/deps.js:151)

W20140221-21:44:28.319(-8)? (STDERR)     at new Deps.Computation (packages/deps/deps.js:81)

=> Exited with code: 8

A cursory looking around only resulted it a 0.5.0 bug.

[James Gill]

I gave rc3 a quick smoke test, and the standard flow is working as normal.  I'll examine it more thoroughly later, but good job so far!

James

[David Glasser]

Deps is not supported on the server.

If it happens to work for you, great, but it's not expected to.

Notably, the deps code has never been safe if the computation yields (as cursor.count does on the server). In 0.7.1 trying to do this throws,  instead of behaving unpredictably.

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.

[emgee3]

Thanks David! I had a Meteor.autorun(... instead of a Meteor.startup(... 

Whoops. Amazing it ever worked.

[Aaron Judd]

On the just released version: Release 0.7.1.1

meteor whoami,login,deploy etc all give:

/Users/aaronjudd/.meteor/tools/8d9edffd4f/lib/node_modules/fibers/future.js:154

throw new Error('Future resolved more than once');

     ^

Error: Future resolved more than once

    at Object.Future.return (/Users/aaronjudd/.meteor/tools/8d9edffd4f/lib/node_modules/fibers/future.js:154:10)

    at /Users/aaronjudd/.meteor/tools/8d9edffd4f/tools/files.js:483:20

    at ChildProcess.exithandler (child_process.js:641:7)

    at ChildProcess.EventEmitter.emit (events.js:98:17)

    at maybeClose (child_process.js:743:16)

    at Socket.<anonymous> (child_process.js:956:11)

    at Socket.EventEmitter.emit (events.js:95:17)

    at Pipe.close (net.js:466:12) 

[Emily Stark]

Hey Aaron,

Thanks for the report! There's a clear bug in error handling here (which I fixed on devel), but we'd like to figure out why there's an error in the first place.

Can you tell me what OS you're running on? It would also be helpful if you could run the following commands and tell us what the output is:

* If you're on a Mac: `scutil --get ComputerName`

* `hostname -s`

* `hostname`

Thanks,

Emily

--
You received this message because you are subscribed to a topic in the Google Groups "meteor-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-talk/xFmGbAsmIck/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meteor-talk...@googlegroups.com.

[Shawn Lim]

hey emily, i'm getting a strange minimongo error on my client side console. it doesn't really break my app though but i just wanna raise the issue just in case its something critical:

1. 
   Uncaught MinimongoError: Mod on _id not allowed minimongo.js:53
1. MinimongoErrorminimongo.js:53
2. (anonymous function)modify.js:51
3. _.each._.forEachunderscore.js:113
4. (anonymous function)modify.js:43
5. _.each._.forEachunderscore.js:113
6. LocalCollection._modifymodify.js:36
7. LocalCollection._modifyAndNotifyminimongo.js:758
8. (anonymous function)minimongo.js:675
9. LocalCollection._eachPossiblyMatchingDocminimongo.js:562
10. LocalCollection.updateminimongo.js:670
11. self._connection.registerStore.updatecollection.js:146
12. store.(anonymous function)livedata_connection.js:410
13. (anonymous function)livedata_connection.js:1037
14. _.each._.forEachunderscore.js:105
15. (anonymous function)livedata_connection.js:1036
16. _.each._.forEachunderscore.js:113
17. _.extend._livedata_datalivedata_connection.js:1033
18. Meteor.default_connection._livedata_dataddp_update.js:55
19. onMessagelivedata_connection.js:225
20. (anonymous function)stream_client_sockjs.js:166
21. _.each._.forEachunderscore.js:105
22. self.socket.onmessagestream_client_sockjs.js:165
23. REventTarget.dispatchEventsockjs-0.3.4.js:87
24. SockJS._dispatchMessagesockjs-0.3.4.js:1072
25. SockJS._didMessagesockjs-0.3.4.js:1130
26. that.ws.onmessagesockjs-0.3.4.js:1277

[David Glasser]

Hmm. That shouldn't happen. Can you open your dev console, go to the
network tab, find the websocket (it's the one that's 101 Switching
Protocols), click the "frames" header, and email me everything you
can? (You may need to hit reload after opening the network tab to see
the websocket.)

> You received this message because you are subscribed to the Google Groups
> "meteor-core" group.

> To unsubscribe from this group and stop receiving emails from it, send an

> email to meteor-core...@googlegroups.com.
> To post to this group, send email to meteo...@googlegroups.com.
> Visit this group at http://groups.google.com/group/meteor-core.

[Shawn Lim]

hey David, 

ok i've replied you. lol my first time replying directly in gmail so i don't know if you received. :P

[Aaron Judd]

Emily,

OSX (10.9.1)

scutil --get ComputerName

  ComputerName: not set

hostname -s :

  MacBookPro-28CFE912E517-2

hostname

  MacBookPro-28CFE912E517-2.local

[Aaron Judd]

Emily,

Based on your question (and my answer), It was a surprise to me that the computer name wasn't set (new MBP,um, no excuses I guess). 

Guessed where you were going with this, so I set the computer name in preference sharing, and voila! Meteor login,etc worked.  

[David Glasser]

OK, the suspicious thing here is ddp_update.js in your stack trace.
This is part of Arunoda's fast-render Atmosphere package, which
overrides core's Meteor.default_connection._livedata_data function. I
think you need to report a bug against fast-render that it should
start being careful not to put _id into the 'fields' that it
generates.

On Mon, Feb 24, 2014 at 9:23 PM, Shawn Lim <shawn.l...@gmail.com> wrote:

> You received this message because you are subscribed to the Google Groups
> "meteor-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to meteor-core...@googlegroups.com.
> To post to this group, send email to meteo...@googlegroups.com.
> Visit this group at http://groups.google.com/group/meteor-core.

[Emily Stark]

Thanks so much, Aaron! That was really helpful. Indeed, it looks like scutil exits non-zero when ComputerName isn't set, and our buggy error handling failed to handle that error properly and move on to trying `hostname`, as it's intended to.

The good news is that the fix is on devel already and, as you pointed out, there's an easy workaround (set the computer name). We'll get the fix out in a point release soon.

Emily

[Arunoda Susiripala]

I've just fixed that issue with FastRender. Now it should with Meteor 0.7.1. I just published a new version.

--
Arunoda Susiripala

@arunoda

https://github.com/arunoda

http://www.linkedin.com/in/arunoda

[Geoff Jacobsen]

I also get "Uncaught MinimongoError: Mod on _id not allowed" in my apps.

You received this message because you are subscribed to a topic in the Google Groups "meteor-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-core/xFmGbAsmIck/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meteor-core...@googlegroups.com.

[Arunoda Susiripala]

Are you using fast-render? If so update it now.

[Dave Workman]

It's awesome that the positional operator now works, this is the ONE feature that was keeping me from doing all of my mongo updates through mini-mongo. But because of a check for the selector in an update statement to only make reference to the _id it's not possible to utilize it.

When attempting to do an update like so:

students.update( { _id: '1', grades: 80 }, { $set: { "grades.$" : 82 } } )

I get the following error: 

Not permitted. Untrusted code may only update documents by ID. [403]

Which I'm kind of puzzled by, unless there's some edge case I'm unaware of, as long as _id is present in the selector, and is either an ObjectID or string or number, it's only going to match that one document.

One other thing I noticed: When trying to test this I copied the example from the Mongo DB documentation. The example they give uses a number as the _id. I wasn't able to get mini-mongo to take a number as a _id, but updating and finding an existing document with a number as an _id gave no warning and worked as expected.

[Dave Workman]

Second parameter in an update allow rule use to be the the document that is being edited, sent through it's transformation function. It's no longer transformed. On insert it is still transformed. I did not test remove.

[David Glasser]

You cannot run an update on the client that has a non-ID selector, but you can write a method with that in its body and invoke it from the client.

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.

[David Glasser]

Can you file this as a github issue with a full reproduction? See https://github.com/meteor/meteor/wiki/Contributing-to-Meteor

--
You received this message because you are subscribed to the Google Groups "meteor-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core...@googlegroups.com.

To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.

[Shawn Lim]

thanks arunoda and david. works now no errors.

[David Glasser]

Also, using numbers as _id should work in minimongo. (Though it's
actually a different _id from the same number as a string!) If you
find that this doesn't work, file an issue with full git clone
reproduction.

> --
> You received this message because you are subscribed to the Google Groups

> "meteor-talk" group.

> To unsubscribe from this group and stop receiving emails from it, send an

> email to meteor-talk...@googlegroups.com.

[Dave Workman]

As I said in my original comment, I've been using the positional operator on the sever in a method.

Please read what I'm saying this time. The following is the only way I know of to use the positional operator, you need to specific some selector logic for which array index to modify:

students.update( { _id: '1', grades: 80 }, { $set: { "grades.$" : 82 } } )

I wouldn't say the above is a "non-ID selector".

Unless there's some edge case I'm unaware of, as long as _id is present in the selector, and is either an ObjectID or string or number, it's only going to match that one document. So why are you limiting the selector to only be allowed to specify the _id and no other keys?

[David Glasser]

This is for security reasons. Allowing untrusted code (ie, client
code, not method code) to use arbitrary selectors in an update lets
them do things like:

c.update({_id: 'some ID', 'some.secret.token': /^[a-m]/}, {$set:
{'profile.matches': true}});

and basically read any data from the database. The security design of
Meteor is that server-side reads should be restricted to the queries
in your publishers and methods, not arbitrary queries from users.
Yes, we could add a complex system to allow/deny rules to let you
carefully whitelist selectors, but writing that code securely is much
more difficult than just adding one-line methods that do the updates
you want. (By putting the method definitions in files that are on
both client and server, you continue to get the full effects of
latency compensation.)

If you're telling me that the update you describe does not work
*inside a method*, then that is a big surprise. Please report that
bug using the instructions in
https://github.com/meteor/meteor/wiki/Contributing-to-Meteor#reporting-a-bug-in-meteor
--- ie, I need a full reproduction that I can clone, not just a
single line of code.

[Dave Workman]

I'm confused, what's the difference between:

  c.update({_id: 'some ID', 'some.secret.token': /^[a-m]/}, {$set: {'profile.matches': true}});

and

  c.update({_id: 'some ID'}, {$set: {'profile.matches': true}});

I'm saying the update doesn't work in mini-mongo, which is run on the client. Nothing about the server, I don't know where you thought that, I wouldn't get an untrusted code error on the server. So basically what you're saying is there will NEVER be support for the positional operator on the client? (to operate on a collection that is persisted to the server).

[David Glasser]

You are correct.

We used to support arbitrary selectors in client->server untrusted
updates and removes. We removed this support in Meteor 0.5.8 for the
aforementioned security reasons.

There really is a difference between "being able to discover whether
or not a document exists matching a given ID" and "being able to
discover whether or not a document with a given ID matches an
arbitrary Mongo selector".

Writing `Meteor.methods({updateGrade: function (id, from, to) {
students.update( { _id: id, grades: from }, { $set: { "grades.$" : to
} } ); }});` and `Meteor.call('updateGrade', '1', 80, 82)` really
isn't that hard, and it eliminates an unfortunate class of security
holes.

[David Glasser]

Note that minimongo itself does support '$', so you can use it with
`new Meteor.Collection(null)`, and also it will work inside method
stubs, like the one in my previous message. You just can't, in
Meteor's default configuration, send an RPC from the client to the
server with an arbitrary query in it.

That said! If you really want to open up a big security hole in your
app (maybe just as a convenience during development to run such things
from the console) you can always also write:

Meteor.methods({
updateStudents: function (selector, modifier, options) {
students.update(selector, modifier, options);
}
});

and run `Meteor.call('updateStudents', { _id: '1', grades: 80 }, {
$set: { "grades.$" : 82 } })`

We're just not going to put that security hole into every Meteor app by default.

[David Greenspan]

Dave,

In case there's confusion on this point, when you call a method on the client that writes to a server-persisted collection, the method runs both on the client (against minimongo) and on the server (against the real database).  This is Meteor's latency compensation feature, which works by "simulating" the write on the client and then reconciling it with the results from the server.  So the new minimongo features apply to client-side simulations (a.k.a. method stubs), as well as collections that aren't server-persisted.

You can think of collection.update as a convenient alias for a built-in update method.  However, there are subtle security implications that preclude sending certain queries over the wire, as David Glasser points out.  Putting your update inside a method definition doesn't look that different in your code (except for a few extra lines), but its behavior is radically different because there's no need to send a query over the wire, only the name of the method.  We expect that as an app matures, it will move towards using methods for many things, because they are more flexible and also create an API between client and server.

Hope this helps.  Glasser knows more about this stuff than I do, but I just wanted to contribute my perspective.

-- David

You received this message because you are subscribed to the Google Groups "meteor-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core...@googlegroups.com.

To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.

[Geoff Jacobsen]

On 25 February 2014 21:50, Arunoda Susiripala <arunoda.s...@gmail.com> wrote:

Are you using fast-render? If so update it now.

Thanks Arunoda! 

I'm not using fast-render but your patch helped me fix my problem :)

[Dave Workman]

I know it's not hard to write. Again, I've done that in places where I need to use the positional operator already (I think that's the 4th time I've said that). But you have to remember to check security permissions in each meteor method you write, where as if it was executable in the client, it's caught by the allow/deny rules.

Thank you for the explanation, I understand the security concern now, a user knows the ID of a document, because they get a error when they attempt to update it. When they start adding more than the _id they can determine the value of a property by checking if they get an error or not, right?

I'm assuming that when you determine whether to send a query through the allow/deny you look up the document first to see if it exists, could you not simply lookup the the document by the _id that was supplied, ignoring anything else that was supplied in the selector, then running it through allow/deny, then do the update with the whole selector that was passed? Doesn't that fix the security hole?

I'd be happy to contribute the best I can with a PR if it helps. I'd really like to get it so all my server side database security checks are in allow/deny, and this is the only thing standing in the way of that. If there's more to it I'd love to discuss it & learn.

[Dave Workman]

Thanks that helps quite a bit actually, I never really understood how the Meteor.methods worked on the client and it's purpose so that helps quite a bit. One of the things that really drew me to Meteor was the fact that the database was entirely on the client and how simple the allow/deny security was to control the actions of that local database, and to be told that the way my entire app is written should be converted to glorified ajax calls and should stop using the local database kind of sucks.

[softwarerero]

I get this error when issuing mrt:

  While building the application:
  error: circular dependency between packages service-configuration and accounts-base

Everything is fine with 0.7.0.1.

I do not know how to debug this, several of my packages do not show up in smart.json or smart.lock, so I am not sure what packages I use to start with. ServiceConfiguration seems to be new but undocumented.

[David Glasser]

Yes, it still uses the local database. It just doesn't allow anyone
in the world to run arbitrary selectors against your remote database.

And again: if you want to re-introduce the security hole for your app
(and I totally agree that it's really convenient to be able to run
arbitrary update/removes from the browser console during development),
it takes one line to add a generic method that takes
selector/modifier/options as an argument and restores the old insecure
behavior. You could even make an Atmosphere package that does this
for all of your packages. But we're not going to do this in core.

--dave

[David Glasser]

Can you report this with a reproduction?
https://github.com/meteor/meteor/wiki/Contributing-to-Meteor#reporting-a-bug-in-meteor
(If necessary, the repository can be private and you can give me
permission to look at it.)

Have you forked the service-configuration or accounts-base packages
(ie, are there directories of that name in your app's "packages"
directory)?

[El Softwarerero]

Your question let me to the solution. I had to delete the accounts-base package in my packages
directory which was left over from former experiments.

[Dave Workman]

No response to this? I'd like to know more about the security hole more than "there is one":

I know it's not hard to write. Again, I've done that in places where I need to use the positional operator already (I think that's the 4th time I've said that). But you have to remember to check security permissions in each meteor method you write, where as if it was executable in the client, it's caught by the allow/deny rules.

Thank you for the explanation, I understand the security concern now, a user knows the ID of a document, because they get a error when they attempt to update it. When they start adding more than the _id they can determine the value of a property by checking if they get an error or not, right?

I'm assuming that when you determine whether to send a query through the allow/deny you look up the document first to see if it exists, could you not simply lookup the the document by the _id that was supplied, ignoring anything else that was supplied in the selector, then running it through allow/deny, then do the update with the whole selector that was passed? Doesn't that fix the security hole?

I'd be happy to contribute the best I can with a PR if it helps. I'd really like to get it so all my server side database security checks are in allow/deny, and this is the only thing standing in the way of that. If there's more to it I'd love to discuss it & learn.

[Nick Martin]

This is not sufficient to close the hole in the case where the user is allowed to write to part of a document.

See https://groups.google.com/d/msg/meteor-talk/qUa3clv4g5E/N7F8IaAX5AgJ for details.

-- Nick

[Eric Dobbertin]

I had a thought on this issue of non-ID selectors. (Just so happens I wanted to use one today, too.) I might be missing something, but wouldn’t the following work:

1. Allow any selectors in minimongo, but continue to require that _id be one of them and continue to disallow `multi`.

2. Add a boolean option to the collection constructor, `allowNonIdSelectors`. Default to `false`, of course. Document the security implications of using it.

3. If `allowNonIdSelectors` is falsy on the client, throw the same error as now.

4. When non-ID selectors come over the wire, first check that `allowNonIdSelectors` is true for that collection (before allow/deny). If not true, throw access denied error.

This would keep the safe mode as the default, but allow careful developers to flag certain collections as containing no data that is of security or privacy concern. I agree with the need to have the defaults be as secure as possible, but since a couple workarounds have already been mentioned, I’m thinking why not have an option that at least avoids potentially even less secure workarounds?

Thanks,

Eric

You received this message because you are subscribed to a topic in the Google Groups "meteor-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-talk/xFmGbAsmIck/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meteor-talk...@googlegroups.com.

[David Glasser]

This sounds like a great package. Again, it takes one line to define
a method that lets you run arbitrary updates and removes.

[Dave Workman]

Thanks for the details.

I have another proposal, if there are more keys than the positional operator in the selector, check that the key that's being used exists in the update statement as well. That way they'd need to have rights in the allow/deny rules to modify that key. Still doing what I suggested before, checking for the document by only the _id before the allow/deny rules so that if a document doesn't exist with the selector they gave but does with only the _id, they wouldn't know.

Here's a gist of one way to accomplish this.

It's completely untested, but you get the idea. Maybe instead of recursion it JSON stringifys the update statement and regexes it to determine if the keys in use. Or maybe you check the modifiers that it's able to be used under ($set, $inc etc), I've addressed all of the security holes outlined in the link you've provided me (at least I think) with a relatively small change to core.

-Dave