

DotCloud.js - Access Cloud Services from the Browser - gabrielgrant
http://js.dotcloud.com/

======
ww520
I've looked at the client-side cloud API from time to time and I'm never
comfortable with embedding my key/secret credential in the Javascript code.
Anyone having access to the client code in the browser, which is everyone,
will have access to my secret credential.

If anyone has an idea to deal with this, please elaborate.

~~~
clintjhill
I've thought about this too. For me it's a matter of what somebody really
"gets" with those keys. If I'm compromised by someone whose taken my keys and
programmed a script against my service are they stealing anything? Well if
I've applied some form of ACL and provided some secondary authentication
against data they shouldn't be able to query I should be Ok.

Likewise with user accounts. If they take my keys, and somehow get someones
password they'd have the same access they would otherwise have through the
GUI. If I put user passwords into the code, well yeah that's totally bad on
me.

I don't know. I'm not a security expert, however I've not been able to catch a
problem with this. I'd love to know better.

~~~
joffreyf
I guess one of the most basic problems that could occur is someone using your
keys to make unauthenticated requests and exhaust your rate limit.

------
nodesocket
Another entry into this space. Others include:

Meteor - <http://www.meteor.com/> FireBase - <http://www.firebase.com> Parse -
<https://parse.com/docs/js_guide>

~~~
gabrielgrant
I see there being two, somewhat distinct, categories of players: those with a
realtime-first, focus (Meteor, Firebase and, now, dotCloud.js) and those that
take more of a traditional REST-based approach (Parse, StackMob, Backlift,
etc.).

The later have an easier time integrating into existing client-side frameworks
(Backbone, Ember, Angular, etc), since those mostly seem to be built with a
REST-based model in mind, but it will be interesting to see what patterns
emerge to plug push-based updates into these pull-oriented systems. For
starters, I suspect we'll need the client-side frameworks to clarify the
distinction between the server and client state and the source of changes.
Henrik Joreteg's talk at BackboneConf[1] was good overview of this and other
problems they've run into.

[1]: [https://speakerdeck.com/u/henrikjoreteg/p/real-world-
realtim...](https://speakerdeck.com/u/henrikjoreteg/p/real-world-realtime-
with-backbone)

------
dsk2012
What's the security model?

~~~
joffreyf
Hey, this is a very good question. We're currently working out an auth
solution that we'll implement directly at the transport level. We haven't
figured out every detail yet, but we'll be sure to give more insight on that
matter as soon as possible - we understand how important it is as soon as we
leave the realm of toy apps.

------
trotsky
if you close the video using the (x) on the lightbox the video disappears but
you still hear the audio - you have to navigate off the page to silence it.

~~~
m0th87
What browser / OS are you using? I haven't been able to reproduce it yet.

~~~
pud
I encountered this problem on one of my sites.

The solution was -- rather than using the video player's API to stop or pause
the video -- I had to remove the video entirely from the DOM with
Jquery.remove()

