search

SolidLabResearch / Challenges

24 stars 0 forks source link

Create Web Component for Solid-OIDC login #125

Closed pheyvaer closed 8 months ago

pheyvaer commented 10 months ago

Pitch

When building Solid apps, allowing users to log in with their WebID or Identity Provider is crucial. Developers have to implement this functionality every time. Thus, it would improve the ease of developing Solid apps if there exists a Web Component that handles the logging in and out.

Desired solution

A Web Component <solid-login> that

Acceptance criteria

The solution needs to support the following flow.

  1. The developer installs the Web Component via npm.
  2. The developer includes the Web Component in a Web app via <solid-login></solid-login>.
  3. The user opens the Web app.
  4. The app shows the Web Component.
  5. The user can either enter their WebID or Identity Provider.
  6. The user clicks on the log in button.
  7. The user is redirected to their Identity Provider.
  8. The user authenticates with their Identity Provider.
  9. The user is redirected to the app.
  10. The app shows a message that the user is logged in.
  11. The app does an authenticated request to a private resource with the fetch received from the Web Component.
  12. The user clicks on the log out button.
  13. The apps shows the original state of the Web Component.

Pointers

None.

Scenarios

None.

angelo-v commented 10 months ago

Not sure if it fulfills all your acceptance criteria, but I have such a component as part of PodOS elements. There is an interactive demo of it. It is also used in PodOS Browser.

pheyvaer commented 10 months ago

Hi @angelo-v, it's indeed something like that. Once a user is logged in how can the app do authenticated fetches? I can't immediately see that in the code?

angelo-v commented 10 months ago

It is not directly possible in the current version but could be extended like that.

The login component needs to be child of a pos-app. The pos-app holds the session and can give other components access to an instance of PodOS, which can do authenticated fetches using the rdflib store/fetcher that is part of it.

<pos-app>
   <pos-login />
</pos-app>
pheyvaer commented 10 months ago

I have currently a component that fulfills the requirements. I would suggest that I mention your solution in the report, because

1) it's great to have a second option for developers to use, 2) the approach is a little bit different which might give us insights on what developers prefer down the line, and 3) you don't need to add new functionality to your code.

github-actions[bot] commented 9 months ago

Please provide a status update about this challenge. Every ongoing challenge needs at least one status update every 2 weeks. Thanks!

pheyvaer commented 8 months ago

You find the report here.

josephguillaume commented 8 months ago

I find it a little strange that the reports for the challenges can end up with no follow up actions, future work or lessons learnt about developer experience.

In case it's useful to anyone, here's a few observations:

Do let me know if the feedback is not welcome.

pheyvaer commented 8 months ago

Follow-up actions and future work are all in terms of the specific challenge. So there might be future work for the component, but there is nothing that came specifically from the challenge. The developer experience is from the point of view of the person completed the challenge. If they didn't have any problems or found shortcomings in for example Solid-related tooling that there is nothing to report. In my case I didn't have any issues. I took my existing login code and converted it to a Lit component.

Propagating (logged in) state is tricky in vanilla JS. The approach used here relies on a callback cascade. PodOS instead relies on stenciljs triggering a re-render - as would most frameworks. A login component needs to integrate well with whatever state management is used.

The component is framework-agnostic, so it can be used with a framework if the developer wants that.

I personally would not use this component because it requires specifying a logged in callback function on a html element, which is a little awkward without a framework.

Same answer as above.

Allowing specifying both webid and IDP is an opinionated UI/UX choice that doesn't appear to have an explanation here. It also seems reasonable that the web component could distinguish itself whether a webid or IDP had been entered, which would then simplify the UI.

True. But the solution and the corresponding are only about satisfying the acceptance criteria. It's always possible that the acceptance criteria could have been better, but the moment a challenge is accepted the acceptance criteria are what matters for a solution.

It's already a common UX pattern that suggested IDPs are offered, and this would strengthen the reusability of the component. Remembering the user's last IDP is a possibility too.

Considering that Solid is not widely adopted "common UX pattern" is a very strong statement. And that would also start the discussion which suggested IDPs you would add there. Which is not a technical challenge. And these challenges are only about technical aspects.

Logging in is actually not too difficult.

From our experience, some people do struggle with the login part. It might be easy for you, but that doesn't necessarily mean that it's easy for who is building a Solid app for the very first time.

My biggest pain point is dealing with expiring tokens. I often have an app open for more than an hour, which then means the token has expired and that even the oidc provider needs consent again on log in. A login component that dealt with refresh tokens would be a game changer.

This could be a specific challenge.

josephguillaume commented 8 months ago

Thanks for the response and explanation