New Login Method - blinkpy will stop working May 11th unless fixed!

[fronzbot]

Describe the bug
As of March 30, 2020 (according to the "What's New" section in the Blink App), 2FA will be available for blink. What this means for the blinkpy library is uncertain, but I wouldn't be surprised if current login methods begin to fail. A solution will need to be discovered.

Additional Information
I'm hoping we'll be able to send a REST command with some 2FA code to continue logging in and that we get some sort of long-term token to use (rather than the current ones that expire after ~24hrs) so users don't have to constantly input of 2FA code. But we'll see what the implementation looks like. Even if 2FA is optional, I want this library to work WITH it enabled.

[uvjim]

Received the attached email today. I guess this means I may need to start tracking down the new login process as well. I wouldn't mind quite so much but the Blink IFTTT integration is basic at best and there is no integration whatsoever with SmartThings.

[fronzbot]

Yeah, I just emailed them. Hoping they'll work with us 🤞

Just bought two more XT cameras so I'll feel like a complete idiot if they cut us out now, but (in all fairness) we've been operating under the radar for 3 years

[madshall]

I've emailed them too. I maintain a similar package for nodejs https://github.com/madshall/node-blink-security

[anonymous-one]

Yeah I just got the email too.

Sigh... As the years go by one by one I swap out every one of my iot devices to something that runs locally... All that there is left is the blinks and the neato...

On a brighter note... I did find power cables on my roof about 2 months ago... If all else fails, time to drop the blinks :(

[madshall]

I'm curious if we can get source code or reverse engineer the above mentioned "supported 3rd party integration".

[madshall]

Seems like Blink started issuing app tokens. That's how they integrate with IFTTT. They're using oauth2. If they maintain a white list of supported integration partners redirect urls then it's over.

[fronzbot]

@madshall yeah, that's what I'm guessing they're doing. Which is a shame. Hopefully they'll work with us but I'm not holding my breath

[uvjim]

Not had a chance to look at this project or his other Blink based project but there's a claim on the Blink forums that he now follows the new 2FA login process. It might be of some use. However seems to need a code from an email sent from Blink.

https://github.com/lurume84/bling-viewer

[fronzbot]

Yeah it looks web-based which is probably why he can get away with that. Maybe it's a stop-gap solution here too? For home-assistant it would have to be coded in a way that basically starts to remove yaml support in favor of gui-only config (ugh), but that's a separate issue

[anonymous-one]

I fail to see how having it web based makes any difference as far as blink is concerned.

Assuming the api calls are identical, weather its web based or server side should make no difference to blink (read: their logging).

I took a look at the most recent commit where he added the 2FA support, he is even passing 'his own' identifier in the client parameter of the json string for the auth call. Something along the lines of "desktop".

[fronzbot]

It make a difference in terms of the home-assistant integration

EDIT- currently all login information is stored in a yaml and logging in is done behind the scenes. For 2FA to work with HA, we'd need to display a pop-up or whatever and make sure the underlying code in this library is compatible with that. There's a lot more work there than a simple change and, unfortunately, I'm only one person.

EDIT2- With that said, I'm all ears on how best to approach it. The current login implementation is, quite frankly, kludgy as hell so a tear-down and re-build isn't out of the question

[anonymous-one]

Ah, I apologize.

OpenHAB here with my own bindings.

[fronzbot]

No problem 👍 I'm working on seeing what can be done to add 2FA as we speak.

One thing I'm concerned about is that the old login method would require re-authorization every 24hrs or so. If the same is true here...that might get annoying quick. I'm still hoping Blink will work with us there to come up with a more streamlined approach, but we'll see.

[anonymous-one]

I will never get around to this as with work and the 1.5 year old, there is just no time...

But I recall reading that Blink at one point anyways (currently?) used OpenWRT on the sync module. I do have an extra blink module and was debating taring it apart as the debug headers are visible so getting a console + root would be (have been?) possible.

EDIT : Voila : https://apphelp.immedia-semi.com/en/license/Attribution.html OpenWRT tarball and all :)

[fronzbot]

I feel you. Work+2.5 y/o+1mo old.

And interesting regarding OpenWRT- didn't know that. I'l be honest, though, that's out of my realm of expertise so I wouldn't even know what to do with that 😬

[MisterWil]

It looks like they just moved to a new login endpoint that supports 2FA flow? Is it for sure that the 2FA token expires after 24 hours (requiring re-authentication in HASS once a day), or is it possible one token is expiring after 24 hours but at some point a refreshed token is issued? Is it possible they have a "trust this computer" flag that extends the length of the token?

[fronzbot]

It looks like they just moved to a new login endpoint that supports 2FA flow?

Yes, it appears that's the case. Working on implementing this now.

Is it for sure that the 2FA token expires after 24 hours (requiring re-authentication in HASS once a day), or is it possible one token is expiring after 24 hours but at some point a refreshed token is issued?

The 24hr comment I made was with respect to the current implementation (not 2FA). I don't know how the 2FA implementation works on their end.

Is it possible they have a "trust this computer" flag that extends the length of the token?

Sure, it's possible.

[fronzbot]

Ok, so right now the PR I'm working on works if you receive an email to allow access to a device. It should also allow for 2FA, but I just need to figure out a way to test it (haven't been able to enable it on my account yet) but things look promising.

[swerb73]

Let me know if I can help in some way, including testing from my account? I use about 25 cameras from 4 different sync modules in 2 different locations, so might be a good scenario...

PR?

[anonymous-one]

BTW, I don't see how the 2FA would expire every 24 hours. I mean having to re-enter an emailed code in the app every 24 hours? I don't see them doing that.

BTW : As it stands now (pre 2FA) do the tokens expire in 24 hours regardless of activity? I have my own custom coded interface and frankly, I just renew the token every 6 hours so even though I have been using my script for years I do not know. Eg: does firing off a get / set command renew the token life for another X hours?

[fronzbot]

@anonymous-one I agree, that would be absolutely ridiculous. pre-2FA, yeah, the auth tokens seem to expire every 24hrs. No- only time you can refresh the token is by re-logging in. With this library, Any time you make a request it checks the response and if it receives an "unauthorized" response, it re-logins to refresh the token.

@swerb73 - PR = Pull Request. Basically just a new commit to the repository, but before it's moved to the main branch it's left in a review state (see #242). And I plan on adding some tests and then releasing a 0.15.0 beta within the next couple days (hopefully) for people to test out, so I'll let you know when that's ready!

[fronzbot]

Just released v0.15.0-rc0 to PyPi for anyone that wants to test. Note that if you receive a prompt to enter a key, it can go one of two ways:

1. You get an email asking you to verify your setup. Click "accept" or whatever it is and then go back to your terminal and hit "enter". DO NOT TYPE ANYTHING.

2. You get an email with a pin. Enter this pin and let me know the results. I have been unable to test this functionality so I have NO IDEA if it works.

Thanks in advance for anyone willing to help! And if you don't know how to run this on the command line, a quick start guide is included in the README 👍

[MisterWil]

0.15.0-rc0 worked for me. I also got the email asking to verify a new device when I tested. In the email it said:

Device: Blinkpy
Device Name: *|DEVICENAME|*

I noticed in the api.py file that you're specifying Blinkpy for both the identifier and the name. I wonder if that *|DEVICENAME|* value is a bug in Blink's email?

I would imagine device identifier and device name should be different values, like perhaps the name should be the computer name? It might be a good idea to be able to override the identifier and name with another value, and then anyone using blinkpy as a library can pass in values that are more relevant to the application (like "Home Assistant") so the email the user receives makes more sense.

Just to clear up the confusion:

1. From my understanding, with the legacy login API endpoint, the access token would expire after 24 hours, requiring a new login.
2. The new login API endpoint likely has the same 24 hour expiration of the token, but the FIRST login request requires a second factor (email, or apparently a code) before issuing the token. Once that second factor has been approved then subsequent login requests should succeed without the second factor needing to be re-approved, even after 24 hours. I'm interested to know how often we have to re-approve the 2FA request.

Good work, and thanks for tackling it so fast! :-)

[fronzbot]

Awesome!! And yeah, I was seeing *|DEVICENAME|* too, but in testing I would occasionally get the Blinkpy name set in the api.py file so it appears to be an intermittent issue.

I would imagine device identifier and device name should be different values, like perhaps the name should be the computer name? It might be a good idea to be able to override the identifier and name with another value, and then anyone using blinkpy as a library can pass in values that are more relevant to the application (like "Home Assistant") so the email the user receives makes more sense.

Great minds think alike? I actually just added that today 😁 (still need to merge and make a new release, though): #245

Just to clear up the confusion

Yes to 1. And that sounds right to me for 2.

Basically I think what will happen is this:

1. First time logging in with new endpoints in home-assistant
2. Pop-up configuration in home-assistant to enter PIN (or no pin, in the case of a verification email)
3. Device is now "remembered" by Blink
4. Token-based communication that might still need to be refreshed (but this is handled behind the scenes and was the old step 2 for the legacy login method)
5. Only time re-verification needs to happen is if Blink resets something - ie. your device is "forgotten". My guess this would be no more frequent than every 30 days

[swerb73]

Seemed to work for me as well. I was so excited to try it I forgot to change the blink device_id so the email I received indicated:
Device: Blinkpy
Device Name: |DEVICENAME|

Question - should I consider updating it, do we think it matters?

Thus I just hit enter and it seemed to work. The key will be after the 11th when they told me "script" would be taken down.

Nice work!

[madshall]

@fronzbot where did you find docs for their v4 API?

[fronzbot]

@madshall - someone posted this project and i found that endpoint in there. With that said, it seems like v4 must only be for actual 2FA since any time I've tested I have to use v3. So from what I gather:

• v2 endpoint is the old username/password only endpoint
• v3 is for email verification (ie. the "Do you trust this device" email)
• v4 is PROBABLY for 2FA (ie. the "Enter this pin" email)

[fronzbot]

@swerb73 - it's probably good practice to update that on a per-application basis. With that said, that name should default to "Blinkpy" so I'm still confused why it returns |DEVICENAME|. I think I'll open a new issue so I remember to track that down...

[madshall]

I believe unique_id needs to stay the same between launches.

[fronzbot]

I thought the same thing, but my testing shows that's not the case

[uvjim]

OK. So this is interesting, I've only just gotten around to testing this. As expected I received a prompt to enter a verification code. I stopped my code running at that point but I did receive the email asking to allow the device (the devicename was as per the other issue you have open). In then enhancing my login/initialisation routines to try and raise relevant errors, I now don't need to verify.

Whilst testing I received 3 emails from Blink. I ignored them all. Then on the last test run, it logged in with no errors, no email for approval etc. Bizarre, but I don't think this has anything to do with blinkpy.

I can confirm the login seems to be working - it was slow on the first login but seems to be fine since then (again I don't think this is anything to do with blinkpy). My problem now, is that I can't test my code with a request that needs to send in a verification code or response to the approval mail. Luckily I'm the only one with access to the code and am the only one using it to work around some of the limitations that Blink have in their own app and IFTTT integrations.

¯\(ツ)/¯

[fronzbot]

Yeah, I've noticed the ability to ignore the email and still login fine. I'm wondering if they just haven't implemented the check yet? Maybe once they do what @madshall says will be the case where unique_id needs to be persistent. We'll see!

I'm going to close this since it seems like the implementation is currently working for everyone. If it breaks after May 11th, a new issue is probably worthwhile.

[dashrb]

I'm testing this now, too (based on 0.15.0 release tag). I also received the email first time, with "|DEVICENAME|" in it. I clicked allow at 10:53 PM.

I continued to test. Shortly after midnight, I received another interactive prompt from blink.start(), and a corresponding email.

I use your library in a once-a-day cron job (at 11:59PM) which connects to my account, and downloads all videos from that day. If I'm going to receive an authorization request from BLINK every day, this is going to be annoying!

(Should we have this conversation here, now that this issue is closed? Or elsewhere?)
Thanks for your work on this, fronzbot!!!

[fronzbot]

@dashrb - hmm, that's interesting. Probably worth opening a new issue for so we can keep track of it.

For what it's worth: I've gone a couple days with mutliple restarts (ie. calling Blink.start()) and only received one email for the same device_id parameter (which is Blinkpy by default, if you didn't change it). Maybe it's a hiccup or a regional thing? 🤷‍♂️

[swerb73]

Just following up for everyone after I changed my "device_id". I did get a new authorization email which changed my Device: but not my Device Name: which I expected. The email said:
Device: THE_NEW_DEVICE_ID
Device Name: |DEVICENAME|

I clicked accept/authorize and all my scripts that leveraged THE_NEW_DEVICE_ID worked.

[MisterWil]

Just as an updated: I ran the same script that I used to test the new login flow 3 days ago (literally just blink.start() and then a dump of camera names) and I was not asked for a pin nor did I have to re-authorize via email.

[dashrb]

My bad, y'all--false alarm on the second authorization email. This is why I shouldn't debug after midnight. I had been running an "info" script, and authorized it, and then I switched to my actual "download" script to get all my files, but I forgot to set the device_id parameter in the second script. So blink saw it as a "new device" and sent a second email to me.

Seems like this is all working well so far. Thanks again @fronzbot!

[jlvandusen]

All
how do I pull this down since I am running a hass.io on Synology?

Can I simply take your latest blink folder under components and place it under custom_components and restart HA?

[fronzbot]

You could try that (it would have to be the blink folder from my active PR), but I don't think it will work. I think you'd need to replace more files that indicate what version of blinkpy to use (there's a few, can't remember them off the top of my head though).