Current dependencies on/for this PR:

• main
  • PRchore: add external auth providers tooidctest #10958
    • PRfeat: add endpoints to list all authed external apps #10944
      • PRfeat: add user/settings page for managing external auth #10945 👈

Thisstack of pull requests is managed byGraphite.

I think the whole table kind of feels "zoomed in" compared to the chrome around it. I guess mainly the icon and button are both way too big. Might be worth referencing the licenses page, it has kind of a similar vibe to this one. (although it actually kind of feels too big too...hmm)

I think the whole table kind of feels "zoomed in" compared to the chrome around it. I guess mainly the icon and button are both way too big. Might be worth referencing the licenses page, it has kind of a similar vibe to this one. (although it actually kind of feels too big too...hmm)

Yea, the look isoff for sure. I spent some time trying to fix this, but at some point I figured someone else can do a much better job in much less time than myself 😄

So I just focused on the functionality.

This is a huge improvement. Thanks@Emyrk 😊.
I think we should not have the confirmation dialogue as a user can authenticator again very easily. It's not something very dangerous like Deleting a workplace or template.

This is a huge improvement. Thanks@Emyrk 😊. I think we should not have the confirmation dialogue as a user can authenticator again very easily. It's not something very dangerous like Deleting a workplace or template.

One benefit to the confirm page is it educates the user that the "unlink" is only on our side. They need to revoke from the application to truly invalidate the token.

I agree. Are there ways we can invalidate the token on our end? By sending a request to the provider?
Also this warning could also be moved as info text somewhere on the revoke button.
I feel its uncecarsy to type the name of the provider Integration.
Moreover, a simple reuthenticate button without unlinking would help if for some reason a user needs a new token.

I agree. Are there ways we can invalidate the token on our end? By sending a request to the provider?

There is an RFC for an oauth2 extension:https://datatracker.ietf.org/doc/html/rfc7009

It is not part of the main spec though so, "your mileage may vary" based on the provider. Since we have providertypes, we can implement them based on the provider type. I think for a first draft this is ok.

Also this warning could also be moved as info text somewhere on the revoke button. I feel its uncecarsy to type the name of the provider Integration. Moreover, a simple reuthenticate button without unlinking would help if for some reason a user needs a new token.

Fair. I think this ui is very first draft.

About code: I left a few considerations about mutation usage

About design:

• The table should be wider
• I feel the button is taller than it should be

Is this something we could fix in a follow up?@BrunoQuaresma

is this behind an experiment? if so fixing later is fine, if not I think I'd rather land it in better shape since the changes would be very minor

is this behind an experiment? if so fixing later is fine, if not I think I'd rather land it in better shape since the changes would be very minor

It's not behind an experiment.

@aslilac do you or@BrunoQuaresma have some time to clean it up in this PR?

@steve-Coder-Ent yeap, I can do it tomorrow morning. In case I miss that, can you ping me on Slack to remind me pls 🙏 ?

@steve-Coder-Ent yeap, I can do it tomorrow morning. In case I miss that, can you ping me on Slack to remind me pls 🙏 ?

Perfect thanks! 🌮

@steve-Coder-Ent I think it is just easier to merge it and I work on top of it so I can use the BE changes directly from dev.coder.com. Sounds good for you?