A number of small questions that should be easy to answer...

sailtheworld

-Users on my site can change their username. How can I have Vanilla automatically recognize that a user has changed their user or email based on the proxy, so that the forums don't have their user and email out of date?

-Can I remove users' ability to change their email and password? Changing these in vanilla would be pointless because they need to change in the actual website database to be effective.

Thanks!

matthewkris

I'm looking for answers to both of these questions as well. Could someone please address this?

judgej

When a user next logs in, their username and email address will be updated from the proxy, since the link for the Vanilla user back to the proxy user does not rely on these (ProxyConnect stores the unique key for each user as defined by the proxy).

However - it is in between logging in that I suspect you are interested in. If a user changes their email address in the proxy, but does *not* visit the Vanilla forum, then Vanilla will not know about this change and so email alerts will keep being sent to the old address.

The only solution, so far as I can see, is to update the usernames and email addresses manually. I have done something similar to create users - the proxy regularly compares the users on the proxy CMS and Vanilla. If a user does not yet exist on Vanilla, then they will be created immediately. I only need to create a user record with a name and email address, link that user to a role, and also link the user to the proxy authenticator based on the proxy unique ID. Everything else is left at default values. When the user logs in for the first time, then the record gets tidied up and completed by Vanilla.

I needed to do that because I needed people to be able to start conversations with people who have not yet used the forum or logged in (it's a closed group).

One thing that was frustrating, is that there seems not to be a set of APIs for creating and updating users. Creation of a user is spread over a number of controllers and is not all in one place, hence my completely custom solution.

My next step will be updating the users when they get out of sync, and that should also be a relatively simple SQL update.

The approach I have taken - and this works only because the proxy CMS and Vanilla are on the same database - is to create views to list any users that are out of sync. The update scripts then are driven by those views.

Let me know if you are interested in the code for this. It's not a simple module for installing, so will need some programming to implement.

judgej

Another complication is Vanilla's (bizarre) use of the user's public name as a unique login name. The public display name on my CMS is for public view, and the username is only seen and used by its owner.

Because the public name was not necessarily unique, and yet needed to be unique when being sent to Vanilla, I select the public name in the CMS through a custom filter. The filter basically checks whether the name has been used by another user, and then adds a numeric suffix (1, 2, 4 etc) if it has, to make it different. The names are then cached so that the same username can be passed each time. If the user changes their name on the CMS, then the same process is again used to ensure that the new name is unique, caching that and marking the old username as "used".

Shadowdare

I am interested in seeing your code for this. I think it's weird as well that emails and passwords aren't getting synchronized. Maybe the SSO plugin should be reversed and make use of Vanilla's database instead. It would be nice if it used the username as the Vanilla username instead of the public name.

judgej

I did start by using a system-generated name for the user (i.e. user_NN) and then replacing that with the user's display name whenever it was displayed, but there were just too many places that needed to be changed throughout the core. The way the display names are used as unique usernames is pretty much hard-coded everywhere. It is one thing used for two purposes IMO, when it should be two things.

judgej

I have a view set up to give me new users on the CMS that have not yet been migrated, and then insert them like this:

INSERT INTO GDN_User ( 
                    UserID, Name, Password, HashMethod, Photo, About, Email,
                    ShowEmail, Gender, CountVisits, CountInvitations, 
                    CountNotifications, InviteUserID, DiscoveryText,
                    Preferences, Permissions, Attributes, DateSetInvitations, DateOfBirth, 
                    DateFirstVisit, DateLastActive, DateInserted, DateUpdated, HourOffset, 
                    Score, Admin, Deleted, CountDiscussions, CountUnreadDiscussions, 
                    CountComments, CountDrafts, CountBookmarks, CountUnreadConversations
                ) VALUES (
                    NULL, ?, ?, NULL, NULL, NULL, ?,
                    '0', 'm', '0', '0', 
                    NULL, NULL, NULL,
                    NULL, NULL, NULL, NULL, NULL,
                    NULL, NULL, NOW(), NULL, '0', 
                    NULL, '0', '0', NULL, NULL, 
                    NULL, NULL, NULL, NULL
                )";

Note that only three items need to specified but I also set the DateInserted as it does not seem to be included as a default. The Name is unique across all users, and you would need to work out how to derive those names from your CMS. The Email must also be unique. The Password I just make a random string, since the user does not need to know what it is, as they will be logging in via ProxyConnect, and so the password will not be used.

Next I insert a couple of roles based on the primary key generated from the first insert and the Vanilla role IDs derived from the CMS:

INSERT INTO GDN_UserRole (UserID, RoleID) VALUES (?, ?)

The last thing to do is to link that new user to the CMS user:

INSERT INTO GDN_UserAuthentication (ForeignUserKey, ProviderKey, UserID) VALUES (?, ?, ?)

The ForeigKey is the ID of the user on the CMS. The UserID is the primary key of the user inserted above. The ProviderKey is the md5 key selected from the AuthenticationProviders table for the "proxy" provider.

Creating the above data in the Vanilla database gives enough of a user account to see the user, add attributes and photos, and start conversations with them, When the user logs in via ProxyConnect, they will be in instantly with no further effort, and all the NULL columns on the User table get populated with the stuff that Vanilla needs.

-- Jason

judgej

Just as an aside, I run these queries from a PHP script that is neither part of Vanilla nor part of my CMS. It runs every hour just to keep the users in sync. I have not yet created an update process to make changes to the email and name of existing linked users, but that will be next.

The PHP code I use is very specific to the framework I use, so I have not posted that here, and you will need to work out how to execute those queries.

It probably would be nice to turn this into a "synchronise" Vanilla plugin. The plugin would handle all the user creation and updating queries, and just needs to get its feed from somewhere - perhaps a web service on the CMS to return all users that need migrating (and locked to localhost so it cannot be accessed publicly).

studioleland

I would be willing to sponsor this dev work for a wordpress-vanilla user synchronize plugin