davelopware

forgot to say, the email contents can be tweaked by hooking into the filter ‘retrieve_password_message’

Henrik, thanks for replying.

In terms of #3, I agree, it results in an underlying single factor auth for everyone, which is far from ideal.

But equally the current procedure for handling lost phone or un-installed authenticator app, drastically limits the audience for the plugin. Most of the people for whom I develop plugins are web designers or “advanced end-users” 90% of which wouldn’t be comfortable messing with this kind of workaround procedure.

How about, a compromise. When the user has lost their phone we’re going to HAVE TO rely on their password. We could use their email as a second factor, by hooking into the password reset workflow… eg:

When a user who is an “authenticator enabled” user does a password reset, then:

(a) add another link in the reset email that goes out, that they can use to disable their ‘authenticator-ness’.

You can do this by adding another parameter to the same url which already goes out in that email [ retrieve_password() in wp-login.php uses the following to generate the reset url: network_site_url(“wp-login.php?action=rp&key=$key&login=” . rawurlencode($user_login), ‘login’) ]. you could add something like &gauthdisable=1 to the end to indicate the google authenticator flag disable instruction.

then in you could…

(b) catch that extra parameter in action ‘login_form_rp’. replicate the checks that wp-login.php does for case ‘rp’: such as check_password_reset_key() and if it passes, then disable the 2FA. You’d have to also blank user_activation_key for that user in the database too, so that the same link can’t be used again [see wp_set_password() in pluggable.php]

So in summary, if user’s lost their phone, they just need to do a password reset, and click the link in the email that says ‘Disable your Google Authenticator setting’. They can then log in using 1FA (which is the only factor they’ve got left).

Thoughts?

kind regards

Dave Amphlett

And – another thing ?? when a users activates the authenticator feature, then I think it’s really important to do an authenticate challenge and only enable it if they can enter a valid authenticator code!

If you can access your database directly, then you need to tweak the value of data in the wp_options table as follows… First: Find the record with option_name = ‘active_plugins’. Second: update the option_value for that record to be exactly the same but with the following single character change: “google-authenticator/google-authenticator.php” -> “google-authenticator/google-authenticator.phx” . Notice we’ve just changed the php at the end to be phx. This will disable the google-authenticator plugin, and give you a warning when you login that the (non-existant) google-authenticator.phx plugin has been disabled which you can ignore. When you’ve got everything ready to rock again, you can simply activate the authenticator plugin again via the admin pages.

Thanks dodmax – great tip on the widgets.

I know the documentation is a somewhat self-referential example of using wp-mvc itself, but I keep wishing it was a wiki that we could all pitch in with ??

I’ve just added a shortcode functionality patch to my branch on github.

It’s really simple if I do say so myself – you just need to add a bit of config in your app/config/bootstrap.php which maps a new shortcode to controller/action and substitutes the result of the associated view when displayed.

There’s even an example in the commit comment here:

https://github.com/damphlett/wp-mvc/commit/7867af1b2ab9fcdfb73331341cda06ecf2130215

The example might seem slightly complicated because it covers the extra functionality that lets you to specify, in the config, allow_actions and deny_actions. This is because you can specify the action as a parameter to the shortcode to hit any action on the mapped controller.

But because shortcodes can often be entered by low-privileged users, it makes sense to be able to limit what actions they can perform with a shortcode.

Thanks for all your help with this dodmax, it really helped.

I ended up hitting another issue where I wanted to join with another table, but not based on the primary key! I’m working on a patch for that on my branch where you can specify a ‘local_key’ as follows…

class Person extends MvcModel {

	var $has_many = array('NameMeaning' => array('local_key' => 'fname', 'foreign_key' => 'name'));

}

I’ll check it in once I’ve got some confidence in it. But that set me thinking about testing – might be good to build some tests around wp-mvc. There’s serveral of us hacking on it now.

DODMax, do you have any preferences for a testing framework? I’ve used
Mockery before and got on well with it. I might start putting some tests together based on that if no-one else has done anything on testing yet.

In the absence of anyone else looking at this, I’ve made a start on it. You can find it on my fork of the code on github here:

https://github.com/damphlett/wp-mvc

the commit associated with this change is here:

https://github.com/damphlett/wp-mvc/commit/7ab2e9fa21f30146d43e78a2872c40c3b44d9f9c

and the commit comment has a simple example of how you can extend MvcModel to implement a model that ISN’T backed onto a database. The example shows the beginning of a model which enumerates the File System (directories and files) for the WordPress installation.

Thanks for the reply and I can confirm that both of these approaches work perfectly.

I must admit it leaves me wondering how I’m going to handle the situation in the future when I want two different fields in the same model to reference two separate instances of a second model, given that I’m referencing the associated model by it’s name.

An example in the original context might be

var $belongs_to = array(

	'JungleBranch' => array(
		'foreign_key' => 'favourite_branch'
	),

	'JungleBranch' => array(
		'foreign_key' => 'home_branch'
	)
);

I’m thinking of something in terms of

$includes = array(
	'favourite_branch' => 'JungleBranch',
	'home_branch' => 'JungleBranch'
);

Which maybe would change both the $object->favourite_branch and $object->home_branch from being just ids, into to being the appropriate instances of the JungleBranch model.

Is there a way to do this at the moment, or anything in the works to enable it? If not I might have a shot as doing a patch for it.

No problem ??

check out:

BuddyPress -> Invite Anyone -> General Settings

then look for the setting:
‘Number of email invitations users are permitted to send at a time’

which is about the 6th one down

for the “The plugin does not have a valid header” issue, go to…

Plugins -> Installed Plugins -> Invite Anyone -> Edit

change the first 3 lines from:

<?php

/*

to:

<?php
/*

ie. remove the blank line from between <?php and the /*

You should then be able to activate the plugin.

Having said that, I’ve activated it and still can’t see the Send Invite link ??

Go to…

Plugins -> Installed Plugins -> Invite Anyone -> Edit

change the first 3 lines from:

<?php

/*

to:

<?php
/*

ie. remove the blank line from between <?php and the /*

You should then be able to activate the plugin.

Having said that, I’ve activated it and still can’t see the Send Invite link ??

Go to…

Plugins -> Installed Plugins -> Invite Anyone -> Edit

change the first 3 lines from:

<?php

/*

to:

<?php
/*

ie. remove the blank line from between <?php and the /*

You should then be able to activate the plugin.

Having said that, I’ve activated it and still can’t see the Send Invite link ??