search

paragonie / airship

Secure Content Management for the Modern Web - "The sky is only the beginning"
https://cspr.ng
Other
418 stars 41 forks source link

WordPress Import #147

Open ghost opened 8 years ago

ghost commented 8 years ago

I know this has been discussed, but to get it documented...

There should be an Import tool that can be used to import content from an existing WordPress blog, to simplify the transition. Given the size of the WordPress user-base, it makes sense to be the first target for importing content.

I see two routes to go here:

WordPress Export

WordPress have a native export tool which uses a custom file format to export most of the key content, though doesn't include media, or any configuration. This still leaves a fair bit of work to be done, but it is probably the simplest option.

Custom WordPress Export Plugin

Another option would be to build a plugin for WordPress that exports as much as possible - comments, media, configuration information, user information, etc. This option would be more complicated as it requires not only building the import into Airship, but building the plugin for WordPress that would export all of this data.

Going with the custom export plugin would make for the easiest transition, as it would require the least effort for transitioning users, and would bring over all of the content that Airship can support. Though at a cost of several times the amount of work required.

Either option would be a substantial improvement over the current very manual process.

paragonie-scott commented 8 years ago

Exporting user information is the part I'm stuck on. There are several approaches we could take:

  1. Export the users as-is and create a gadget that allows for users to login with their old WP password. This would be handled by a Gadget, not placed in core.
  2. Export the users, but re-hash their existing password hash with Argon2i and store the salt along with a new legacy flag (as explained in this post).
  3. Export the users, and require them to reset their password to re-authenticate.

The third option is the easiest for me, but creates a bad transition experience for a multi-user system.

ghost commented 8 years ago

@paragonie-scott I was thinking about that while writing the description - my opinion would be to go with option 3 (it's the most secure, as it doesn't require handling a weak hash), and if there's pushback (or a large org willing to sponsor), then go with 2.

paragonie-scott commented 8 years ago

The folks I've asked on IRC said that 2 would be most useful for them. This means: I need to build a WordPress Import gadget that shims in the hashing (and, likely, add a UI wizard to the Bridge to ask for MySQL information to facilitate the import).

ghost commented 8 years ago

add a UI wizard to the Bridge to ask for MySQL information to facilitate the import

I would suggest not relying on having access to the original WP DB; as the airship instance may not be on the same server / infrastructure.

For me, due to the different requirements of Airship versus WP, Airship runs in a separate VM (in a different datacenter), so if it relies on DB access, it would require firewall games to allow access. If a user is coming from a shared host, they may not be able to expose MySQL at all.

My opinion is that it should export to a file, and then upload the file to Airship to be processed. I know it's a bit more complex than pulling it in directly, but it should greatly reduce the pain for users in the future.

paragonie-scott commented 8 years ago

That's a very good point. I'll look into their custom format ASAP. :)

paragonie-scott commented 8 years ago

The framework now exists for importing password hashes from other projects. We ship with a WordPress password hash migration utility. Others can be added in the future.

https://github.com/paragonie/airship/commit/7b2f8daa046d72eb49cd42454190a12fdf742b79