It seems that it's acceptable for the client to integrate with FxA, so we should reactivate FxA support on the server.

Presumably removing session support is going to break any non-FxA clients. Is that correct?

It is. Support for cookie sessions is only implemented to go faster on the MLP, but it seems that we want to integrate with FxA for MLP, so we'll need to change back to FxA auth at some point.

A recent theory that I heard is that product is likely to want both for MVP, so unless and until we hear otherwise, I'd suggest not removing sessions.

On mobile: => The API to authenticate to FxA is already available => I expect TEF to provide a working prototype allowing both MSISDN authentication and FxA authentication by June 9th. TEF (Jorge and Fernando) confirmed they don't need 984949 for June 9th. The long term solution will allow both MSISDN and FxA authentication On desktop: => Account-less (opaque ID) works now (MLP) => FxA integration will require for MVP FxA UX changes on the desktop side which we are discussing with Ryan at the moment. We are just exploring UX for now and we expect FxA integration to come in later (checking timelines with Ryan) The long term solution will allow both account-less (opaque ID) and FxA authentication (assumes account-less is proven to be useful for end users).

(In reply to Romain Testard [:RT] from comment #5) > On mobile: > => The API to authenticate to FxA is already available > => I expect TEF to provide a working prototype allowing both MSISDN > authentication and FxA authentication by June 9th. TEF (Jorge and Fernando) > confirmed they don't need 984949 for June 9th. What should be available by June 9th is bug 988469 and bug 1003330, but no Loop prototype using it. That will happen a few days later :). > On desktop: > => Account-less (opaque ID) works now (MLP) > => FxA integration will require for MVP FxA UX changes on the desktop side > which we are discussing with Ryan at the moment. We are just exploring UX > for now and we expect FxA integration to come in later (checking timelines > with Ryan) Are you considering bug 996494 for the UX changes?

The goal is to complete this work this week.

That PR appears to leave (Hawk) sessions in place, correct? I.e. the bug title has become incorrect.

Corrected the bug title per discussions that were had. Thanks Alexis for re-activating FxA and leaving HAWK active. Adam was in the conversation with Alexis - so validated both will be on, so the desktop client will still work.

It depends what you call sessions, actually. The changes removed the session cookies and uses hawk or FxA for authentication. In case no auth is provided, it creates an anonymous session and returns hawk credentials for it.

Landed https://github.com/mozilla-services/loop-server/commit/092bdc4cc46c0dde7dbcbd80b0fda1ef6a307de0

Comment on attachment 8430149 [details] link to github PR Thanks Alexis! This is being reviewed and tested by jaoo

(In reply to Fernando Jiménez Moreno [:ferjm] (work week, not reading bugmail) from comment #13) > Comment on attachment 8430149 [details] > link to github PR > > Thanks Alexis! This is being reviewed and tested by jaoo I have not tested yet the FxA assertion dance, the hawk sessions works pretty well. I'll try to test the FxA assertion dance today and provide some overall feedback. Action for FxOS Loop client app is happening on bug 1016423, I'll change the bug title to reflect the client is gonna support the FxA case as well.

Quick verification of all code additions/changes and unit tests. Also verified the changes to the load test.