I’ve preordered “Meteor in Action” by Stephan Hochhaus. Its publication has been delayed, and I’m hoping it’s so that the material reflects changes in the new version of Meteor. Does anybody know?
1 Like
I know. Unfortunately it’s because book publishing has longer lead times and lots of production steps involved. We did not have a chance to update for 1.2. Sorry I couldn’t bring any better news.
But in the bright side, we just signed off on the index, basically the last piece, and send the manuscript to the presses this week.
1 Like
Thanks for your reply; I’m sure it’s mostly the same, so will still be beneficial. Can you post the index here? Since the amazon page doesn’t give any preview that way, I don’t know just what the book covers - I just ordered it in “blind faith” expecting it to be a worthwhile investment.
Check out the book page, which contains some free extracts from the book and the table of contents. Also I think looking at the repos gives you a good idea of what the book covers.
I am sorry, but I am not at liberty to post the index here without permission from Manning. But I expect those resources should suffice to get an overview of the contents.
Vielen dank! Ich warte sehnend darauf, das Buch zu bekommen. Ich habe viel am Internet diesbzg. zu lesen, aber brauche auch etwas gedrueckt fuer die Zeiten wo ich draussen in der Sonne sitzen (und es gibt viele Sonne hier in Kalifornien!)
1 Like
Haha, well done! I am sure you will like the Californian sun as well as our book 
Yes, I’ve been enjoying the California sun (and fog - lived a lot of my life on the coast) on-and-off for 57 years.
BTW, I’ve read chapter 1 and am looking forward to receiving the book to read the rest.
However, I have a question: On page 27, it says, “…you must never put security-related code (like private API keys) into an if (Meteor.isServer) block because doing so may send it directly to the client as well.”
Shouldn’t it be “…if (Meteor.isClient)…”?
The book is correct. If you have a shared (client and server) JS file and you use Meteor.isClient and/or Meteor.isServer then all such code will be on the client and the server.
The only way to prevent code being put on the client is to ensure it is in a server folder (or child of such). Or, of course in a package, target the code specifically to the server.
1 Like
Yes, but it says to “never put” such code in an if (Meteor.isServer) block. Shouldn’t it either be:
“…you must never put security-related code (like private API keys) into an if (Meteor.isClient) block because doing so may send it directly to the client as well.”
-or:
“…you must be sure to put security-related code (like private API keys) into an if (Meteor.isServer) block because doing otherwise may send it directly to the client as well.”
The confusion is that either of these blocks are exclusive to either environment. They are not. The files that contain these blocks are sent to client, server, or both depending on their location in the directory structure. Block conditionals merely prohibit or allow execution in either environment.
The idea is to keep things simple. You are correct that if a file is never sent to the server, then you can “safely” put API keys in a Meteor.isServer() block. However, what’s the point in using such a block if the file is exclusive to the server anyway. All files that go to the server should never contain any private information (such as API keys). Putting things in these blocks is a conditional that gets evaluated at runtime, hence it does not add any security.
Bottom line, everything that should be secure must reside in settings.json or be provided via environment variables upon start of the Meteor server.
1 Like