Gitea Login #16

New Issue

Closed

opened 2022-12-16 02:00:34 +05:30 by realaravinth · 2 comments

realaravinth commented

2022-12-16 02:00:34 +05:30

Owner

No description provided.

realaravinth self-assigned this 2022-12-16 02:00:34 +05:30

realaravinth added spent time 2022-12-16 02:00:56 +05:30

4 hours

realaravinth added spent time 2022-12-16 21:39:51 +05:30

2 hours

realaravinth commented

2022-12-16 21:40:58 +05:30

Author

Owner

Summary:

Web UI to register new Gitea instance: any unauthenticated user can add a new Gitea instance
Fetch and store Oauth metadata data in DB.

(code is yet to be pushed, since it is lacking integration testing)

## Summary: 1. Web UI to register new Gitea instance: any unauthenticated user can add a new Gitea instance 2. Fetch and store Oauth metadata data in DB. (code is yet to be pushed, since it is lacking integration testing)

realaravinth added spent time 2022-12-19 00:25:07 +05:30

2 hours

realaravinth commented

2022-12-19 00:36:30 +05:30

Author

Owner

Abandoning effort. Code dump lives in wip-gitea-login branch.

I had originally planned an approach where a customer can add OAuth configurations (client ID, client secret and instance URL) to LibrePages via an unauthenticated form:

This would enable customers to configure LibrePages to work with any indie Gitea instance without requiring assistance from LibrePages instance administer. A new customer who wishes to sign up could search for registered Gitea instances on LibrePages and use OAuth to sign in.

Gitea login is infeasible because OAuth credentials provided by customers aren't reliable: the customer can delete them on their Gitea instance, and we'd only know about it after the fact. An alternative is to request LibrePages instance admin to create an account on the Gitea instance and add it manually to LibrePages. People run indie instances to stay independent, so this solution is not an ideal fit.

Abandoning effort. Code dump lives in [`wip-gitea-login`](https://git.batsense.net/LibrePages/librepages/src/branch/wip-gitea-login) branch. I had originally planned an approach where a customer can add OAuth configurations (client ID, client secret and instance URL) to LibrePages via an unauthenticated form: ![image](/attachments/c209396c-3597-48e8-8484-123e343344da) This would enable customers to configure LibrePages to work with any indie Gitea instance without requiring assistance from LibrePages instance administer. A new customer who wishes to sign up could search for registered Gitea instances on LibrePages and use OAuth to sign in. Gitea login is infeasible because OAuth credentials provided by customers aren't reliable: the customer can delete them on their Gitea instance, and we'd only know about it after the fact. An alternative is to request LibrePages instance admin to create an account on the Gitea instance and add it manually to LibrePages. People run indie instances to stay independent, so this solution is not an ideal fit.

image.png

90 KiB

realaravinth closed this issue

2022-12-19 00:36:30 +05:30

realaravinth added the

infeasible

label 2022-12-19 00:37:39 +05:30

realaravinth referenced this issue

2022-12-28 16:22:18 +05:30

Forgejo compatible webhook #3