Write a new migration script

[angusmcleod]

@merefield We'll need to write a new migration script which directly populates the new data stores we've estabished in #6. This will be an updated version of the migrate-wp-users/migrate_wp_user_to_oauth.pl.

[auggod]

Can you elaborate why we need a new migration script at all? I was not thinking of changing this script. I suggest we build a new UI to onboard existing users into the new system.

[nmeyne]

I guess the safest, but definitely not the friendliest, option is indeed to ask users to re-enter / recreate all their wordpress profile information in the 'empty' user and membership api, binding this to the existing ID server authentication to the player.

A data migration from WP to user API based on email address, assuming a reliable match, would be friendlier. We would force an ID server password reset including proof of control of the email address before users gain access to the converted data. Risks?

Another UI-led alternative is to convert only when the users come to revisit the site.... on joint authentication to both wordpress and the ID server user API, invoke a profile copy across for the user who is logged in to both services. Then mark the WP record as claimed/migrated.

Although the UI led approach is great for cleaning out old lapsed / expired user accounts, I would worry about having a long period of transition where a lot of pending users and accounts are on WP and we lose the completeness of a single minimal identity store (intention of the user-membership API) for core Resonate services. I also worry that the WordPress forgotten password process is admin-intensive at the moment, so we might get a peak of queries from that?

Have I understood this correctly?

[angusmcleod]

@auggod @nmeyne Requiring users to create new credentials is best avoided if possible. You have to:

1. Create a UI for it
2. Handle old account removal
3. Handle new account de-duplication
4. Message about it, i.e. tell users in advance what is happening.
5. Deal with legacy conversions for some time to come (i.e. people who convert late)

It is easier to write a migration script to move existing credentials over to the new system. It's less development work, less user-messaging and less disruption for the users. There's no need to clear out lapsed / expired accounts, unless you have some kind of data privacy concern. The extra storage space they take is minimal.

The primary reason you'd want to require users to create new credentials is if you had an issue with validating old password hashes, i.e. https://github.com/resonatecoop/id/issues/10. If that's an issue, we'd then turn to the option of requiring new credential creation, but I think we can handle that relatively easily considering we're dealing with passwords created in wordpress.

[angusmcleod]

@auggod @nmeyne How about we take a middle ground here.

1. Migrate all users over to the new system using an updated script
2. Ask users to create a new password within a X month period.
3. Support old WP passwords during the X month period
4. Require users to create a new password after ther X month period ends

This way we

1. Don't have to message about the switch over beforehand, which would otherwise be an extra to do on our list before we can launch
2. Allow users time to make the switch, i.e. they may just want to be able to log on, and we should make that as easy as possible (i.e. no hard requirement to create a new password).
3. Gives us extra time to message about the change
4. Don't have to support the old password hashes forever

We want to keep our pre-launch workload as light as possible, but still migrate users over to the new password hashing as well. This is perhaps a compromise.

[auggod]

See https://github.com/resonatecoop/wp-migration