Meteor releases authentication, accounts system, and new screencast | Hacker News Reader

Meteor releases authentication, accounts system, and new screencast

meteor.com

269 pointsdebergalis65 comments

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.

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.

> Furthermore, nothing can protect you if your password is password.

I'm not sure why you threw this line in with the rest of your response. I don't see what point you're making.

What I meant by that is that a brute force offline attack will always succeed if your password is easily guessable regardless of what hashing or password verification protocols are used.

I have an exercise: is it possible to create a javascript file (served over https) that, when included in a non-https HTML page, is able to determine whether any other scripts were included on the page or will be included on the page by a man-in-the-middle?

If this were possible (I suspect it is not), then it might be possible to have secure javascript code running over a non-HTTPS url. (the motivation for this is to have some form of security and still be able to load websockets and make CORS xmlhttprequests to other (non-secure) hosts - with the assumption that these hosts may also be man-in-the-middled). For now, the only alternative is to use something like a packaged app, if you want to make sure your code is actually your code, and still be able to load insecure resources.

It's not possible. What's possible is using a browser extension to verify some of the essential javascript and use that javascript to do further verification.

An attacker can just remove the <script>-tag that points to the HTTS-served verifier.

In general: If the site the user visits is plain HTTP then there's no way to trust the site.

"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."

That's an outright lie. cf. http://opalang.org

But aren't Opa applications written in Opa, not pure JavaScript?

I also have doubts about the effectiveness of their security, so I'd like to challenge that part of the statement too.

From the linked page:

  client function client_function(x, y) { ... }

This seems at least slightly different from "pure javascript". There are more examples on the page, particularly the neat sugar for database stuff.

I don't think it's accurate to say that this is an outright lie.

Opa generates pure JS code, even though it's indeed a variant of JavaScript with some added features (the ones you mention) and some removed. But then, there's also Derby and probably others.

Just curious, as I don't know enough about the two, what makes Opa similar enough to Meteor that the claim "[Meteor is] the only system of its kind in the world" is an outright lie?

The "only system of its kind" seemed broad enough to include Opa, which generates pure JS.

There is Derby, http://derbyjs.com

And Socketstream

Apparently no one noticed that Derby.js has been able to integrate with Everyauth for over a month: https://groups.google.com/d/msg/derbyjs/7VWTclIBEw8/LsOiuvfz...

Derby vs. Meteor (by Derby): http://news.ycombinator.com/item?id=3842525

Full disclosure: I'm not a Derby contributor. I just played with it for some rapid prototyping.

What about nowjs? http://nowjs.com/

Now.js has been abandoned by its authors [0], and bitrot is creeping in. Someone stepped in to maintain it, but has barely touched it ever since [1].

0. https://github.com/Flotype/now/issues/208

1. https://github.com/jameskeane/now/commits/master/

nowjs has no concept of security.

Yeah Derby was doing what Meteor did months before Meteor was started.

SocketStream http://socketstream.com lacks the media blitz, but it provides authentication and integrates with pretty much anything in NPM (one of the stated goals of the author), and still provides all the benefits of a real-time framework like Meteor (for more than a year now)

This is exactly why I love SocketStream. The extensibility of it is great. I can use one of the several thousand existing node modules/libraries and install them easily via NPM. In addition, development has been active and Owen (the lead dev) is extremely responsive to any issues on the GitHub repo.

He recently demo'd SS at LXJS 2012 - worth watching IMO: http://www.youtube.com/watch?v=LOS1lpWXphs

Thanks for the mention. I've just spoken at NodeDublin.com and released the first bit of very early code for SocketStream 0.4: https://github.com/socketstream/socketstream-0.4

It doesn't do much yet, but shows the direction I'm going in: More API based, pipeable Node Streams wherever possible, full npm / Node compatibility. Follow @socketstream for updates.

Also I want to congratulate the Meteor team on their release. Making scalable, reliable realtime web apps is hard and all work in this area benefits the entire community.

i think when they say "only system of it's kind" they mean they are solving all of these problems in different ways than all other systems... everything from rails to django to opa to derby to whatever.

>That's an outright lie. cf. http://opalang.org

While I agree with you wrt to there being other examples, and the original claim was wrong/false, it could be considered presumptuous to label this as 'an outright lie'.

Most people I know, and the internets, seem to agree that lying requires: intent to deceive.

Having chatted with Matt DeBergalis online and in person on occasion, he comes across rather honest in my admittedly subjective opinion (although welcome to hear contrary info). So if we accept that, then it seems unlikely he would intentionally allow the team to spread falsehood knowingly (especially if it's so easily refuted).

FWIW, I think Meteor is cool for certain camps and projects, but I also really like the 'pick and choose' NPM-friendly style of node development (in fact my personal preference at the moment is for an open modular ecosystem vs a monolithic framework with plenty of magic), so it's not like I have any particular emotional investment in saying this, other than to correct the record.

So in conclusion, this does not seem like a totally fair assessment of the author.

(And yes I realized you mentioned no-one by name, but a project website cannot 'lie'. At the end of the day, a person was still responsible for writing those words).

Notwithstanding Hanlon's razor, ignoring the existence of your competitors (Opa, Derby, SocketStream) would be a display of incompetence I don't expect from the Meteor team.

http://opalang.org/

http://derbyjs.com/

http://www.socketstream.org/

And the several years old Jaxer in Aptana IDE.

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).

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.

Agree on all fronts. However, for getting something up and running, MVP, and for 99.9% of sites that don't need to scale past couple-hundred thousand users (just making up a small figure here), this type of solution might be more than sufficient...

I don't know, though, but I do know that I'll keep following the project. They make great screen casts, and have interesting ideas.

I'm really glad auth finally got in this. With the biggest obvious stumbling block knocked off the list, I have some questions;

Is this production ready? Should I be using this for a greenfield project?

What is database access like? Postres, Mysql? SSL connections to mysql?

what's a typical setup/deployment look like?

I agree auth is a huge success, but no alternate DB support is a not starter for most I imagine. Any other non relational DB support would be a huge win, most people that I have talked to are blocked by Mongo's license.

Now I need to ask, what's blocking about Mongo's license?

How in particular are they blocked by Mongo license? It's AGPL but it only applies to changes made to the database source code itself. It doesn't impose any requirements on your application if you are just talking to Mongo over the wire.

It is not unheard of for businesses in both the public and private sector to not allow AGPL code or use of applications released under this license.

For example, I worked at a public library for years, and the policy was no AGPL, even if we had no intention of touching the source. Same for a local university.

[Edit to add anecdote]

I know a few large scale corporations that license Mongo from 10gen including their commercial support. I really don't see any issue here.

http://www.mongodb.org/display/DOCS/MongoDB+Commercial+Servi...

Not all people trying to use meteor have the money for commercial licensing / support.

<sarcasm>Nice to see libraries and local universities are thinking ahead for when they want to modify the source code of their database </sarcasm>

It's an early preview for a reason. That's why auth wasn't in til now. Not because it wasn't planned, but because the product isn't done yet. Wait for 1.0 before you start greenfielding.

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.

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.

Based on the way they were calling all the inserts and and data changing from the command line, it seems like testing wouldn't be difficult.

Agree on the tightly coupled to MongoDB, though. Hopefully by the time it's released there's suport for traditional relational databases.

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?

Not as straightforward as in other more established server-side frameworks, I assume. It's part of the reason I'm reluctant to ditch my server-side framework of choice (Rails) in favor of an all-encompassing solution like Meteor. There are more than just javascript clients that need to access my APIs.

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.

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...

@paulg: "Did anyone else see a fireball heading east over Silicon Valley at 7:44? (Meteor?)"

Nope. That is in reference to an actual, physical event, not a startup. My guess is that it's related to this: http://menlopark-atherton.patch.com/articles/orionids-meteor...

Amusing coincidence then!

Pg had a typo: it should be "Firebase" not "fireball" ;)

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?

Meteor.com runs on meteor, and it survived their own launch, which was bigger than anyone seemed to expect. In practice, that's probably the biggest thing to run on meteor at the moment.

The framework is built around long lived requests, which push data to the client. There doesn't seem to be anything unscalable about that, since Facebook and many other huge sites are doing it.

That essentially leaves node.js and mongo, both of which should lend themselves to scaling pretty well.

I've used the Auth Branch for a few month now. You can see it in action at http://www.classfy.com (P.S: make sure you have the "www", or else you wont be able to access the page)

It's super confusing to have your 'naked' domain and www. subdomain point to different things. Clearly, it also requires you to explain it every time you post somewhere. What's the reasoning behind this?

Does anyone know if the server code is being exposed to the client?

There are 3 types of code. Server only , Client only and both.

Looks like they finally took the suicide joke off their homepage.

it's still blank unless you execute the javascript

I have allowed most connections on NoScript and RequestPolicy in Firefox, but this website shows only the background image. How do they use many APIs or stupid JavaScript snipets to show something about SECURITY?

When all you have is a hammer, everything looks like a nail.

What was the suicide joke?

There was a guy who said something along the lines of "I'm going to slash my wrists if I have to keep doing web development the old way much longer!"

I'm still trying to figure out the difference and advantage to learning this over node.js.

PROS: it reduces the delays you have due to the paradox of choice

CONS: it makes the choices for you

I just like the Velvet Underground reference on the new party app demo.

If the auth is top of the art, why doesn't it have persona? :)

always when i see meteor i think it's the reverse polling comet server i used 2 years ago

Reply on news.ycombinator.com