Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Parse launches JavaScript SDK: Parse for Websites

blog.parse.com

Post reply on HN
Print view View original

71–80 of 112 posts

Re: Parse launches JavaScript SDK: Parse for Websites

#71

Post by jamesgeck0 »

mortenjorck wrote: post #61
jiggy2011 wrote: post #21

Earlier quoted context omitted.

Yes, this may have been true 10 years ago when installing everything meant getting the source , setting compile flags for everything to work together and updates were applied manually. These days I can have Ubuntu , Apache , PHP5 , Mysql and Wordpress all working happily on a VPS in under an hour. On the other hand there are other considerations like maintenance , security and scaling that it might be nice not to hav…

Well, sure, LAMP is easy to set up if you're working in PHP; that's one of the huge advantages PHP has over most other options. You want to set up and deploy to a Rails server, though, that's going to be a bit more effort.

I've actually had an easier time setting up Phusion Passenger with Apache than I've had setting up PHP. Ease of deployment isn't necessarily a major advantage in PHP's corner anymore.

Re: Parse launches JavaScript SDK: Parse for Websites

#72

Post by rapind »

peripitea wrote: post #52
equark wrote: post #37

Earlier quoted context omitted.

What prevents you from doing this with ajax post on every existing website?

Server-side logic. The difference is that traditional data flow is UserControlledCode (i.e. client-side JS) --> MyServer --> DataStore, whereas this is UserControlledCode --> DataStore. In practice you may often choose not to have the code in MyServer do anything beyond act as a pass-through, but not having that option at all seems scary. The only recourse I see is things like database schema constraints (e.g. max po…

Another way of wording his (and my) concern is how do you securely identify the user? Nevermind the permissions model (ACL), how do you actually ensure the user is who they say they are, and how tamper-proof is this authentication.

Nothing in their documentation provides any details on this. The security section is filled with details on how to specify access levels, but I can't find anything about how they guarantee Fred is actually Fred and not Bob with firebug open.

Re: Parse launches JavaScript SDK: Parse for Websites

#73

Post by jmathai »

reinhardt wrote: post #65
lclarkmichalek wrote: post #54

Earlier quoted context omitted.

This argument applies to all APIs however. And I can't see any reason why Parse wouldn't be "vulnerable" to another service/library with an identical API (in the non-web world, this has happened often).

All proprietary APIs. Also not all APIs are as critical and large encompassing as the whole backend code of your business.

And not all APIs are startups with a decent likelihood of not being around in the future.

Re: Parse launches JavaScript SDK: Parse for Websites

#74

Post by sktrdie »

lclarkmichalek wrote: post #54
clintjhill wrote: post #14

I'm of two minds about this. On one side I think it's a very smart service to use. It removes what otherwise might be a ton of work to duplicate. On the other side I think it's a very dumb thing to be bound to. They certainly free you from their service by allowing an export of your data. But what about all the code written to the API? If at some point in the future you decide you don't want or can't afford Parse - i…

This argument applies to all APIs however. And I can't see any reason why Parse wouldn't be "vulnerable" to another service/library with an identical API (in the non-web world, this has happened often).

His argument was about the fact that you're stuck using their APIs on their servers. This doesn't really apply to all APIs.

With other services you're stuck with their APIs, but at least you can host it on your own server, if the cloud becomes too expensive.

Re: Parse launches JavaScript SDK: Parse for Websites

#76

Post by DrCatbox »

You cant write anything serious with this, for any business processing, where the interesting things happen, you need your own servers, not just storage and you cant trust the clients with your processing needs. For example, make a VPN service out of this, or a file sharing application with payment system?

Re: Parse launches JavaScript SDK: Parse for Websites

#77

Post by lacker »

rapind wrote: post #72
peripitea wrote: post #52

Earlier quoted context omitted.

Server-side logic. The difference is that traditional data flow is UserControlledCode (i.e. client-side JS) --> MyServer --> DataStore, whereas this is UserControlledCode --> DataStore. In practice you may often choose not to have the code in MyServer do anything beyond act as a pass-through, but not having that option at all seems scary. The only recourse I see is things like database schema constraints (e.g. max po…

Another way of wording his (and my) concern is how do you securely identify the user? Nevermind the permissions model (ACL), how do you actually ensure the user is who they say they are, and how tamper-proof is this authentication. Nothing in their documentation provides any details on this. The security section is filled with details on how to specify access levels, but I can't find anything about how they guarantee…

For secure user identification we have the typical username/password model. You don't have to expose that to end users, so you can also cross-authenticate with your own systems. The password is only stored on the server, with a client-side token. There's more documentation for this here:

https://www.parse.com/docs/js_guide#users

It looks like this information is in our "Users" section rather than our "Security" section - we should clean that up in our docs to make it easier to find the right information.

Re: Parse launches JavaScript SDK: Parse for Websites

#80

Post by ryanberg »

rapind wrote: post #72
peripitea wrote: post #52

Earlier quoted context omitted.

Server-side logic. The difference is that traditional data flow is UserControlledCode (i.e. client-side JS) --> MyServer --> DataStore, whereas this is UserControlledCode --> DataStore. In practice you may often choose not to have the code in MyServer do anything beyond act as a pass-through, but not having that option at all seems scary. The only recourse I see is things like database schema constraints (e.g. max po…

Another way of wording his (and my) concern is how do you securely identify the user? Nevermind the permissions model (ACL), how do you actually ensure the user is who they say they are, and how tamper-proof is this authentication. Nothing in their documentation provides any details on this. The security section is filled with details on how to specify access levels, but I can't find anything about how they guarantee…

This has always been my concern (perhaps naive) with any (not just this) javascript SDK. It seems that it would be very easy, and almost inviting, for a malicious user to script a spam attack using the javascript console in their browser, and perform a large number of inserts to the database before you can detect this and disable their account.

Are there common javascript development practices or conventions to prevent malicious users from writing an infinite loop (as pseudo-coded in the post above) and spamming your data set?

Post reply on HN