My Two Cents on Two Factor

Two-factor authentication should (imho) be in core, but core can’t always provide the best ways to accomplish it, for example, text messaging which requires external APIs.

What I see the best fit being, is this:

There is a framework for Two-Factor Authentication in core, that provides two free no-api-required methods for users to select to validate:

  • Email (with a warning that it’s not as secure)
  • Time-based One-time Password Algorithm (TOTP)
    • This is what Google Authenticator / Authy use.
    • IETF RFC6238

Beyond this, Core would offer a filter to permit plugins to register other authentication methods, for example, Duo Security’s push-based request system, or Jetpack could provide a gateway for text-messages, just as they are sent from WordPress.com.

We would also need to allow a define( 'DISABLE_TWO_FACTOR_AUTH', true ); line in wp-config.php that would switch it off, in case a site owner lost their phone and needed to disable it temporarily.  I could also see use for a customized define to only disable it for a given user.  Ideally this would add a warning to the adminbar for all users that have manage_options() to notify them that it has been disabled.

Other dependencies that would need to be in core:

  • Application Passwords
    • For systems where the user cannot be prompted for a two-factor auth code (XMLRPC, etc), disallow their normal password for authentication, and force them to use a generated application password that is stored in usermeta.
    • For systems where the user can be prompted for a two-factor auth code (wp-login.php) don’t permit the use of application passwords.
  • Backup Auth Codes
    • Saved in usermeta, not terribly much interesting here.

ComicPress and Jetpack Photon

Howdy, all! Just a bit of a reminder if you’re a webcomic creator, and you’re running your webcomics on WordPress, you can get a pretty big performance improvement (and savings on bandwidth costs) if you activate the Photon module in Jetpack.

http://jetpack.me/support/photon/

Photon is a free Image Content Delivery Network hosted by WordPress.com. For most content images (depending on how your theme is serving them up), it will just swap out a CDN url of the image automagically, nothing to configure.

If you’re using ComicPress, though, it’s got some funky ways of outputting images just due to legacy code.  It’s pretty easy to fix, though:

Just upload this as a new file entitled comicpress-photon.php to your /wp-content/mu-plugins/ folder — or add it into your theme (or preferably child theme)’s functions.php file (but without the opening <?php)

It’s a huge savings on your hosting account because when serving images, your shared host has to keep talking to the client the entire time that the image is downloading, which can occasionally take longer than creating the page that the image is embedded in! So if your webserver has less load, it behaves better, your hosting company is probably happier with you, it’s not getting choked with serving up images when it could serve up HTML or the like, and you’ll instantly become 200% more attractive! (Okay, I lied on the last one)

OLYMPUS DIGITAL CAMERA

Translations Abstraction Proposal for WordPress

plugins.svn.wordpress.org:

  • There is a new special folder in Plugin Repositories, at /assets/i18n/
  • A /assets/trunk.pot file should probably be maintained for support of repositories where trunk is their public release version.
  • Whenever a new tag is created, for example /tag/3.2-beta1 (a script automatically|the plugin author) generates the po/mo source files, and stores it as /assets/i18n/3.2-beta1.pot or the like.
  • I’m torn as to who generates this, and I have no desire for this to generate additional changesets on our already burdened plugins.svn.wordpress.org — perhaps they could live elsewhere, and wouldn’t necessarily need to be under version control.
  • A /assets/i18n/master.pot and the like file may be maintained which is a merger of all the strings in all the versions in all the tags.
    • This is to simplify things so that if a string is dropped from one version to the next, it is still included in a master index, potentially simplifying things from a storage perspective, so that if requesting translations for a plugin, a version number does not need to be specified, and GlotPress wouldn’t need to store fifty copies of the same string for the same plugin, if there are fifty different tagged versions.

plugins.glotpress.wordpress.org

  • I know very little about the inner workings of GlotPress currently, so I’ll leave this part of the proposal as a ‘black box’ that magically works.
  • Sharing identical strings between plugins would be amazing, if possible, but with the ability to break the link if one plugin author needs it to be translated differently.  But I suppose that can be done with _x() and notes for translators.
  • API requests for translations shouldn’t by default be given up-to-the-second results.  If there’s a cached version from the last 24 hours, or it hasn’t been invalidated with any new translations yet, just serve that version up.
  • Gzip it all in transit & storage.

core

  • This would be implemented as a plugin tentatively by using the 'override_load_textdomain' filter — which would then query the API and either store the translations in a transient/option, or in a folder within /wp-content/.
  • If not using a transient, set a wp_cron task to check for updates every X days, weeks, or on upgrades / installs / manually pushing the update translations button.
  • Store a version number for the most recently received translations, and pass that back with subsequent queries, so it only receives the strings that have been updated since the last pass (huge potential savings on bandwidth and server processing time).
  • On the (client|server) side, round the version number down to a given interval (thousand, ten thousand?) so that it can be cached more easily on the server side.  A couple duplicate translations could get delivered, but that’s a small price to pay for the savings in processing time.