Leaderboard

I don't plan on forcing the option, though had thought that when enabled, we'd give them a login warning notification asking them to enable it, every time they login. I haven't come across any services that forces me to 2FA yet, though I know some companies require it internally. But I think it might depend on the 2FA method being used before you could say if it would be a good idea to force it or not. There are times where you might want to disable 2FA temporarily too. So I think it's best to let the user control it, and maybe annoy them a bit with warnings when they aren't using it. But this is one of those things where I think we'll start fairly simple, but then start fine tuning the options according to what we find are the needs of people using it. I think support in the core is consistent with PW's strategy of making security the top priority. I think we are soon reaching the time (or already have in some cases) where 2FA is considered essential in order for an online application to be taken seriously as having an emphasis on security. I consider it essential for any other online account I maintain (as I imagine many do), so it should be in PW too. If we step outside the security aspect, I think it also builds trust and checks boxes for a lot of bigger companies that may be considering PW or comparing to other options. The support and interface for it will be in the core. The implementation of the interface will be in modules. There will very likely be one implementation module included in the core, though I'm not 100% positive on that yet. Either way, I'll be building and maintaining at least one of the modules that supports it. As I understand it, Google Authenticator is just a standard implementation of RFC 6238 and RFC 4226, like any number of other authenticator apps. As far as I know, they are compatible with each other, but Google Authenticator is just the most widely known/used. I think the compliant you mentioned is the nature of the technology, and not really anything about Google Authenticator in particular. But the complaint is also the reason why it's secure. Once one understands how it works and the steps they should take, I think it all make sense. I'll try to describe. The reality is that 2FA is an extra step, which you can't deny is an inconvenience. But it's like locking your door before you leave the house. Nobody likes having to take extra steps, what they like is the security benefit (if they understand it). And if you lose your keys, then yes you are locked out, unless you've got a backup method. This is why services typically provide backup 2FA methods (like SMS) or one-time use backup codes that you can store securely somewhere in case you ever lose your device. For every place where you use 2FA, you've established "a secret" between your device and the service/website (a long base32 string, which can also be represented by a QR code image). The reason it is secure is because it's not shared anywhere else. If that secret were stored up in the cloud or synced between devices and such, then it is becoming less secure. It is getting passed around networks just like your password, which kind of defeats the purpose of 2FA. If you buy a new phone, and can't restore backup data from your old phone for some reason, the yes you'd want to reset your 2FA for the new phone. If you've got your old device handy, then you'd switch the 2FA to your new device. If your old device is lost or non-functional, then this is where a backup method and/or one-time use code would come into play. If those options weren't available, when it comes to PW, one could also fix any of this by asking a superuser to reset it even temporarily disabling from $config (if nobody had admin access). As I understand it, this is simply a matter of a user 2FA off for some account, then turning it back on, so they can establish a new secret/QR code. There's already a password reset module built into PW. 2FA can be disabled for any individual account as needed. This is what the superuser account is for. ? This is definitely part of the plan. Though with the 2FA methods I've been working with, we can't enable it for anyone that hasn't set it up themselves. Maybe with Netcarver's PPP module when using email, it could work. Or maybe it would work with SMS when you've already got the user's mobile phone number stored. It needs to know the user name in order to be able to look up the user-specific secret for the codes. Technically it doesn't need the password. But 2FA without a password is no longer two-factor, and would have its own security problems, which might be even worse than not having 2FA in the first place. If someone gets a hold of your device, and needs no password for your account, then they essentially have access to your account. Whereas, the intention with 2FA is that both your password AND your device are necessary. It's that combination of factors that makes it secure.

Hi @netcarver, Right now the module can't do that. It's on my to-do list to update this module so that it has a hookable method that would allow the sort of thing you're wanting to do, but not sure when I'll get around to that. For now you could use a hook to hide/disable the trash icon, similar to what I described in this topic: In /site/ready.php: $wire->addHookAfter('InputfieldFieldset::render', function(HookEvent $event) { /* @var $fieldset InputfieldFieldset */ $fieldset = $event->object; $attr = $fieldset->wrapAttr(); // Fieldsets in a Repeater inputfield have a data-page attribute if(isset($attr['data-page'])) { // Get the Repeater item $p = $this->pages((int) $attr['data-page']); if($p->hidden_field != '') $fieldset->addClass('no-trash'); } }); In some custom admin CSS: /* Hide and disable the trash icon while keeping its space in the layout */ .no-trash .InputfieldRepeaterTrash { visibility:hidden; pointer-events:none; } You could use display:none instead if you're not worried about the icon alignment.

This week we’re going to discuss a new security feature that’s currently in development on the dev branch: 2-factor authentication. In this post we look at the benefits of 2FA, how it works, the coming implementation in ProcessWire, and more: https://processwire.com/blog/posts/2-factor-authentication-coming-to-processwire/

In a current project I am using a Repeater field to build a kind of pseudo-table, where each Repeater item is a row. Some of the rows are headers, and some have buttons that toggle corresponding checkbox fields in a hidden FormBuilder form. The problem was that when the Repeater items were collapsed I couldn't see which rows were headers and which contained buttons. I tried including the fields in the Repeater labels but it still didn't provide enough visual difference to be quickly recognisable. So I investigated how classes could be added to selected Repeater items in admin depending on the value of fields within the Repeater items. This is what I ended up with... In /site/ready.php // Add classes to selected service row Repeater items $this->addHookAfter('InputfieldFieldset::render', function(HookEvent $event) { /* @var $fieldset InputfieldFieldset */ $fieldset = $event->object; $attr = $fieldset->wrapAttr(); // Fieldsets in a Repeater inputfield have a data-page attribute if(isset($attr['data-page'])) { // Get the Repeater item $p = $this->pages((int) $attr['data-page']); // Check field values and add classes accordingly // If item is a header if($p->row_type && $p->row_type->id == 2) { $fieldset->addClass('header-row'); } // If item has a checkbox button if($p->fb_field) { $fieldset->addClass('has-checkbox'); } } }); In admin-custom.css (via AdminCustomFiles) /* Special repeater rows */ .Inputfield_service_rows .header-row > label { background:#29a5aa !important; } .Inputfield_service_rows .has-checkbox > label .InputfieldRepeaterItemLabel:before { font-family:'FontAwesome'; color:#73cc31; content:"\f058"; display:inline-block; margin-right:6px; } Result

I have the same issue, no FB Events displaying since the new Facebook API updates. However, I found a temporary workaround: Temporary Workaround to make Facebook-Events module work again Cons: unclear future support needs manual token generation every two months needs small change in module Pro: it works, at least for now ? This solution uses an extended custom User Access Token instead of the Access Token created by the module. Step 1 Go to https://developers.facebook.com/tools/explorer and choose the app you’ve created. Click on Get Token -> Get User Access Token. Uncheck all permissions, especially user_friends (this was selected by default for me) since the API changes need apps to be reviewed by Facebook to grant access to this. Check only the pages_show_list permission! Click on Get Access Token. Now, a generated Access Token should appear in the Access Token field. You can test if this token works by testing the following api syntax (empty field under Access Token field): your-page-id/events/?fields=id,name,timezone,start_time,end_time,description,place,cover Replace your-page-id with your actual page id. You should get a JSON with all your page events in the response field. Step 2 By default, this generated token is only valid for a few hours. To change this, click on the blue round Info-button next to the Access Token. Click Open in Access Token Tool. In the Access Token Tool, click on Extend Access Token. Now, your Access Token should be valid for two months. After that, you have to repeat this process! Step 3 By default, in the Facebook-Events module settings (admin/module/edit?name=FacebookEvents), the config field for the Facebook Access Token is hidden. To change that, go to the FacebookEventsConfig.php file of the module, and on line 74, comment out the following line: ... ... $field->collapsed = Inputfield::collapsedHidden; // COMMENT OUT THIS LINE! ... Upload the modified FacebookEventsConfig.php file and refresh the Facebook-Events module settings. Now, the Facebook Access Token field should be visible. Replace this Access Token with the one you generated before! Now, everything should work again. ----------------------------------------------------------------- Please let me know if this worked for you. Let's see how long this will continue to work ? Also, when using this method, don't forget to renew your Access Token every two months! If somebody is able to modify the module to solve this programmatically, that would be awesome!

From the blog post: "This will enable us to support different types 2-factor authentication and different providers. Much in the same way that we support different types of email providers with WireMail modules." I think there must be API based support to make individual authentication methods easier to implement.

@adrian I guess it will vary. I can't see people with smallish brochure sites wanting it. However, I'm currently using PW to build an admin system for a charity. Most of the users are probably using their (child|spouse|pet)'s name + a year of birth as their password, yet they are trusted to handle their own client's confidential information on the system. I see 2FA as a big win for this kind of user, as a small change in log-in protocol can bring in a big benefit for the charity and its clients, by mitigating the risk of such poor passwords.

Yes! Very pleased to see this finally make it into the core. Thanks for mentioning my old module too - as it happens, I'm still using it, and just updated it to work with PHP7.2. Thanks, Ryan.

Neither I have an immediate need for rewrite in pure JS but I'm sure I'll try this on a new PW project (nothing in sight btw). I can have a look at it on next week if all goes well.

I was all set to suggest that you do this: but apparently the Sanitizer::translate option forces lowercase (https://github.com/processwire/processwire-issues/issues/643). Here's another interesting thing I just found: https://github.com/processwire/processwire-issues/issues/644 which doesn't seem expected to me. If Ryan agrees that the first one is a bug, then the alpha sanitizer with translate should result in this:

Generally speaking ProcessWire v2 modules should work under ProcessWire 3.x. The big change was to use namespaces in ProcessWire 3 but PW's "compiler" should take care of it in case of PW v2 modules. https://processwire.com/blog/posts/processwire-3.0.14-updates-file-compiler-fields-and-more/#file-compiler-updates If a module doesn't have a namespace, then FileCompiler will compile it to make it run under ProcessWire 3. Sure, there could be other issues as well, but it looks like a basic module using the PW API and was coded by Ryan, so I guess it works. Give it a try ?

All done. Simpler than I thought it would be in the end... $(document).on('wiretabclick', function(event, newTab, oldTab) { old_id = oldTab.attr('id'); new_id = newTab.attr('id'); if ((old_id !== new_id) && (new_id === 'Inputfield_mailing_actions')) { var changes = $(".InputfieldFormConfirm:not(.InputfieldFormSubmitted) .InputfieldStateChanged"); if(changes.length !== 0) { $('#Inputfield_save_btn').click(); } } }); The missing code was in the templates-admin/scripts/inputfields.js file at line 901.

@LAPS form-builder.inc: /** * * Add custom scripts to the form. * */ $forms->addHookBefore('FormBuilder::render', function($event) { $form = $event->arguments(0); $config = wire('config'); switch ($form->name) { case 'name-of-form': $config->scripts->add($config->urls->templates . "libraries/chosen/name-of-js.js"); $config->styles->add($config->urls->templates . "libraries/chosen/name-of-css.css"); $config->scripts->add($config->urls->templates . "FormBuilder/custom-js-init-file.js"); break; // other forms can be added below... } }); in your init file: $("#Inputfield_name_of_input").chosen({ no_results_text: "The planet exists not", allow_single_deselect: true, width: '100%' });

Got it... with a lot of trail and error. $this->user. $wire->addHookAfter('InputfieldPage::getSelectablePages', function($event) { if($event->object->hasField == 'turtles_fed') { $event->return = $event->pages->find("template=turtle, created_users_id=$this->user"); } });

Welcome to the forums @OxfordSUOliver If you have access to your files, paste the following temporarily into one of your template files and then visit a page that uses that template: $u = $users->get('sup'); // or whatever your supersuser name is $u->of(false); $u->pass = 'your-new-strong-secret-password'; $u->save(); Remember to delete the above from your template file once done. If you don't know the name of the supersuser, you can check this in your DB tables. See the pages table. Scroll down to user with ID 41 and check the string under the column name. Alternatively, temporarily again, in a template file, do the following: $u = $users->get(41); echo $u->name;// this is the name you want for logging in Note the original ProcessWire Superuser ID is normally 41, unless for some reason your colleague changed it, which would be highly unlikely, although they could have deleted that user having set up an alternative Superuser ?.

You can achieve something (that I think is better) using a the Repeater Matrix (profield). I was actually playing with this the other day. I created several "blocks" ie image/text, quotes, slideshow etc etc and with very little effort (output styling not included) had a homepage built. I like this approach better than Visual Builder as it allows the developer to have a bit more control of the output (styles/layout). In my experience, vb can lead to bloat, and a very fractured site structure. It also, at times, makes it difficult to find where pieces of the site are located.