if(Meteor.isClient) { ... } if(Meteor.isServer) { ... } Does the Meteor compiler somehow split those code blocks into separate files, so that it only serves the client code to the browser? If not, it seems like a pretty bad practice for delivering fast webapps. Edit: In general, Meteor.isServer seems like a great way for developers to shoot themselves in the foot: Dev: Let me just add my $secret in the server-side bl…
"Does the Meteor compiler somehow split those code blocks into separate files, so that it only serves the client code to the browser?" Yes.
Uh, actually, no. And I put together a screencast to prove it.
$ curl https://install.meteor.com | sh I really wish people would stop giving instructions like this. Despite all the focus on web security and sandboxing, we continue to instruct people to run arbitrary code on their user account. People should at least give any shell script they download from the internet a cursory look to see if it's doing what it should be doing instead of blindly executing the response from an H…
Meteor dev here.. We actually think this is more secure, or at least does more to raise awareness about security! We want people to BE AWARE that they're running arbitrary code, secured only by the certificate authorities in their local curl install. Just about every other way of installing software ends up letting the remote run arbitrary code on your machine. The disadvantage of the other approaches is that you don…
Good response. This is not directly related, but wouldn't it be nice to have some sort of convention where install scripts declare the access that they need and people could allow it (or not)? Something like the Unix permissions systems, but more fine-grained. E.g. perhaps a chroot jail with symlinks to the places that you want to give the script access. Indeed, the first run of the script could be to generate the symlink commands you'd need to execute before it really executes. If you don't like the permissions it wants, you just exit the jail, kill the parent process, and move on with your life.
$ curl https://install.meteor.com | sh I really wish people would stop giving instructions like this. Despite all the focus on web security and sandboxing, we continue to instruct people to run arbitrary code on their user account. People should at least give any shell script they download from the internet a cursory look to see if it's doing what it should be doing instead of blindly executing the response from an H…
You're right but this is just kind of a nit-pick. It should be up to the user to decide if they trust the source. The way I see it, it all comes down to the question of do you trust the source. If the source is trustworthy from there you've got to worry about an attacker compromising your trusted source. That happens and it sucks but its life and I for one am not going to stop `gem install`ing and `curl`ing because R…
That being said, you'd be amazed at how many ruby gems are required to run the average nuclear reactor.
Great tutorial! If only there was an easy way to store the entered addresses in a database? Maybe that could be done in the next 5 minutes? :) I've had a few projects which where basically nothing more than just what was in the article. Meteor's builtin deploy and free Mailgun will fit perfect for cases like that.
Anyone who says "5 minutes implementation" to me, get's a nice and sound "GO FUCK YOURSELF" EDIT: Usually it's the business monkey, UX snake oil guys and product leeches that say "Hey, that will only take like 5 minutes, right?"
Because people are always looking for the easy way out. And Meteor wants press.
$ curl https://install.meteor.com | sh I really wish people would stop giving instructions like this. Despite all the focus on web security and sandboxing, we continue to instruct people to run arbitrary code on their user account. People should at least give any shell script they download from the internet a cursory look to see if it's doing what it should be doing instead of blindly executing the response from an H…
Meteor dev here.. We actually think this is more secure, or at least does more to raise awareness about security! We want people to BE AWARE that they're running arbitrary code, secured only by the certificate authorities in their local curl install. Just about every other way of installing software ends up letting the remote run arbitrary code on your machine. The disadvantage of the other approaches is that you don…
Meteor sounded like a really good concept and I wanted to give it a decent shot. However I could not find a getting started project. The ones I found were very trivial and did not go much into details. I couldnt really find a lot of documentation about how to create an app which used 40-50% of the features which will be used by the majority of the crowd. But I will give it another shot and probably write a polls app…
Meteor dev here.. We actually think this is more secure, or at least does more to raise awareness about security! We want people to BE AWARE that they're running arbitrary code, secured only by the certificate authorities in their local curl install. Just about every other way of installing software ends up letting the remote run arbitrary code on your machine. The disadvantage of the other approaches is that you don…
Good response. This is not directly related, but wouldn't it be nice to have some sort of convention where install scripts declare the access that they need and people could allow it (or not)? Something like the Unix permissions systems, but more fine-grained. E.g. perhaps a chroot jail with symlinks to the places that you want to give the script access. Indeed, the first run of the script could be to generate the sy…
The UNIX permission system is ludicrously primitive for this day and age. Check out OLPC's Bitfrost for a more fresh take on the matter:
Unfortunately, it doesn't look like it went anywhere even in the OLPC world... I'm not very familiar with OLPC, but the fact it carries a 2007 timestamp isn't very encouraging. I wonder if it fell victim to the "sugar" watering down of the project :-(
$ curl https://install.meteor.com | sh I really wish people would stop giving instructions like this. Despite all the focus on web security and sandboxing, we continue to instruct people to run arbitrary code on their user account. People should at least give any shell script they download from the internet a cursory look to see if it's doing what it should be doing instead of blindly executing the response from an H…
Meteor dev here.. We actually think this is more secure, or at least does more to raise awareness about security! We want people to BE AWARE that they're running arbitrary code, secured only by the certificate authorities in their local curl install. Just about every other way of installing software ends up letting the remote run arbitrary code on your machine. The disadvantage of the other approaches is that you don…
But then how will he really know it's you, Geoff? ;)
In all seriousness, you should consider posting a response like this in your FAQ/Help and linking at the install tutorial. I'm really sick of this knee-jerk security reaction happening every time someone builds an installer like this.