DotCloud.js - Access Cloud Services from the Browser(js.dotcloud.com)
js.dotcloud.com
DotCloud.js - Access Cloud Services from the Browser
http://js.dotcloud.com/
4 comments
Hi, I'm one of the developers who's been working on this project at dotCloud, and more specifically on the twitter service. The example you're citing shows what I figured was the shortest way to try out the twitter API integration. And you're absolutely right for saying that as soon as your app goes public, it sucks.
This is why this call only has to be made one time ; the key and secret are then securely persisted into the database and the consumer secret can be ommitted in all subsequent calls. Alternatively, we also provide an API endpoint that you can just curl to provide the consumer key/secret. Our "detailed" documentation (http://js.dotcloud.com/doc.html#c4) is more thorough on that matter.
Hope that answers your question!
Edit: sorry for the late response, happened to be out of town for the last three days. Bad timing. :(
This is why this call only has to be made one time ; the key and secret are then securely persisted into the database and the consumer secret can be ommitted in all subsequent calls. Alternatively, we also provide an API endpoint that you can just curl to provide the consumer key/secret. Our "detailed" documentation (http://js.dotcloud.com/doc.html#c4) is more thorough on that matter.
Hope that answers your question!
Edit: sorry for the late response, happened to be out of town for the last three days. Bad timing. :(
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.
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.
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.
What's the security model?
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.
Another entry into this space. Others include:
Meteor - http://www.meteor.com/ FireBase - http://www.firebase.com Parse - https://parse.com/docs/js_guide
Meteor - http://www.meteor.com/ FireBase - http://www.firebase.com Parse - https://parse.com/docs/js_guide
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...
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...
Flattering that you should compare us to them, but this is an early-stage experiment, and we're not quite sure how it'll play out yet!
CloudMine - https://cloudmine.me/ is similar, but more aimed at mobile...
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.
What browser / OS are you using? I haven't been able to reproduce it yet.
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()
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()
Chromium 18.0.1025.151 (Developer Build 130497 Linux) Ubuntu 12.04
plugins set to click to play
plugins set to click to play
It worked fine for me, what browser you using? I have chrome on a mac.
If anyone has an idea to deal with this, please elaborate.