From c8456d57ff757afaf77478e71cf140740fe520d3 Mon Sep 17 00:00:00 2001
From: erik <erik.seiert@meissa-gmbh.de>
Date: Thu, 30 Nov 2023 16:10:26 +0100
Subject: [PATCH] Add thoughts on user creation
---
routers/api/v1/activitypub/repository.go | 30 ++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/routers/api/v1/activitypub/repository.go b/routers/api/v1/activitypub/repository.go
index 3250c00166..1220d9838e 100644
--- a/routers/api/v1/activitypub/repository.go
+++ b/routers/api/v1/activitypub/repository.go
@@ -130,9 +130,39 @@ func RepositoryInbox(ctx *context.APIContext) {
log.Info("http client. %v", client)
log.Info("response: %v\n error: ", response, err)
log.Info("Person is: %v", person)
+ log.Info("Person Name is: %v", person.PreferredUsername)
+ log.Info("Person URL is: %v", person.URL)
// create_user_from_person (if not alreaydy present)
+ /*
+ ToDo:
+ This might be a forgefed specification question?
+
+ How do we identify users from other places? Do we get the information needed to actually create a user?
+ E.g. email adress seems not to be part of the person actor (and may be considered sensitive info by some)
+ cmd/admin_user_create.go seems to require an EMail adress for user creation.
+
+ We might just create a user with a random email adress and a random password.
+ But what if that user wants to create an account at our instance with the same user name?
+
+ Or might it just be easier to change the data structure of the star and
+ save identifying info of a remote user there? That would make the star structure quite bloaty though.
+ It would also implicate that every other feature to be federated might need their own struct to be changed.
+
+ Or create a federated user struct?
+ That way, we could save the user info apart from any federated feature but tie it to that.
+ On a new registration we could check whether that user has already been seen as federated user and maybe ask if they want to connect these information.
+ Features to be federated in the future might benefit from that
+ The database of federated features will have to be updated with the new user values then.
+
+ The "if not already present" part might be easy:
+ Check the user database for given user id.
+ This could happen with something like: user_model.SearchUsers() as seen in routers/api/v1/user.go
+ SearchUsers is defined in models/user/search.go
+ And depending on implementation check if the person already exists in federated user db.
+ */
+
// wait 15 sec.
ctx.Status(http.StatusNoContent)