WrapAPI Login call failing?

[tacomilkshake]

Starting today, perhaps yesterday, I've been unable to login using the WrapAPI login call -- looking at the logs (on WrapAPI), I see "Expired Session". Either I've done something wrong, or perhaps Alarm.com's PDA website has changed again.

Anyone else having issues controlling their alarm via HomeBridge?

[tacomilkshake]

Doing some more digging at WrapAPI, I'm seeing this returning in the rawData of the login request:

A 302 status code (moved temporarily) /login.aspx?m=unexpectederror

[c0diq]

Same problem here.

[jomo25]

Same problem here, since yesterday. Last time it worked for sure was Sunday night. And not seeing any nag screens or issues logging into the web or mobile or app alarm.com interfaces.

[bryanbartow]

Interesting. I'll try and take a look at this tonight.

[solomonj1963]

In my amateur guessing, it looks to me like the initlogin needs to post to the url https://www.alarm.com/pda/Default.aspx, but other calls like login need to post to the url https://www.alarm.com/pda/main.aspx instead. Not familiar enough with wrapapi service to do quick and dirty test though...

[bryanbartow]

WrapAPI was including some weird looking variables in the POST. They must have always been there and I just didn't notice. Anywho, I removed them and now I no longer get a 302, but I am getting a session expired message. Typically, that would return a new session URL, which I would use to re-login. The only problem is that no longer seems to work. Even if I take the new session URL and immediately try within seconds, I still get the session expired message.

This is definitely a show stopper. I'll have to sleep on it, but in the meantime, if anyone has any other ideas please do share.

[tacomilkshake]

I was able to get new WrapAPI calls working with Alarm.com login -- I created fresh initlogin and login calls using the WrapAPI chrome plugin, and they worked, so this can be fixed. I'd share mine, but they're private as they include my login details and I haven't figured out how to scrub that out yet.

I looked into those odd variables and they are a part of ASP.net, and I believe they keep track of the form state (for multi-page processes, I assume). The ones that were previously being submitted we're likely quite old, generated when you first captured the page. Perhaps a ASP server upgrade invalidated the static ones you were passing and caused the web server to throw an error. Just guessing. Another thing I noticed is that the POST URL is now default.aspx, not Default.aspx. Doubt that matters. Or finally, perhaps another small page or process change was made that my fresh WrapAPI capture is now handling properly.

Perhaps try replacing those six values with some that are freshly generated? Even better would be to just collect those weird variables and pass them to the login call, similar to how you do with sessionUrl. That would ensure future compatibility if those values were indeed the issue.

Worse case, you could recreate those two calls using WrapAPI's chrome extension-- that worked for me. The good news is all of the other calls still work.

[bryanbartow]

@jamiesteven Good news. You can mark your variables on Wrap as private and they won't get included when sharing. If you can't figure it out or don't have time, I'll re-create the calls when I get a chance, which will probably be this weekend. Either way, thanks for checking it out.

[bryanbartow]

As @jamiesteven mentioned, updating the cryptic ASP.net form values on the login call restored functionality. The call has been updated to version 0.1.1 and the plugin has been updated on npm to 0.6.1. Everything is working great for me again. In a future version, I will try to programmatically capture and update those variables. Probably when it breaks again ;) I'm closing this issue, but please reopen if you continue to have problems after updating.

[omarshahine]

Thank you! Updated plugin and it's working again!!!

[jomo25]

Yes, same here. Thank you for fixing it! Working now after updating the npm package. Let us know if you make the next adjustment as well! Much appreciated!

[bryanbartow]

@omarshahine @jomo25 Nice. Glad it's working.

I think one change I probably will make at some point, separate from the aforementioned change, is to replace references to versioned APIs with [apicall]\latest as opposed to [apicall]\version.

That way I don't have to update the plugin itself if/when something like this happens in the future. I'll just have to update the call on WrapAPI and everything should work.

[jomo25]

@bryanbartow cool. That will be nice. Won't need to npm update then! Thanks!

[tacomilkshake]

Great news, thanks @bryanbartow!

[c0diq]

Works like a charm. Thank you @bryanbartow !

[gsteever]

Thanks @bryanbartow for jumping on this issue so quickly! It's amazing how reliant one becomes on these automation tools...when they stop working it feels like a crisis.

Quick follow up question...I applied the update and ran through the WrapAPI tests again. Basic alarm functions are now working but I've lost the ability to see or control the locks and garage door via Alarm.com's integration. Has anyone run into similar problems? I'm already at the office so I don't have the specific errors with me but if anyone else is using this additional integration, I'm anxious to hear if yours is working. I can post the errors I'm seeing tonight.

[bryanbartow]

@gsteever I don't have locks nor garage door connected to Alarm.com, so it wouldn't be possible for me to test. As this issue was related specifically to the login call(s), I'd appreciate it if you could open a separate issue. My guess is it will get more visibility that way, too.

[bryanbartow]

It turns out this broke sooner than I thought ;) I have added an intermediate step to the plugin, which captures the ASP.net form values and passes them to the login call. This should prevent this particular problem from occurring in the future. You'll have to update your plugin and WrapAPI calls in order for it to work.

[solomonj1963]

FYI, you might want to add the new getviewstate API to your readme file. I noticed it wasn't there. I found it by searching on wrapapi.

[bryanbartow]

@solomonj1963 You're right. My bad. I've added it.

[jnanes]

is this project dead?