I know these guys have good intentions, but they seem confused about the guarantees that SRP provides. It does allow the server to verify the user's password without receiving it, but it doesn't help in any was against offline attacks. If the "password" (in this case verifier) database is compromised, the attackers will still be able to brute force the passwords. If they implemented it correctly, they will be salted, but this only makes the attack slower. Furthermore, nothing can protect you if your password is password.<p>Also, I hope that they don't think this removes the need for SSL. It does not. In a web application the server sends the client the javascript to run. A man in the middle can modify it and defeat the whole point of SRP.
"Meteor 0.5.0, available today, allows you to write secure realtime client-server applications in pure JavaScript. It's the only system of its kind in the world."<p>That's an outright lie.
cf. <a href="http://opalang.org" rel="nofollow">http://opalang.org</a>
Basing this on the screencast I think this looks amazing and they seem to be very productive. This said, I am unsure if this would produce codebases that are easier to maintain, since there is not a clear separation of concerns and everything seems to be connected. I think doing client-side JavaScript is hard and messy (even with Backbone or Ember) I could not imagine this would be any easier if I had to handle the backend on the client-side as well (especially a backend that's updated in realtime).<p>This said, maybe the current struggle of the client side is because the data is on the backend and needs to be fetched, updated and handled using a client-server model. With Meteror the data seems to live on the client-side which maybe makes things easier.
I'm really glad auth finally got in this. With the biggest obvious stumbling block knocked off the list, I have some questions;<p>Is this production ready? Should I be using this for a greenfield project?<p>What is database access like? Postres, Mysql? SSL connections to mysql?<p>what's a typical setup/deployment look like?
While I'm not confident that being this tightly coupled to MongoDB is a great (or even a good) idea, I'm really glad to see Meteor get closer to 1.0 especially seeing as it's not another Rails clone.<p>The other concern I have is how testable is a meteor/derby codebase? I don't think I could commit to using something in a team environment without being able to _easily_ test things.
Are Meteor or Derby frameworks to be used on the premise that you have only browser clients? If my Meteor/Derby web app has server component, how easy it is to build native iOS and Android clients to access the same data on the server?
This is a huge milestone for a very, very interesting and ambitious project. I wish instead of nit-picking about the marketing language in a release announcement, people would take a minute to appreciate just how amazing this platform is becoming. Yes, ok, derby.js and socketstream and nowjs and opa and realtime-project-foo and etc, sure, maybe they are awesome too, but so what? Meteor is incredible, and contributing to this rising tide floating all the realtime framework boats. And that is something to celebrate imho.<p>To the meteor team: high five, keep it coming, and thank you!
The other top HN page article today doesn't add to my confidence in MongoDB so more persistence options will be interesting. But still, production ready or not, this can be an excellent MVP creator.
I saw the following tweet from PG within the last hour and wondered if it was a reference to some tech company launch. Then I came here and saw this story. Still not sure...<p>@paulg: "Did anyone else see a fireball heading east over Silicon Valley at 7:44? (Meteor?)"
This looks very interesting, but can anyone tell me how scalable is this? All the examples I've seen are small scale; but can it support, say, 1000 clients? 10_000 ? Higher?
I've used the Auth Branch for a few month now. You can see it in action at <a href="http://www.classfy.com" rel="nofollow">http://www.classfy.com</a> (P.S: make sure you have the "www", or else you wont be able to access the page)