search

WP-API / authentication

The home for design & development of a core WordPress REST API authentication solution
GNU General Public License v2.0
62 stars 2 forks source link

Review Connection UI #26

Open TimothyBJacobs opened 4 years ago

TimothyBJacobs commented 4 years ago

We should ask for design review to make sure our UI is as understandable as possible.

This is the basic connection screen. image

This is shown when you are connecting with a new application. image

And this is what we show if you are connecting with a new application that is verified to be developed by the given uri. image

The spec also recommends that we capture and display the following information as well.

logo_uri

URL string that references a logo for the client. If present, the server SHOULD display this image to the end-user during approval.

tos_uri

URL string that points to a human-readable terms of service document for the client that describes a contractual relationship between the end-user and the client that the end-user accepts when authorizing the client. The authorization server SHOULD display this URL to the end-user if it is provided.

policy_uri

URL string that points to a human-readable privacy policy document that describes how the deployment organization collects, uses, retains, and discloses personal data. The authorization server SHOULD display this URL to the end-user if it is provided.

And perhaps

contacts

Array of strings representing ways to contact people responsible for this client, typically email addresses. The authorization server MAY make these contact addresses available to end-users for support requests for the client.

saylorrain commented 4 years ago

This design looks good. It makes sense and flows well. One really small copy change on the "warning" notice. Remove the word "that" in the phrase "... an application that you haven't connected..." it is unnecessary. Everything else looks clean and it makes sense.

TimothyBJacobs commented 4 years ago

Some notes from @georgestephanis was that we should consider flipping the verification UI. Instead of showing when a client is "verified" show a warning when the client is not verified. Like how browsers now handle SSL.