You know how HTTP GET requests are meant to be idempotent? • Hacker News Board

Re: You know how HTTP GET requests are meant to be idempotent?

#281

Post by wpearse » Tue, May 01, 2018, 8:23 PM UTC

luma wrote: post #191

chaosmonkey wrote: post #182

Earlier quoted context omitted.

I think he only had GET /door/toggle, which cannot be idempotent.

He mentions later in the thread that he doesn't have a sensor to indicate door position, which is going to kill this project and absolutely prevents an idempotent approach. There are a bunch of ways to approach this, most of which are patented by Chamberlain, which is the specific reason you don't find many garage automation solutions sold as a bundle in the US. Typical bolt-on solutions would be a range finder point…

I wasn't looking forward to running cable for sensors (I need two reed switches per door, as the doors can stop half-open). The D1s are at the back of the garage, so maybe 8m of cable per switch and two doors = 30-ish metres of cable? (90 feet?)

Range finder seems like the best idea. I was thinking of mounting it on the door motor and pointing horizontally down the track at a reflector attached to the chain/handle.

I love the idea of putting a D1 in the car. Thanks for the link!

Re: You know how HTTP GET requests are meant to be idempotent?

#282

Post by lisper » Tue, May 01, 2018, 8:31 PM UTC

wpearse wrote: post #29

Hello! 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.

Please, for the love of all that is holy, don't post long-form content on Twitter.

Re: You know how HTTP GET requests are meant to be idempotent?

#283

Post by criddell » Tue, May 01, 2018, 8:43 PM UTC

mistermann wrote: post #261

criddell wrote: post #200

Earlier quoted context omitted.

I don't want to be presented with a confirmation box every time I change something. Nobody reads them - they just click the button that will make it go away.

> I don't want to be presented with a confirmation box every time I change something. That's much broader scope than what's being discussed here. > Nobody reads them - they just click the button that will make it go away. That statement is false. Many people read and care about confirmations. What you're talking about is very specific personal preferences, not what is generally considered "fine".

It's not all that specific. What I'm describing isn't that far off from what Microsoft found when Windows Vista was presenting a lot of UAC elevation prompts.

Re: You know how HTTP GET requests are meant to be idempotent?

#284

Post by wpearse » Tue, May 01, 2018, 8:55 PM UTC

mrdiesel wrote: post #220

This guy is stupid.

You're stupid.

Re: You know how HTTP GET requests are meant to be idempotent?

#285

Post by [deleted] » Tue, May 01, 2018, 9:08 PM UTC

wwweston wrote: post #53

Perhaps we need a specific nomenclature for this sort of case: oddempotent! After all, you get the same state if you do it 3,5,7,9,etc times as if you do it once, right? ;)

[deleted]

Re: You know how HTTP GET requests are meant to be idempotent?

#286

Post by ChristianBundy » Tue, May 01, 2018, 9:21 PM UTC

lisper wrote: post #282

wpearse wrote: post #29

Hello! 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.

Please, for the love of all that is holy, don't post long-form content on Twitter.

> Please, for the love of all that is holy, don't post on Twitter.

FTFY

Re: You know how HTTP GET requests are meant to be idempotent?

#287

Post by thefifthsetpin » Tue, May 01, 2018, 10:02 PM UTC

wpearse wrote: post #281

luma wrote: post #191

Earlier quoted context omitted.

He mentions later in the thread that he doesn't have a sensor to indicate door position, which is going to kill this project and absolutely prevents an idempotent approach. There are a bunch of ways to approach this, most of which are patented by Chamberlain, which is the specific reason you don't find many garage automation solutions sold as a bundle in the US. Typical bolt-on solutions would be a range finder point…

I wasn't looking forward to running cable for sensors (I need two reed switches per door, as the doors can stop half-open). The D1s are at the back of the garage, so maybe 8m of cable per switch and two doors = 30-ish metres of cable? (90 feet?) Range finder seems like the best idea. I was thinking of mounting it on the door motor and pointing horizontally down the track at a reflector attached to the chain/handle. I…

My opener runs a tiny little garage door in parallel with the big door in front of my garage, and monitors the position of the little garage door with simple switches. This is all in the plastic housing that holds the motor. If yours is the same, you might be able to steal the same signal.

Sadly, the little garage door doesn't look like a dollhouse garage door; that'd be too cool. It looks like a wire on a track.

Re: You know how HTTP GET requests are meant to be idempotent?

#288

Post by luma » Tue, May 01, 2018, 10:26 PM UTC

wpearse wrote: post #281

luma wrote: post #191

Earlier quoted context omitted.

He mentions later in the thread that he doesn't have a sensor to indicate door position, which is going to kill this project and absolutely prevents an idempotent approach. There are a bunch of ways to approach this, most of which are patented by Chamberlain, which is the specific reason you don't find many garage automation solutions sold as a bundle in the US. Typical bolt-on solutions would be a range finder point…

I wasn't looking forward to running cable for sensors (I need two reed switches per door, as the doors can stop half-open). The D1s are at the back of the garage, so maybe 8m of cable per switch and two doors = 30-ish metres of cable? (90 feet?) Range finder seems like the best idea. I was thinking of mounting it on the door motor and pointing horizontally down the track at a reflector attached to the chain/handle. I…

You can get commercial Z-Wave tilt sensors for approx ~20USD a piece that will last a year or two on a single battery. With those you can mount them directly to the door (because wireless) but obviously you need a Z-Wave radio on your automation platform for that to work.

In either event, are you sure you need two sensors per door? The garage door can stop at any point, but (to my thinking) it's still only open or closed. If it's open by only a bit, open half way, mostly open, etc... it's all open in my system, meaning someone can get in or out if they want. So limit switches (or whatever) at the closed position can tell you if it's all the way closed or "not closed", which is suitable for automation purposes.

Re: You know how HTTP GET requests are meant to be idempotent?

#289

Post by Willamin » Tue, May 01, 2018, 10:39 PM UTC

wpearse wrote: post #281

luma wrote: post #191

Earlier quoted context omitted.

He mentions later in the thread that he doesn't have a sensor to indicate door position, which is going to kill this project and absolutely prevents an idempotent approach. There are a bunch of ways to approach this, most of which are patented by Chamberlain, which is the specific reason you don't find many garage automation solutions sold as a bundle in the US. Typical bolt-on solutions would be a range finder point…

I wasn't looking forward to running cable for sensors (I need two reed switches per door, as the doors can stop half-open). The D1s are at the back of the garage, so maybe 8m of cable per switch and two doors = 30-ish metres of cable? (90 feet?) Range finder seems like the best idea. I was thinking of mounting it on the door motor and pointing horizontally down the track at a reflector attached to the chain/handle. I…

Why not simply have your webserver remember what state the door _should_ be in? Maybe don't rely on that from a security standpoint (eg. GET /garage/status => "closed, everything is secure"), but I suspect it would work for most situations.

Re: You know how HTTP GET requests are meant to be idempotent?

#290

Post by tialaramex » Tue, May 01, 2018, 10:58 PM UTC

kingbirdy wrote: post #250

tialaramex wrote: post #108

Earlier quoted context omitted.

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 e…

Any chance you could provide articles on these grey hat activities? Sounds interesting

For the OCR one the combination of "WHOIS" and "OCR" found me this thread from 2016 with an incident report from Comodo's Robin Alden:

https://www.mail-archive.com/dev-security-policy@lists.mozil...

Alas I wasn't able to bring to mind a combination of keywords that would find the other incident in public archives, and I know it's from my background reading so it will be before my personal archives of these discussions begin. Sorry.