This kind of thing shouldn’t even be a REST call. Use JSON RPC.
You know how HTTP GET requests are meant to be idempotent?
101–110 of 313 posts
Re: You know how HTTP GET requests are meant to be idempotent?
#102To me this sounds like a CSRF problem. There's no token or session associated with these calls, so a browser was able to inadvertently CSRF the calls. Changing this call to POST or PUT would still leave this API vulnerable.
It's not about access control, it's about the fact that browsers are free to make speculative GET requests whenever they like, and they actively do to pre-fetch pages. His GET end-point was pre-fetched by his browser, activating the door. This would still happen even if there was a token or session associated.
Re: You know how HTTP GET requests are meant to be idempotent?
#103Idempotency might be necessary for GET calls, but it's not sufficient. Imagine he had two separate GET calls (opened/closed): the author would still have the same problem. Browsers assume GET to be safe (non-mutating), and safety implies idempotency.
HTTP GET is nice because you can "debug" via browser. But I don't think it's a good protocol choice for opening/closing doors nor any other service not related to document requests.
I really don’t like that, I prefer debugging with curl which easily supports the other verbs.
Re: You know how HTTP GET requests are meant to be idempotent?
#104Hello! Long-time lurker, and guilty dev behind the garage door. You can see the (broken) code I wrote here: https://github.com/wpearse/wemos-d1-garage-door-wifi I'll get around to fixing it later this week. Also, an apology: I should have used "side-effect-free" instead of "idempotent" in my tweets.
No side effects means no garage door opening or closing. I guess you wanted it to open or close in some cases at least?
Isn't the point of this thread that the OT says that he shouldn't have used GET for this?
Re: You know how HTTP GET requests are meant to be idempotent?
#105Re: You know how HTTP GET requests are meant to be idempotent?
#106Re: You know how HTTP GET requests are meant to be idempotent?
#107Earlier quoted context omitted.
“Toggle” is by definition not idempodent, because you get a different result each and every time. “Open” and “close” are idempodent, but not safe. The result of a GET request should always be idempodent and safe.
GET requests should have no side effects. In other words NOOP is idempotent
Reading from a database isn’t “side effect free”, neither is reading from a mutable variable.
Given that HTTP requests are supposed to trigger database reads that may return a different result after some time, then “side effect free” would indeed be incorrect.
The litmus test is ... does it always return the same output given the same input? If that can change, the it’s not describing a pure function, but a side effectful one.
And the output of a GET request can and does change.
Speaking of which people here aren’t talking of idempotency in a mathematical sense:
f(f(x)) == f(x)
If you really think about it, GET requests aren’t even idempotent ;-)
Re: You know how HTTP GET requests are meant to be idempotent?
#108When I recently added 'click to unsubscribe' functionality to my emails, the URL got wrote out into some logs. Those logs got written to a Slack channel and Slack loves to click any link it sees. Oh, and it doesn't respect robots.txt. But all I saw was every member of my list clicking 'unsubscribe'. It took a good hour to figure out exactly what was going on. Idempotence is not the problem here, by the way. That just…
Actual public Certificate Authorities have done this too.
You request a cert, it's authorized everything seems fine. Except, huh, the guy who was supposed to authorize is off sick today, how did that work? The email to the authorizer should just be sat in his INBOX until he gets back.
Oh - the company's "Malware protection" system automatically dereferenced the "Do you want to issue this certificate?" link from the email and there was no second step. So for affected companies basically anybody could request any certificate in their domains and it would get issued.
As far as I remember nobody has proof any bad guys ever used this, but grey hats posted some fun they had with it. Likewise for a CA that decided to OCR the images from an unco-operative DNS hierarchy that wouldn't provide machine readable data to them. Grey hats obtained domain names that confused the OCR into allowing them to get certs for other people's names. Did any black hats do it? We have no proof.
Re: You know how HTTP GET requests are meant to be idempotent?
#109The intersection of full-stack web devs from the commercial line-of-business world; and hardware/embedded hackers brings a lot of room for accidents IMO. I'm not saying any one of these groups are bad or inept. I'm in the former and completely accept that I'm new to embedded programming. It seems kool and I wanna learn about it. But I can also see the flip side where a hardware hacker sees query strings for toggling…
> Do we expect the embedded guys to grok HTTP/REST?
REST is irrelevant to this; HTTP alone covers the reason why this is bad. So ultimately, the question is: "Do we expect somebody designing an HTTP API to understand HTTP?" I think that's a reasonable expectation. If your embedded guys don't understand HTTP, then get somebody who does understand HTTP to design the API. They don't need embedded experience to do so, they aren't implementing it, just designing it. This isn't a difficult cross-functional intersection, you just don't assign tasks to people who aren't qualified to carry them out.
Re: You know how HTTP GET requests are meant to be idempotent?
#110Two thoughts:
1) Twitter is a terrible medium for anything, let alone posts longer than a sentence.
2) The level of over-engineering tech people readily engage in without a second thought is truly mind boggling.