HN user
The Maker Channel Action doesn't support authenticated requests, at least anything beyond something you could send in the URL or body of the message. We do this to prevent people from using it to spoof requests to public authenticated services that might view such behavior as slightly "shady". The Maker Channel is really meant for prototyping and experimenting and so we've limited the capabilities to keep the uses in that realm. Hope that helps!
Not exactly sure what you mean by long-polling in this context. Do you mean a client making calls to the API at regular timed intervals to check the status? Or do you mean the server making calls to an endpoint URI when an event occurs?
Hey azdle, thanks for the question and being honest. Do you mind me asking who you work for? Just curious more than anything.
To answer your questions about the alert code, yes it runs in a sandbox, but we also parse it and take it through a pretty lengthy pre-check process to weed out any code that might cause performance bottlenecks or general security problems.
As for websockets, we actually do support them (well, technically socket.io) but just don't make it very clear in the documentation. If you take a look at our open-source javascript client (https://github.com/buglabs/dweetio-client/blob/master/dweet....) you can see that we're actually using it there.
Hope that helps.
Yeah it's something that is browser dependent. I wouldn't call it a bug, but it is an annoyance. It's a decision we had to make in order to keep Freeboards secure for customers who don't want their data to be seen. But it does require the API to be available in HTTPS as well.
It's something we'll have to fix— maybe an option to turn off SSL for the freeboard, or like you say, create a proxy.
We'll look into it and have a solution soon.
Our core focus is read-only at the moment, but yes, command and control has been very much on our mind for a while and I think is going to be a next logical step. Technically you could implement C&C with a plugin right now, but we want to make it more of first-class feature at some point.
Yeah it's 100% client side.
Check the repository again. I just updated the Readme.md to add some more docs on loading and creating plugins. Let me know if this helps. Thanks!
donatj, I would expect that both of those would work, but I can check into adding this as a feature. A lot of times this is actually an issue with CORS. The API would need to add a CORS header for freeboard.io. Or if the API supports JSONP, you can overcome this without a CORS header.
Will do mate.
Hah! Never thought about it, but you are so right. HTTP is actually an M2M protocol at heart and is by far the most prevalent on the planet...
Right now there is nothing to protect because the API is inherently open (on purpose to make it easy). But next week we will be introducing a security token mechanism to be able to "lock" machines. In this case HTTPS will be important and will be required. So yes, it's coming...
Thanks for the feedback! To be clear, the node.js library is just a client-side library, so it should only be technically running on a single machine in most cases.
Also, we only use socket.io for real-time pubsub, but you could just as easily use a polling mechanism with HTTP to get similar results if you're worried about the performance and overhead it carries.
I think perhaps the most important thing is to be very clear about our goals here. Dweet.io is NOT built for super low-latency pub/sub. IMHO most devices in the future of IOT won't need to communicate to the cloud more than a few times every minute or at the most once per second. For the devices that need low-latency (sub-second) pub/sub, I agree, you should look at other protocols like MqTT. But if I were a betting man, I'd say the vast majority of IOT devices in the future will not need this level of performance to warrant the extra headache.
So let's not a call it a security issue then. Let's call it an "it's too easy to delete" issue. And if that's the case, then that's what we're going for— easy. Remember, if you were truly protecting something that was secure then you would require a security token parameter— which BTW is something we're planning in the next rev, for people who want to protect their machines.
If I was phishing to get you to click on a link to delete a resource, then I would need to know that token, and if I knew that token, then I could just delete it myself. Note that the HAPI spec discourages the use of cookies (which I agree could allow a phishing attack if you were using cookies as a security mechanism).
Yes and if I were a hacker, I could do the same thing with curl. Either way the only person who's likely to do it is someone who is technically savvy.
Seriously? Look at the HTTP protocol and tell me you really believe that.
Their way:
DELETE /something HTTP/1.1
My way:
GET /delete/something HTTP/1.1
Do you really think one is more secure than the other?
Yes this is by design to make it easy. Being able to lock things to make them private is an upcoming feature. No promises, but probably will be available this coming week.
Yeah that's pretty much it. We're not claiming anything earth shattering or new here— just something that is dead simple, and works.
Correct. Damned be the HTTP specs and REST because they are such a pain in the ass :) I built HAPI precisely because the current standards only work in a world where everyone knows how and enjoys using curl. I think you should be able to paste a URL for an API anywhere and it should just work.
For example: Here let me show you how to delete that resource using our API... Oh wait, damn. I can't show you because I have no way of sharing a link with you because it requires the DELETE verb. Just go read this documentation and get back to me when you're done. ;)
Agreed, in the code-readability sense it's a little on the strange side, but I wouldn't call it completely nonsense either. My thinking behind the design was that developers are a lot easier to deal with than end-users/laypeople who you might rely on to help debug things. Besides, it's easy enough to write wrapper functions or use DEFINE (in the case of C/C++) to make the code more code-readability-friendly.
Nothing is perfect for everyone, and I think the response is probably the least important aspect of HAPI. The biggest bang for the buck in my mind is self documenting URLs and support for only HTTP-GET verbs. Just my $0.02 :)
It might seem like it, but it's actually not that different from a lot of REST APIs I know of. Most REST APIs return a status (in our case "this":"succeeded"), and some sort of wrapper for the actual data (in our case "with":{}). The only thing that might be redundant is the "by" property, but I think it's useful to have in cases where you want to make doubly sure that the API did what you thought it was going to do.
Private machines are coming soon...
Basically any device or thing that has an internet connection can publish information about itself so that it can be consumed externally. For example if you had a BeagleBone microprocessor monitoring temperatures and you wanted to share those temperatures with other people or machines on the cloud, you could do it easily with dweet.io. It's basically a really simple pub/sub platform.
You bet, that would also be part of the paid plan.
No promises yet, but we plan on offering paid plans that could offer SLAs on latency. Although I will say we architected it from the get-go to be high throughput and low latency— it's all using redis in-memory on the back-end.
The idea is to keep the basic platform free, but to charge to make devices private (ie writeable and readable with key authentication).
Similar to the github model...
It's socket.io. But we can/will document more on it soon.