Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve UX of adding a third party app as trusted #1142

Open
michielbdejong opened this issue Mar 15, 2019 · 7 comments

Comments

Projects
None yet
3 participants
@michielbdejong
Copy link
Contributor

commented Mar 15, 2019

Current UX with NSS 5 for using a third-party webapp:

  • visit e.g. https://pheyvaer.github.io/solid-chess/
  • click 'Log In'
  • a popup gives you four options, pick 'custom'
  • enter your WebId, or at least the protocol+hostname of it
  • log in to your pod (if you're not already logged in)
  • the popup wil close and the app will say you're logged in
  • open a separate tab, browse to your own WebId (make sure to include the '#me')
  • hover over the 'card' title
  • select the 'A' icon
  • enter the origin of the app, https://pheyvaer.github.io
  • tick the read, write, and append boxes
  • click add
  • switch back to the app pane and start using the app

Proposal: add a checkbox that makes it easier to add an app as trusted, as part of the login flow. With this, it would become:

  • visit https://pheyvaer.github.io/solid-chess/
  • click 'Log In'
  • a popup gives you four options, pick 'custom'
  • enter your WebId, or at least the protocol+hostname of it
  • log in to your pod (if you're not already logged in)
  • if the app is not in your list of trusted apps yet, you will see three buttons in the popup dialog: 'identity only (don't add as trusted app)', 'identity+read only', and 'identity+read+write'
  • click one of those buttons
  • the popup wil close and the app will say you're logged in
  • no need to go into the data browser's trusted apps pane separately
@michielbdejong

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2019

Screenshot 2019-04-17 15 55 19

@michielbdejong

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2019

Screenshot 2019-04-17 15 57 40

@jaxoncreed

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2019

This makes sense. I'll be sure to try to implement this feature in the new idp.

@michielbdejong

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2019

Yeah, we need some cross-dependency there because it means the UI of the IDP needs to trigger a change on the pod.

@jaxoncreed

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2019

Ah, that's very true. This would require a whole new dimension where the IDP knows all the pods that a user has, and update each one of them. On top of that, the UI isn't just as simple as "grant access to an app." It would be "Grant access to an app for all of my pods... this one pod... everything excluding this pod?"

@michielbdejong

This comment has been minimized.

Copy link
Contributor Author

commented Apr 18, 2019

No, there is only one profile per user, even if there are multiple pim:storage pods. You find the user's profile by dereferencing their webid, and that's where their list of trusted apps is. In theory, the user's profile doesn't even have to be on their pod, it could also be generated dynamically from the profile information stored in an organization's LDAP server.

@jaxoncreed jaxoncreed self-assigned this Apr 29, 2019

@jaxoncreed jaxoncreed added feature and removed triage labels Apr 29, 2019

@megoth

This comment has been minimized.

Copy link
Contributor

commented May 8, 2019

To inform people following this issue: @jaxoncreed are working on implementing a solution that would allow users to grant access to application as part of the login process if a redirect URL is present and the profile the user tries to authenticate with haven't granted access to application from before and trustedOrigin is set to true for the server.

I'm working on a text that explains what this is about for people uncertain what this part of the login form means.

megoth added a commit that referenced this issue May 8, 2019

Added a text that is aimed for non-technical users
This would accompany the work being done on #1142, which would link to this resource to give users a bit more understanding on what they're about to do.

I've written this with non-technical users in mind.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.