This is an upstreamed issue originating here: https://github.com/GlancingMind/git-bug/issues/13 Git-Bug supports multiple identities. Just create another one with 'git-bug user create' and list all with 'git-bug user ls'. Identities can be switched by replacing the current user id for the new user id under the git-bug/identity entry in the .git/config.

Comment by @MichaelMure:

I'd like to re-frame that idea slighlty differently:

Eventually, the webUI should be able to be used as a public portal for a project and accept external edition. That is, the maintainer of a project would put the git-bug binary on a server somewhere and run the webUI exposed on the internet. Ideally the webUI would accept external auth system like Github OAuth or others. When a new user would use those the first time, a new git-bug identity would be created in the git repo (by the go code) for later use.

There is the premise of that system already: https://github.com/MichaelMure/git-bug/tree/master/api/auth https://github.com/MichaelMure/git-bug/blob/master/commands/webui.go#L92-L101

All of that to say that what you are describing is a login screen for the webUI. With git-bug's current capability on that aspect, this login screen could have a dropdown of the existing identities. Later, support for those external auth system can be added.

Note though that in a near future those existing identities might be "locked", in the sense that they will carry cryptographic keys and you will need to have the private key to use them.

Originally posted by @MichaelMure in https://github.com/GlancingMind/git-bug/issues/13#issuecomment-792828040

Sascha (GlancingMind) changed the title from WebUI: Add Login page with OAuth support. to WebUI: Add Login page with OAuth support. 4 years ago

IndieAuth might be another option to the common OAuth options.

Looks like https://github.com/go-pkgz/auth would be decent.

It does require though a set of configuration (for example, github app ID) for each OAuth provider. I suppose git-bug can't have default values as those are supposed to be secret. This means that a user wanting to have the webUI public and accept external auth would need to generate those secrets for each provider they want to have. Not ideal but that would work.

If we want to be fancy, would could have code that make the requests to generate those secrets (in a similar fashion as bridges generating tokens), but that's not necessary at all.

Michael Muré (MichaelMure) added label enhancement 3 years ago

Michael Muré (MichaelMure) added label help wanted 3 years ago

This bot triages untriaged issues and PRs according to the following rules:

• After 90 days of inactivity, the lifecycle/stale label is applied
• After 30 days of inactivity since lifecycle/stale was applied, the issue is closed

To remove the stale status, you can:

• Remove the lifecycle/stale label
• Comment on this issue

github-actions (github-actions) added label lifecycle/stale 1 year ago

sudoforge removed label help wanted 1 year ago

sudoforge removed label lifecycle/stale 1 year ago

sudoforge added label area/ui/web 1 year ago

sudoforge added label kind/feature 1 year ago

sudoforge added label lifecycle/frozen 1 year ago

sudoforge added label priority/important-longterm 1 year ago

sudoforge removed label enhancement 1 year ago

sudoforge removed label lifecycle/pinned 7 months ago