Coming soon: The next generation of FrontEndUsers

Have a question or a suggestion about a 3rd party addon module or plugin?
Let us know here.
Post Reply
calguy1000
Support Guru
Support Guru
Posts: 8169
Joined: Tue Oct 19, 2004 6:44 pm
Location: Fernie British Columbia, Canada

Coming soon: The next generation of FrontEndUsers

Post by calguy1000 »

I have recently been working on some code to refresh the FEU module, clean it up, make it more efficient and documented, and to allow for functionality like Two factor authentication and external authentication.

I am near finished only some testing and documentation remains, and I will be able to release the new FEU v3.0 along with a new registration module a new sample 2FA module using Twillio and a Twitter authentication module.

There are a few new features in the new and upcoming FEU module:
- A new field type or two
- Cleanup of field properties
- New field properties like 'placeholder'
- A cleaner and more efficient, extendable and documented API
- A well documented API
- Extensive use of hooks
- Refactor internal authentication to use 'AuthTokens' (with an expiry) and cookies instead of the session. Cookie data is non personal, obfuscated, and signed. Long term (remember me) cookies can allow a user to remain logged in using the same browser for up to 90 days.

And there will be some breakages in the new FEU v3.x
- Removed all direct integration with the design manager so by default, on new installs all templates are file based. For upgrades you must now specify the name of the design manager template.
- Removed all redirection preferences/settings and allow that to be done in various templates.
- Removed the settings panels and placed all settings in the config.php
- Removed support for the encrypted field type as it was problematic
- Removed ECommerce integration as it was flawed.

--
The new Registration module CGFEURegister replaces Selfreg for FEU v3+. It is small, light weight, and secure. It uses file based templates by default, and has more features than Selfreg ever did. Selfreg will not be upgraded to work with FEU v3+.

--
CGFEUTwillio2FA is a sample module that I implemented to prove two factor authentication. After a user has entered his username and password, It uses Twillio (a paid service) to send an SMS to the phone number associated with an account. The user must enter the code in the SMS into a form in order to complete the login process.

--
The CGFEUTwitterAuth is a simple module that implements Oauth, allowing users to authenticate to your website using the twitter service. Once authenticated, users can change their settings, and interact with FEU normally. The only functionality that is different for users is that they cannot change or verify their passwords.

These changes to FEU are extensive and appear dramatic, so I wanted to give people a heads up. There will be more details in the changelog when everything is released.

Going forward, after FEU 3.0 is released I will be discontinuing maintenance on SelfReg and only addressing critical issues in FEU 2.x for a period of time.
Follow me on twitter
Please post system information from "Extensions >> System Information" (there is a bbcode option) on all posts asking for assistance.
--------------------
If you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
calguy1000
Support Guru
Support Guru
Posts: 8169
Joined: Tue Oct 19, 2004 6:44 pm
Location: Fernie British Columbia, Canada

Re: Coming soon: The next generation of FrontEndUsers

Post by calguy1000 »

This is the current changelog for v3.0 of FEU. For a heads up.

THIS IS A MAJOR UPDATE
You should have a backup before upgrading! Please ensure that everything works properly on your staging site before pushing these changes to your live site.

There is some breakage in this release. Some actions have been removed, and all frontend templates have changed. Some functionality has been removed completely, though most has new ways of accompishing the same result.

All frontend templates have changed. You will probably need to restyle your templates. Also, you will probably need to modify your templates to use {cms_module_hint} to specify the name of the FEU template that you wish to use for FEU related views.

Since the authentication storage mechanism now uses cookies formatted differently, any users that were logged in, or had long term cookies (rememberme functionality) will be forced to re-login. Though their information will not have changed.

Settings and options have changed. You should grab screenshots of the settings pages before upgrade so that you can know how to adjust config entries and templates to the new methodologies.

__
This revision of FEU was done to allow for future development. I started this project as a way to clean up FEU so that I could add external authentication via twitter or facebook, and allow for two factor authentication. This required a cleaner, more stable API. And breaking a few eggs.

I also wanted to remove some complexity from the module interface, and make application development using FEU simpler for professional developers. To accomplish that I removed the settings and placed them into the CMSMS config file, and made changes so that for templates we preferred files rather than Design Manager.

I took advantage of what was already a major change to cleanup some past difficulties in FEU. This involved removing E-commerce functionality as it was implemented badly, and seldom used, preferring hooks over events, and other tasks.
--

* No longer install template types for DesignManager. It is still possible to use DesignManager to manage templates.
* All frontend templates now assume file templates by default. Unless parameters are specified with a smarty resource to indicate a different location or do not end with a .tpl extension.
* Clean up all frontend and most admin forms. The templates have changed.
* The emails for forgot password functionality and verification now use CGExtensions based 'eml' file.
* All frontend forms now support redirect-after-post. Determining which page to redirect to after each form is now done in the templates.
* Remove the setting panels completely. Now use config options as these options rarely change after initial setup, and were designed not to. Therefore the better location for these options was a config file.
* Refactor authentication to use authtokens and cookies, and NOT session data. On login users get an authtoken that has an expiry timestamp. Authtokens can be long term (+90 days) or short term (session cookies). Short term authtokens are regularly extended as the user accesses various pages, but are removed when the browser is closed.
* REMOVE all support for different auth consumers. This breaks the FEU_Auth_* modules which may or may not see replacements in the future.
* REMOVE all hooks and events for Ecommerce functionality.
* REMOVE all support for encrypted fields. The data for any existing encrypted fields is not explicitly decrypted. So admins and users can only see the encrypted strings. Developers can choose to store data encrypted if they wish before saving the property. Or can use external tables.
* REMOVE the inline parameter. This can still be specified on the {form_start} tag of most templates.
* REMOVE the returnto parameter.
* REMOVE cancel buttons from frontend forms. If you would like cancel functionality, include a link in your templates.
* REMOVE the viewuser action.
* REMOVE the reset_session action. As we do not use sessions anymore, just cookies.
* REMOVE the silent action: use {$feu_smarty->get_user()}
* Adds new number field type.
* Field definitions allow setting a field size and placeholder.
* Refactor the API functions to use Decorators and increased type hinting.
* Some seldom used API functions were removed.
* The prototypes of various API functions have changed. But ussually in a minor way. Type hinting is now used extensively.
* Refactor all caching
* Refactor the user class, create new userSet and Filter and FilterResultset classes.
* Remove the feu_user_query_resultset class. Now uses the userSet functionality.
* Refactor the user_edit_assistant class (replaced with a renamed class)
* Remove the verification_assistant classes... no longer necessary.
* Rewrite admin actions for efficiency.
* More hooks and and calling of hooks.
* more...
Follow me on twitter
Please post system information from "Extensions >> System Information" (there is a bbcode option) on all posts asking for assistance.
--------------------
If you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
Post Reply

Return to “Modules/Add-Ons”