New feature for alt_auth plugin

[Jimmi08]

This is again about the difference between my real used version and the upstream version. Just a note for future discussion.

This is a missing feature that I needed to add as basic functionality.

You have 2 sites, site 1 and site 2 (site 2 allows logging in with data from site 1), but both have a full user login/registration system.

A new user creates a new account on site 2. That nickname is not registered on site 1, so anybody there can register under the same nickname. To block this, I needed to add the creation of a user account on site 1 - not a password, just a nickname and email- so nobody on site 1 can use this nickname. If this user wants to use site 1, they use the forgotten password functionality. But nickname is already taken.

Alt_auth plugin has all the information already for something like this, and I added this functionality as a preference.

It is not about having the same user list for 2 sites - site 2 users are a subset of site 1 users - (Like site 1 is parent where all nicknames should be registered, and site 2 has only users that need site 2)

Is it clear what I am trying to say?

[Alex-e107nl]

Ai @Jimmi08 not a complete sync but half... complicated, why not a complete sync and use classes and then with the right class for entering the right website? So registering on site one = class one and registering on site 2 class = two and make sure both websites use these classes?

Or is that even more complicated :-)

[Alex-e107nl]

Oke, what happens when someone has a account on website 2 with a reserved Nickname on website 1 and want to make a account on website 1 with the this nickname? Interesting i really want to know! Classes are transported by the Alt auth so it could also be a solution... nothing more, only a idea...

[Jimmi08]

I suppose that they got the answer that the name is already taken. I am moving site 1 from other to e107 user system. I will look at this later

[e107help[bot]]

Ahoj @Jimmi08, yes, it is clear.

Reading it back so you can correct me: site 1 owns the nickname space. When somebody signs up on site 2, you create a shell account for them on site 1, nickname and email only, no password, so nobody else can take that nickname there. If that person later wants site 1, they go in through forgotten password.

Worth recording next to your note, for whoever picks it up: alt_auth already creates accounts, just pointing the other way. After a successful remote authentication it inserts the user into the local table at alt_auth_login_class.php:255, and the connection to the other site is already open at e107db_auth.php:102. The parts exist. What your feature adds is a write into the directory rather than out of it, on credentials that today only need SELECT.

The reason it is bigger than it looks upstream is the other backends. alt_auth ships five, and ldap, radius, importdb and otherdb are not all things you can insert an e107 user row into. So a reservation feature is either e107db only or it needs a per-backend answer, and which of those it should be is Deltik's call rather than mine.

No hurry from my side, and I noticed you are still moving site 1 across. Whenever you do come back to it, the two things worth writing down here are what happens to the reservation when the site 2 account is deleted or the nickname changed, and whether the receiving site's forgotten-password flow copes with an account that has never had a password set. If the code goes on this thread rather than staying in your notes, it is where the next person will look for it.

[Jimmi08]

Thank you for your answer. This should go for e107 DB only.

I moved this weekend site1 from unnuke users to e107 user/registration, and I am taking these notes just to show how complicated it was before (and if somebody hit some my old comments about this)

Original state: (this was created with Deltic's help long time ago)
Site 1 - Nuke registrations/users - headless creating e107 account and used xup field for saving nickname - yeah, IDs are not safe; always nicknames. And headless login in too.
Site 2 - e107 system, not used unnuke_users table at all.
Alt auth was used to allow to login on site 2 with otherdb settings from site 1 . Originally, it was planned to use e107 users from site 1, but then I found that there is an issue - e107 data wasn't updated when the nuke user was. I just forgot to do this.

Actual state
Site 1 - e107 system - unnuke table still exists, and the record is created after the first login with e_event. Works perfect. I hit an issue with that xup field, but I fixed the shortcodes manually for now. I will use it like extended fields because there is a point system for user activity so...
Nuke is still fully installed, but all stuff related to users is now managed by e107 (admin is on the to-do list)

Site 2 - the same code - FINALLY! - used alt auth e107-e107

The solution for otherdb is here:
https://github.com/Jimako-e107-plugins/e107-alt_auth-plugin/blob/main/e107_plugins/alt_auth/e_event.php

But my time is limited too, so let this just as note, I can live without it.

[e107help[bot]]

@Jimmi08 e107db only makes this much easier to reason about, thank you. I read the file you linked (e_event.php at 8ee5919) and there are two columns missing from the INSERT that I think you want. Both values are already in hand from the e107::user($userId) call just above it.

user_email. Your first post has it right, nickname and email, but the statement writes only the configured user field and the password, so the row lands with user_email = ''. Forgotten password on site 1 looks the account up by email unconditionally, fpw.php:292, so the reserved account can never be found and the recovery route you designed the whole thing around does not open. Nothing else blocks it, for what it is worth: user_ban defaults to 0, which is exactly what fpw wants to see.

user_name. The user table carries a UNIQUE KEY on it, core_sql.php:623, and the column is NOT NULL default '' at :596. So the first reservation row inserts happily and the second one dies on a duplicate empty display name. The existence check ahead of it only looks at the user field, so it does not see that coming, and the Throwable catch turns the failure into an admin-log line instead of anything visible. If site 1 already has more than one of these, the log will have "Alt auth outbound sync failed" in it. Filling the column closes the smaller gap in the same move: the duplicate check on site 1 runs per column, so until user_name holds something, the display name is still free for the next person there to register.

One thing for the record rather than for doing. The hook is on the core login event, login.php:818, so the name gets reserved at the site 2 user's first login rather than at registration, leaving a window where site 1 is still open. Small in practice, and moving it to a signup event trades it for a worse one, since unverified signups would squat names for good. I would leave it where you have it.

Nothing here needs an answer. It is on the thread for whoever picks the idea up, yourself included, whenever that is.