Register Plus Redux

Posts regarding the plugin, Register Plus Redux.

Note, this article revisits an article I previously wrote, “WordPress Multisite and the Disregard for Plugins”. For one thing, that title was a little too broad, hence, this article’s title, “WordPress Multisite Activation and its Illogical Disregard for Plugins” which corrects that mistake. Secondly, I previously discussed Marco Cimmino’s Cimy User Extra Fields as a cornerstone in my solution. Since then, I have further analyzed WordPress core and come to a different yet equally valid solution. I will discuss the merits of each in turn later, but first, what do I mean, Illogical Disregard for Plugins?

Two years ago I began my quest to “port” Register Plus Redux to WordPress for Networks/Wordpress Multisite. I thought this would be pretty simple, in fact I was hoping to make most of my existing code work in both scenario, perhaps with some type of overloaded hook function to funnel variables to one common function. I quickly learned that WordPress MS (my preferred name), with its signup/activation system significantly deviates from single WordPress’ registration process. In fact considering the hacky, silly way I implement my own “activation” system, via user email verification and administrator verification I found WordPress MS’s system to be a significant improvement over my own which alters the user_login to isolate “unactivated” users (one I’m looking to steal via my own ‘signups’ table in a future revision). Regardless, systematically, WordPress MS signup couldn’t be any more different from WordPress registration, down to the user experience which brought its own problems.

My real problem began, and ended with activation, that which follows the signup. Following a valid signup, Redux was able to store added fields, first name, last name, additional fields, invitation code, etc in WordPress’ signup table in a meta field. However, I could not, following any amount of effort restore that stored meta data. First I thought I was ‘misreading’ the meta data from the database, which seemed odd considering the simple nature in which it was stored. Then I though that these were unrealized hooks which brought me down a terrible path of analyzing what and how hooks are defined and activated in WordPress core. I learned that hooks aren’t so much defined, you can hook to any string, so long as a do_action or apply_filter uses that same string, that hook will activate. So that debunked that fear. Eventually I just had to find another “working” plugin, which brought me to Marco Cimmino’s Cimy User Extra Fields. There might be a few others out there, but the market for WordPress MS Signup alternation seems pretty slim so Cimy appeared to have a real choke hold on this corner of the plugin field.

Cimy’s solution involved “must-use” code, that is another php file that must be manually placed in WordPress’ mu-plugings folder. Must use plugins load regardless of all else, they cannot be activated, deactivated, installed or uninstalled within your WordPress control panel. They exist, therefore they run. Cimy’s separate mu-plugin in turn called to the regular plugin, this making the entire plugin a mu-plugin. This worked, and I thought it might be the only solution, until I prepared to open a ticket on WordPress Trac to complain about this behavior. In the process of isolating the behavior I came to notice that there was a flag, WP_INSTALLING, checked when loading plugins from wp_get_active_and_valid_plugins. I didn’t think much of this, it seemed fair to assume plugins aren’t loading during WordPress’ installation process. Then I had my epiphany. wp-activate.php throws up this WP_INSTALLING flag. That brought me full circle and I thought I finally understood the full extent of my problem. Not that I understood why, but at least I understood how. Digging deeper, and stepping through WordPress initialization I realized WP_INSTALLING isn’t checked against network activated plugins. Now I had an alternate solution. Still no explanation, but again, two solutions for this quirky behavior is better than none!

The nice thing about network activation over must-use is that network activation can be handled completely within WordPress’ control panel. You install the plugin as always via the Plugins menu, then click Network Activate. Simple enough. Must use can be installed via the Plugins menu, but as I mentioned earlier means administrators must open up a FTP session or such and move files from the plugins install directory into the mu-plugins directory. Both solutions ultimately lead to the same conclusion, the plugin will be available to every site in the network and, most importantly, actually work. Both solutions also have the same flaw, the plugin is available to every site! Each site’s administrator need not activate the plugin, they don’t get any choice. In the case of Redux, I put a lot of effort to ensure that by default, Redux modifies nothing. You most activate features from Redux’s settings in order for it to alter any of WordPress’ default behavior. Other plugins may not be so respectful. All of which is beside the point, I chose to encourage administrators to network activate Register Plus Redux. I find that to be a simpler solution. Must use isn’t impossible, or even difficult to “activate” yet I find it troublesome that you cannot easily disable Redux, you would have to go into the mu-plugins folder and delete Redux’s must use php file, or at least move that file out of the mu-plugins directory. That isn’t very, “easy” in my opinion. Like I said neither approach appears to be wrong, but I have my own preferences.

Long story short, Register Plus Redux now works on WordPress Multisite. The whole exercise has forced me to move further along with my code decoupling. It’s been a todo of mine to break my monolithic php file into pieces, so that only utilized code is loaded. Redux 3.9 has turned into quite a monster. I expected to roll out some of these “big” features over 3.9, 3.10, and ultimately 4.0. But I guess I’m making up for the lost two years of development all at once!

Finally, and most importantly, I completed my initial 3.9 code base. I created a new tag on WordPress SVN and have sent a request to to have Redux back online in the plugin repository. I hope to hear back soon so that you can enjoy Redux without needing to leave your control panel. In the meantime, here’s a zip file for anyone interested. Break it as best you can so that I can make a better plugin. I’m back in business and hope to have 4.0 finished sometime before 2014! In store, a revised user verification system (à la WordPress MS), full functionality for WordPress MS (currently some features aren’t ported over, customized emails and autologin to name a few), and, perhaps pie-in-the-sky, but a shortcode droppable registration/signup form so that you can register users anywhere. I wouldn’t mind playing with user creation from the back-end, as is, if you have added fields during registration, you’d have to create a user then edit that user to enter the same information. That isn’t ideal, but just quickly reviewing WordPress admin code, I don’t see anyway to alter the new user form. I may have to make a separate Expanded Add User page or something along those lines. Not my dream project but something I kick around in my head for completions sake. Rant over, enjoy Redux 3.9, I hope the whole world does soon enough!

I recently lost a hard drive containing all my work to-date on Redux. I was certain this was going to cost me another year, but fortunately, I realized, I’m an idiot. I have a test site that runs the WIP copy of Redux, so I downloaded a copy, added the most recent changes that I hadn’t even posted to the test site yet and had a working copy of Redux. Phew. Crisis averted. But this did make me realize, I’ve been making these changes awfully haphazardly. So, I’ve finally pushed a massive update to WordPress’ SVN with all the changes to-date. This doesn’t make Redux available for download to the whole wide world again, but it does make it available to developers, so, it’s a start.

Regardless, I’ve finally started taking JetPack apart, but that is just about the last thing I wanted to do before publishing 3.9 for real. Well, I think the whole idea of XSS via CSS to be rather ridiculous, so, I’m posting 3.9 for you now! If you agree with me, then go nuts, download this copy try it on your development sites and let me know what works and what doesn’t! As far as I know this version should even work with WordPress Multisite! Of course I’m sure there’s something I’ve messed up here and there. I’ve been writing this for 18 months off and on, more off then on. I’ve probably thought up the same bugs ten times in that period of time, and resolved them in my head six times, and yet, I bet they are still there. Sigh.

Fortunately, I really should have some time on my hands to get this all cleaned up as I am between jobs at the moment and also out of school. Honestly, I need to get this all cleaned up sooner than later, once I get into my new job, I won’t have free time for some time.

As of February 6, Register Plus Redux is back on with version 3.9.1!

One of the long-standing issues preventing the release of Redux has been Custom CSS and the nasty potential for cross-site scripting. Well, as I’ve been twiddling my fingers wondering and wishing a solution would come to me, one finally did: JetPack 1.7. This comes as some surprise to me. I was just routinely updating my plugins, reading through changelogs (as I am want to do) when I noticed a new feature. The ability to edit a theme’s CSS. Hm. Well I immediately dug into the JetPack code and noticed the inclusion of CSSTidy. Excellent. You know the saying, ‘good artists copy, great artists steal’. Well, that’s the plan. So I am currently trying to absorb this code into Redux. Once that’s done, well, that will close my last major loophole! Exciting stuff.

Of course, knowing myself as well as I do, I can’t promise a timeline, but I’ll hope for yours and my sake that it isn’t too long. I really would like to be “done” with Redux for a little while. It’s a nagging feeling to have code incomplete.

After deeply analyzing MustLive’s code changes, I believe I’ve closed most of the holes he found, in my own way. MustLive made valid changes, but I found them draconian. Regardless, the holes he found were valid and I have, after significant research, closed them in a manner more fitting the desired functionality of Redux.

One problem area was created by some jQuery used on the Settings page. The jQuery in question analyzes your settings and displays a summary about when and what email your specific settings will cause. This is a relatively new feature, and a mildly frivolous one too. But I thought it would be handy, instead of musing over your settings, you get a real-time update. The problem is that this jQuery is slightly vulnerable. Someone could potential alter the post data displayed on the settings page. I’m not sure how, honestly, but logically, I see the potential vulnerability.

MustLive’s solution was to convert potential HTML tags to text. That works, but it wasn’t quite as elegant as I’d like. Fortunately, my post on stackoverflow resulted in a solution. I now handwrite the summary HTML, element by element. I’m not exactly sure how to summarize it any better, but this eliminates the vulnerabilities in that code.

The bigger, and more prevalent problem, was the unhindered HTML access I allowed administrators. MustLive pointed out the following vulnerable fields.

Email Verification Message (message_verify_user_email)
Admin Verification Message (message_verify_user_admin)
Custom New User Message (user_message_body)
Custom Verification Message (verification_message_body)
Password Meter Empty Message (message_empty_password)
Password Meter Short Message (message_short_password)
Password Meter Bad Message (message_bad_password)
Password Meter Good Message (message_good_password)
Password Meter Strong Message (message_strong_password)
Password Meter Mismatch Message (message_mismatch_password)

And I realized the following fields are equally vulnerable.

Custom Admin Notification Message (admin_message_body)
Disclaimer Content (message_disclaimer)
License Agreement Content (message_license)
Privacy Policy Content (message_privacy_policy)

Again MustLive’s solution was to scrub out any HTML. Which again works, but this change I found undesirable. Whereas the jQuery code he modified was not functionally eliminating anything, this change would reduce Redux’s functionality. An administrator should be able to create a message with bold words, or a link to any other page. Whatever they like, in my opinion. This vulnerability, to me, is kind of an administrator’s problem in a way. But, it doesn’t reflect well on Redux, so there had to be a solution. After thinking way too long about it, the obvious one surfaced, white listing. But I didn’t really feel like writing up a white list. Who am I say what’s good, bad, or indifferent. However, WordPress already makes judgements, all the time, using wp_kses_data. Now, those fields are secured like any other post you’d write on your site. You can have links, headers, tables, all sorts of stuff, but no “evil scripts”. Excellent.

So, we secure the admin side with esc_textarea and the database side with wp_kses_data, but what can I do about potential SQL injections? Well, I’m still scratching my head there. I guess I could run it through wp_kses_data before and after the database, but that seems silly… Either way, this doesn’t end my pursuit of perfect security. MustLive also pointed out potential XSS via CSS, another field I have given admin’s unrestricted access to. Unfortunately, there aren’t any handy WordPress sanitization functions for CSS, so I’m going to have to roll my own. Yay, right?

For those of you keeping track at home. Here’s my worksheet for securing all possible settings. I haven’t included boolean variables because I don’t do anything funny with them. If they are positive, one thing happens, if not, another. SQL injection could turn on and off functionality, but at that point, the whole site is probably in flames and I’m not dramatically concerned with that.

Updated 12/21/12 to reflect changes made in Register Plus Redux 3.9

Admin textbox fields, URL
* Apply esc_attr on display to admin
* Apply esc_url on use
* Apply esc_url_raw before commit to database
Custom Logo URL (custom_logo_url)
Registration Redirect (registration_redirect_url)
Verification Redirect (verification_redirect_url) (unused)

Admin textbox fields, email address
* Apply esc_attr on display to admin
* Apply is_email on use
* Apply sanitize_email before commit to database
Custom New User Message From Email (user_message_from_email)
Custom Verification Message From Email (verification_message_from_email)
Custom Admin Notification Message From Email (admin_message_from_email)

Admin textbox fields, text
* Apply esc_attr on display to admin
* Apply esc_html on output to page
* Apply sanitize_text_field before commit to database
Disclaimer Title (message_disclaimer_title)
Disclaimer Agree Text (message_disclaimer_agree)
License Agreement Title (message_license_title)
License Agreement Agree Text (message_license_agree)
Privacy Policy Title (message_privacy_policy_title)
Privacy Policy Agree Text (message_privacy_policy_agree)
Custom New User Message From Name (user_message_from_name)
Custom New User Message Subject (user_message_subject)
Custom Verification Message From Name (verification_message_from_name)
Custom Verification Message Subject (verification_message_subject)
Custom Admin Notification Message From Name (admin_message_from_name)
Custom Admin Notification Message Subject (admin_message_subject)

Admin textbox fields, numeric
* Apply esc_attr on display to admin
* Apply absint on use
* Apply absint before commit to database
Grace Period (delete_unverified_users_after)
Minimum password length (min_password_length)
Starting Tabindex (starting_tabindex)

Admin textarea fields, HTML enabled
* Apply esc_textarea on display to admin
* Apply wp_kses_data before commit to database
? On output to page
Email Verification Message (message_verify_user_email)
Admin Verification Message (message_verify_user_admin)
Custom New User Message (user_message_body)
Custom Verification Message (verification_message_body)
Custom Admin Notification Message (admin_message_body)
Disclaimer Content (message_disclaimer)
License Agreement Content (message_license)
Privacy Policy Content (message_privacy_policy)

Admin textbox fields, HTML enabled
* Apply esc_attr on display to admin
* Apply wp_kses_data before commit to database
? On output to page
Password Meter Empty Message (message_empty_password)
Password Meter Short Message (message_short_password)
Password Meter Bad Message (message_bad_password)
Password Meter Good Message (message_good_password)
Password Meter Strong Message (message_strong_password)
Password Meter Mismatch Message (message_mismatch_password)

User fields, potential HTML
* Apply esc_textarea on display to user
* Apply wp_filter_kses before commit to database
User Description (description)
Custom Textarea Meta Fields

Admin textarea field, CSS enabled
* Apply esc_textarea on display to admin
* Apply esc_html on output to page
* Apply CSSTidy before commit to database
Custom Register CSS (custom_registration_page_css)
Custom Login CSS (custom_login_page_css)

Admin textbox field, CSS enabled
* Apply esc_attr on display to admin
* Apply esc_html on output to page
* Apply CSSTidy before commit to database
Required Fields Style Rules (required_fields_style)

Register Plus Redux was removed after the following vulnerabilities disclosed to were forwarded to dated 9/18/2010 dated 4/18/2011

At the time, I didn’t think much of these vulnerabilities. To be honest, I still don’t. I couldn’t figure out how to replicate them. To be honest, I still can’t. Maybe that makes me a buffoon, I don’t know. The fact that they are in Ukrainian, certainly didn’t help. On top of that, I just don’t get it.

My knowledge of XSS is limited to the following. When you take information from HTTP GET or POST, you need to validate it because anyone can spoof that data. OK, cool. I try to keep that in mind, I think I do OK in that regard, although I did find a couple oversights following this whole debacle.

My problem, I think, might be philosophical. Honestly, being that I am a self-taught programmer, words escape me trying to explain my “philosophy”, for lack of a better word. On the Settings page, I allow HTML to be entered in custom messages. Such as when someone goes to the Registration page and you want it to say, “You will need a confirmation number to register, <click here> for more information.” In the code I received from MustLive that is prohibited. And here is where his report and my knowledge diverge.

Is there a potential for the HTTP POST information to be modified, thus setting that message to something malicious that… I don’t know, yanks cookies and sends them to some far off bad guy, for example. Sure. But, I use a nonce and check_admin_referer as recommended my WordPress, and, as far as I know, as used by WordPress core. Whenever possible, I have referred to WordPress core files and used the same syntax and functions used on core pages. So, how is Redux any more vulnerable? I just don’t understand and I scratched my head for a while, and then gave up.

But from time to time, I think, maybe I just didn’t look at it hard enough, maybe I’ll see something new. Still nothing. So last week, I turned to the internet.

Potential jQuery XSS

This is a more specific problem that MustLive pointed out. However, I figured it was one of the easier ones to recreate without getting into WordPress as a whole.

Surprisingly, to me, no true replies. Not to attack the only person who responded at all, Jonathan Rowny, but his response to me, just sounds more of paranoia. This “problem” was big enough to get Redux yanked, but yet the only solution is to prohibit any HTML and reduce functionality, for what?

Anyway, I don’t want to dismiss MustLive, Jonathan Rowny, or anyone else that ever asked me about this or sent me a message. Nevertheless, I still don’t know what to do to make them happy, and you, constant user, secure. I would run this plugin on my page. I do. Not for any reason, there’s no point in registering here, just so I can test it myself.

Long story short, I just don’t know what to do, and we are still where we were a year ago.

OK, phew, long time no… anything. I’m very few removed from WordPress these days, as if that isn’t obvious. But I can tell there is still a great deal of interest in Register Plus Redux. MustLive has commented here and there about some changes he made. Now, the problem, for me, is that he made changes to the trunk build, which no one should have been using. This is both good and bad. I made hundreds of changes to the trunk, so many I couldn’t even figure out where to begin verifying what worked and what didn’t after stepping away for a couple of months. I was incredibly terrified to publish 3.8 because I had no idea whether it worked at all! Well I guess MustLive at least proved that out for me. He found a few literal bugs, but mostly he addressed vulnerabilities as he saw them. Here is a complete changelog he sent me.

  • Fixed 36 vulnerabilities of version (almost all holes, except two one). Including Insufficient Anti-automation hole – added CAPTCHA (from Register Plus, which was removed in Redux) and turned it on by default.
  • Added option for autologin user after registration. Note, that in version 3.8.1 the autologin future was working. But after version 3.8.2 version, it is broken (for some unknown reasons).
  • Added option for removing Confirm Password field.
  • Fixed bug with saving user’s password at registration.
  • Fixed bug with incorrect username in emails to admin and user at enabled option Email Verification or Admin Verification.
  • Fixed bug with Require Agreement checkbox.
  • Added option to send administrator an email after verification of new user.
  • Fixed bug with user verification with using of verification code.
  • Fixed 2 vulnerabilities of version (last two holes).

This, with my own changes to data verification (esc_attr instead of stripslashes for example), a complete re-write of Register Plus Redux settings, support for WordPress Networks (which I still haven’t verified), and whatever other changes I forgot about along the way equates to Register Plus Redux 3.8.4. I still consider this unofficial, partly because I haven’t completely reviewed all MustLive’s changes, but mostly because I can’t vouch for my own changes since 3.7.

So where does that leave us? Well I’d like to get Redux back on WordPress proper, but I think I need help. I would like to take this from a one-man show to a team. I am looking for anyone who wants to contribute to keep Redux alive and growing. If you have contributed patches, or forked your own build, please, contribute. I’m not a glory hound, I want everyone to get the credit they deserve. I want to open up the repository, contributors can make changes and when we as a group feel like they have taken shape, we can branch off and publish builds. I can’t say I’ve ever worked in a group before, but there’s a first time for everything. We aren’t writing an operating system, I think this can be done, effectively, and relatively easily. Also, what to do with any donations, if they ever occur needs to be discussed. I would say split them equally among contributing developers, but that’s just my opinion.

If there’s anyone out there interested, let me know. I’m not going to lose sleep over the death of Redux, but I’d like to see it back out there benefiting the community.

Finally, here it is, Register Plus Redux 3.8.4, “There be Dragons Edition”.

So, I’m in the middle of revising the invitation code system for a specific user. In the process I’ve got myself into a quandary. This user needs each invitation code to be unique, so there will be a new option to only allow invitation codes to be used once. That pretty much satisfied them for the immediate time. Now, I’ve come across two problems. First, when a user is deleted, should their invitation code be deleted too? I’m thinking we need an option for this behavior. Second, if an invitation code is deleted, what should happen? This one’s trickier and could require several changes. So, I present the question to you, loyal Redux users. Let me know what you think.

This will be where I discuss and attempt to resolve wp_new_user_notification conflicts.

Maintenance Mode
Resolved in version 5.3 of Maintenance Mode
Was loading pluggable.php from constructor. Please refer to The Case of Maintenance Mode for more information.

Login with Ajax
Resolved in version 3.0b3 of Login with Ajax.
Defines its own wp_new_user_notification. Plugin now only defines wp_new_user_notification under certain conditions.

Absolute Privacy
Defines its own wp_new_user_notification.

Events Calendar
Is loading pluggable.php from constructor.

Is loading pluggable.php from constructor. But not quite so bluntly, Mingle’s code determines whether it needs to load pluggable before loading it. There must be some calls that need to be moved around to get Mingle to stop loading pluggable. This could be traceable, but only by a dedicated Mingle user or developer. The root offending file is MngUtils.php located in the mingleclassesmodels directory.

PDF24 Article to PDF
Is loading pluggable.php from constructor.

TDO Mini Forms
Is loading pluggable.php from constructor.

Cimy User Extra Fields

WP Better Email