| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Finally.
Last bug fixes here: Send PairResp with same UUID in the PairReq.
Fix off-by-one in code that filters out our own pairing messages.
Also reworked the pairing alerts, which are still slightly buggy.
|
|
|
|
|
| |
This avoids us responding to our own pairing messages, as well
as ignoring any out of order messages that might be received somehow.
|
| |
|
|
|
|
|
|
|
| |
Pair requests the the same UUID are part of the same pairing session,
which allows us to detect attempts to brute force the shared secret,
as that will result in pair requests with the same UUID that are
not verified with the right secret.
|
| |
|
|
|
|
|
| |
Including rollback of adding the key when a pairing response
gets canceled by the user.
|
| |
|
| |
|
|
|
|
| |
Has a button to cancel the request.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
They work fine. But I had to go to a lot of trouble to get Yesod to render
routes in a pure function. It may instead make more sense to have each
alert have an assocated IO action, and a single route that runs the IO
action of a given alert id. I just wish I'd realized that before the past
several hours of struggling with something Yesod really doesn't want to
allow.
|
| |
|
|
|
|
|
| |
Due to being multicast, requests sent by one thread are received by the
listener in another thread.
|
| |
|
|
|