Return the authenticated username on the hello page.

[Natim]

• Using basic auth we could return the user part.
• Using FxA the email address.

It will ease displaying the username on the kinto-admin.

[Natim]

See Kinto/kinto-admin#80 (comment)

[almet]

It is actually possible (and might be a better thing to have) to import the name of the user by asking the profile server. It is also possible to ask for the email address.

Also note that the email address that's returned by the account server needs the auth to have the proper token scope.

[Natim]

Yes we could try to get the email from the profile server if the profile:email scope is available.

[almet]

Well, my point was more that it's possible to get the full name of the user :)

[leplatrem]

Using basic auth we could return the user part.

No. There is no user part. We have invited our users to use a token:!

[leplatrem]

Actually, I fear that this introduces some confusion with the user id to be used in permissions definitions...

We could let the client do these calls no?

I put a -1 on the idea, but I may be wrong, please explain why it makes sense to do on the server side :)

[Natim]

No. There is no user part. We have invited our users to use a token:!

Well does it makes sense with the admin too?

[tarekziade]

It will ease displaying the username on the kinto-admin.

I am also confused because ISTM the dashobard has all the info. Can you describe the detailed use case in a user story ?

[Natim]

Yes: when people are connected on Kinto I want to display their username / email address in the header to inform them about which user they are logged with. (i.e Gmail header)

I would like to find a way to do it that works regardless of the login method.

[leplatrem]

No. There is no user part. We have invited our users to use a token:!

Well does it makes sense with the admin too?

In theory, the kinto-admin should adapt to the notions of the protocol. Even if it means replacing the username and password fields of basic auth by a single «token» field.
Maybe this is not possible in practice...

(Related #297 and #395)

I would like to find a way to do it that works regardless of the login method.

Yes, I think that is the main argument in favor of doing this on the server side.

[Natim]

I think what the doc propose with token:api-key is just a convention.

We never choose to prevent people from using username:api-key did we?

[leplatrem]

We never choose to prevent people from using username:api-key did we?

Indeed :)

[almet]

But that is not the recommendation we're making i' the docs though (where we recommend using token:passwd).

I believe it would be a good idea to make a decision on this and adapt the docs and admin accordingly (either use app token or something else but we need to be consistent)

[leplatrem]

Closing...
Feel free to reopen if you have some opinion on this :)