971991 - Loop Server needs to accept FxA bid assertion and simple push URL

Status: VERIFIED FIXED

(Hello (Loop) :: Server, defect)

Comment 1

[Byron Campen [:bwc]]

This is the service that accepts registrations of simple push URLs for a user.

Comment 2

[Alexis Metaireau (:alexis)]

I think we should associate userids with push urls (eventually multiple ones) and not auth tokens. Auth tokens issued by the tokenserver will eventually expire whereas the userid will not.

Associating the simple push url with an user id allows us to have a persistant way to find back how to contact our users.

Comment 3

[Byron Campen [:bwc]]

That's consistent with my understanding of the plan.

Comment 4

[Alexis Metaireau (:alexis)]

https://github.com/ametaireau/pants-server/commit/cecaaab368f36e0627baf9b5f7bb63dd1ca13473 is the code that does authentication, and https://github.com/ametaireau/pants-server/commit/3033f1ee1e6088c959ab2e58276bf5f7139d94bc checks we're sending a simple push url.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

For MLP, I bet we want to do whatever's easiest.  I've heard use cases for both expiring and non-expiring URLs.  Which of these gets prioritized for MVP is presumably up to product.

Comment 6

[Byron Campen [:bwc]]

For non-expiring, it becomes a lot more important to tackle revocation early on, which is I think a harder problem than an expiry.

Comment 7

[Adam Roach [:abr]]

(In reply to Dan Mosedale (:dmose) from comment #5)
> For MLP, I bet we want to do whatever's easiest.  I've heard use cases for
> both expiring and non-expiring URLs.  Which of these gets prioritized for
> MVP is presumably up to product.

Which URLs are you talking about here? The Simple Push Server URLs?

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

abr: good catch; I was in fact confused. Please disregard my comment.  :-)

Comment 9

[Alexis Metaireau (:alexis)]

Bug 972020 states we don't need integration with the token server for the MLP.

Comment 10

[Alexis Metaireau (:alexis)]

We need to accept browserid assertions directly, and not tokens issued by the token server. Eventually, to avoid having to do a bid verification on the server each time, we can put a session cookie on the client then.

Comment 11

[Adam Roach [:abr]]

For clarity, this is for the step that associates an FxA account ID with a simple push URL.

Comment 12

[Alexis Metaireau (:alexis)]

https://github.com/mozilla/loop-server/commit/a9aa6d1442624ba2014f42d6f9230ce3d1b2226f

Comment 14

[James Bonacci [:jbonacci]]

:alexis
I guess this is moot since loop/authentication.js is no longer part of the repo?

Comment 15

[Alexis Metaireau (:alexis)]

It's still the case but doesn't happen the same way. Have a look at loop/fxa.js and loop/index.js for more insights on how this is working.

Comment 16

[James Bonacci [:jbonacci]]

Yep. That's fine.