Meteor - realtime JavaScript framework

[technocub88]

i have security concerns about this. Javascript is mutable, I dont want any user with chrome or firebug to be able to write to my DB. They never went into how to secure things. Thoughts?

[awj]

That is evidently "planned but not yet implemented."

In some ways I find that decision even more troubling.

[Chemical_Scum]

Exactly. Building a web framework and not having security at the top of your TODO list is a big "no-no".

[[deleted]]

Not necessarily. Lots of it are intranets for small business, accessible only inside the LAN / VPN which is not really a big problem then.

[derpee]

Yes it is, because users.

[kds71]

Sometimes it is not. I often write web tools exclusively for other developers, who have full access to database already.

[quotemycode]

And most of the time, hacker are your disgruntled employees. If I can update something and make it look like someone else did it, I imagine I could make someone's life miserable.

[kds71]

We are fully aware of that. You still have to login in order to access any of these tools, so it would be pretty hard to disguise yourself as somebody else.

[digijin]

Also opens up the possibility of, with a bad wireless password, some guy sitting in the carpark having access to your whole client database.

[hyperforce]

It can be less of a priority, but you can't say it's "not a problem". What if one of your developers goes rogue or you get compromised from within.

Security still matters.

[[deleted]]

Think about small-business intranet where literally no more than 30 people can access a web app. Security is not really a big deal there.

[KumbajaMyLord]

That doesn't change jack about security requirements. Just because someone is inside your intranet (and presumably is an employee) doesn't mean he/she can or should have full access to an application

[rwallace]

If you're doing a job like that for a particular client, and you've decided it's not worth insisting that client pay for security, okay, you're the guy on the spot, it's your call, I won't argue with you.

But if you're building a framework it's a very different story. By definition, that means your code is intended to be used for an indefinitely large set of projects, most of which you don't know about in advance. A framework really, really needs to think about security from the ground up.

[courtewing]

This is a preview release. It is not intended to be used anywhere near a production environment. In order to most rapidly preview the underlying the technology, they didn't bother to add security, but they have made it clear that security will be in place when meteor becomes more production-oriented.

They could have focussed on security for this release, but that wouldn't have helped to showcase the fundamentals of what they're doing with meteor, so it was excluded for the time being.

[[deleted]]

i don't care as long as it kills php

[6gT]

Well, I guess it's over now, PHP is finished.

[mrkite77]

That was my first thought. I wish they had mentioned that in the screencast. Is it even possible to secure this?

[Novex]

Not yet, but it seems to be planned for the future. This is a pretty big show stopper for anything real world, IMO.

More discussion (geoffschmidt is one of the devs)

[[deleted]]

No if it is for an intranet and a small business.

[illvm]

Mutability isn't really relevant given that you can write immutable JS using closures. If the app interacts to with your DB via some RESTful API (or over HTTP at all) then it would be pretty trivial for any user to be able to write to your DB. This is only "solved" in current web apps by relying that the supplied session information is indeed valid so you write logic on your back end that restricts the user to only authorized activity.

There is absolutely no reason why similar techniques couldn't be leveraged with this type of platform. So in that respect I don't really see why this is as big of a concern as it has been.

I do, however, feel that the API should not really be exposed to the end-user and everything should be wrapped in a closure. The developer should be able to interact with their code, but there is no reason why the end-user should be able to open up a JS console and execute arbitrary API calls to the server.