[#11304] - Improvements for secure registration and login
- Closed
- 3 Aug 2016
- Medium
- Build: staging
- # 11304
- Diff
- jo-sf:patch-20
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
User tests: Successful: Unsuccessful:
This is a revised version of PR #8619 based upon the current Joomla staging version.
Assume the following setup:
- the Joomla server is reachable via HTTP and HTTPS
- the Joomla administration is accessed via HTTPS ("Force HTTPS" is set to "Administrator Only")
- the Joomla site shall be accessed by default via HTTP
- optionally the ports used for HTTP and HTTPS are non-standard and shall be configurable
This PR aims at the following:
- there should be a single place for activating secure login and registration
- user registration data shall be transferred via HTTPS to the server if activated
- user login at the frontend shall always use HTTPS if activated
- all pages shown when logged in at the frontend shall always be transferred via HTTPS if activated
- user logout at the frontend shall always return to HTTP if secure login is activated
- site preview from the administration shall always open the site home page in HTTP mode
- switching between HTTP and HTTPS shall work even when non-standard ports are used
- if "Force HTTPS" is set to None no switching between HTTP and HTTPS shall be done
Currently secure login can be activated in each mod_login instance separately (and there are at least three of them in the demo site delivered with Joomla), and there is no way to enable secure login when using the login form menu item coming from com_users. Moreover it is not possible to activate secure transfer for user registration data which include sensitive data like password and mail address. Also the reminding and resetting functions shall be able to use HTTPS for transferring e.g. the mail address (currently HTTP is used for that).
In order to achieve this I moved the "usesecure" setting from the mod_login instance settings to the com_users configuration, and I changed all affected files (including message files) accordingly. In order to make foreign templates that override the mod_login login form work as before (assuming they check for the "usesecure" setting when logging in) I copy the "usesecure" setting from the com_users configuration dynamically to the mod_login instance settings prior to activating the login form of the template.
For proper links from the backend running in HTTPS mode to the site (site preview) I modified the administrator templates hathor and isis accordingly, moreover I had to change the administrator module mod_status for that purpose.
In order to handle internal URL checking even in the case of switching between HTTP and HTTPS I had to change the JUri::isInternal() method.
I order to make switching between HTTP and HTTPS protocols easier (same lines of code needed at many places) I implemented two new methods JUri::siteScheme() and JUri::adminScheme() which do this switching.
If you enable "Force HTTPS" by setting it to either "Administrator Only" or "Entire Site" (Global Configuration, Server Settings) you'll now get two additional fields for the HTTP and the HTTPS ports where you can enter the ports used at your site. This is necessary only when using non-standard ports like 8080 for HTTP and 8443 for HTTPS.
If you change these ports they are checked as well as the "Force HTTPS" mode itself, and in case of an error doing so the change is undone.
At all code locations where switching between HTTP and HTTPS is performed these ports if set are used accordingly.
Note that switching between HTTP and HTTPS protocols is done only if "Force HTTPS" is set to anything else than "None". This should help in cases like in PR #11213.
The login and logout forms in mod_login used the current URL as their target for the forms which is of no great use since the real target of these forms is passed in the hidden field "return" I changed that back to "index.php" as it was about two years ago.
I saw that the beez3 template contains an override for the mod_login login form but no separate override for the logout form. Instead the login form still contained the login and logout cases as was the case in mod_login until more than three years ago (August 2012).
Finally I added the new field attribute "renderon" (see PR #11207) both to the "usesecure" field in com_users and to the "secure" field in com_menus, these fields are shown only if the global flag "force_ssl" is set to 1 ("Administrator Only") and if PR #11207 has been applied. My reason for this is that if "force_ssl" is 0 probably no HTTPS is available such that switching to HTTPS would most likely fail, and if "force_ssl" is 2 ("Entire Site") all pages are already shown via HTTPS such that no switching is necessary.
Testing Instructions
- set up current Joomla version including demo site and apply all changes from this PR
- optionally apply the changes from PR #11207
- the webserver must be reachable via HTTP and HTTPS
- log in to the backend as administrator
- set "Force HTTPS" in Global Configuration, Server Settings to "Administrator Only"
- the backend should now be accessed via HTTPS only
- all site preview links should point to HTTP (hathor or isis template assumed)
- frontend login (regardless which) continue in HTTP mode
- go to the Users Configuration and enable "Encrypt Login / Registration Forms"
- check registration form: the action URL should point to HTTPS
- after successful registration the user will be back in HTTP mode
- check frontend login form (regardless which): the action URL should point to HTTPS
- after successful login all pages should be displayed via HTTPS
- in case of a login failure the user should be back in HTTP mode
- check frontend logout form: the action URL should point to HTTPS
- perform logout: the user should be back in HTTP mode
- check remind and reset links: the action URL for both of them should point to HTTPS
- after performing remind / reset functions the user should be back in HTTP mode
- set any menu item to "Secure" mode (tab "Metadata")
- check in the frontend that this menu item now points to HTTPS
- configure additional server ports usable for HTTP and HTTPS, e.g. to 8080 and 8443
- configure these ports in Global Configuration, Server Settings (below "Force HTTPS")
- check that switching between HTTP and HTTPS works as expected
- check that the action URLs mentioned above contain the right HTTPS port
- set "Force HTTPS" in Global Configuration, Server Settings to "Entire Site"
- all pages should now be served via HTTPS, no switching when logging in or out
- if PR #11207 was applied too:
- the field "Encrypt Login / Registration Forms" in the Users Configuration is no longer rendered
- the field "Secure" in menu items (tab "Metadata") is no longer rendered
Note: In testing this PR you might encounter that your browser uses the HTTPS protocol even if you changed "Force HTTPS" back from "Entire Site" to "Administrator Only" or "None" or back from "Administrator Only" to "None". This is not a problem with these changes but is caused by the browser caching redirections it received prior to changing the "Force HTTPS" setting. In such cases please close all windows or tabs showing content from the Joomla instance used for testing, clear the browser's cache and then try again.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration Components Language & Strings Modules Templates (admin) Front End Libraries |
| Labels |
Added:
?
?
|
||
@conconnl
You're absolutely right. I optimized too much in JRoute::_() which caused the host name to be missing in the resulting URL - it should now work as expected.
Please note that switching to HTTPS when sending the registration form to the server and when logging in is done only when "Force HTTPS" is set to "Administrator Only"; if it is set to "None" no switching is done, and if it is set to "Entire Site" no switching is necessary since the registration form has already been loaded via HTTPS.
Unfortunately this PR is no longer automatically mergeable with the staging code and it seems to cause some conflicts when testing it by means of PatchTester (at least some changes done in administrator/components/com_config/model/application.php coming from PR #11189 are lost after applying this PR to the staging code).
Can I and if yes how can I cure this?
You will need to update your own branch to the latest staging and if necessary resolve any merge conflicts there.
@brianteeman
Sorry for being ignorant, but how can I update my own branch (I think you mean the "patch-XX" branch from where I created this PR) to the latest staging (here I assume you mean the latest "joomla/joomla-cms" staging)? I searched for any way to do this in the github web interface, but I didn't find any way to do so. Is this at all possible via the web interface?
Yeah you guessed what I meant correctly and no its not possible
autoamtically via the web interface as far as I know.
I am going out for a few hours but will take a deeper look at this for you
when I get back (unless someone else helps in the meantime)
On 29 July 2016 at 07:57, jo-sf notifications@github.com wrote:
@brianteeman https://github.com/brianteeman
Sorry for being ignorant, but how can I update my own branch (I think you
mean the "patch-XX" branch from where I created this PR) to the latest
staging (here I assume you mean the latest "joomla/joomla-cms" staging)? I
searched for any way to do this in the github web interface, but I didn't
find any way to do so. Is this at all possible via the web interface?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11304 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8aP5mXsLeL_xAx8onfmFlrcKsbiSks5qaaQ_gaJpZM4JUeEY
.
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/
@conconnl
Prior to continuing with this PR (branch update, bug fixing, improvements) I think we have to make some decisions. @andrepereiradasilva made a point asking for B/C - this is something I had only partly in mind when creating this PR.
Let's first look at all places where you can switch to secure mode in Joomla today (those are at least all places I found so far):
- you can set "Force HTTPS" in the global configuration to "Administrator Only" or "Entire Site"
- since Joomla 3.6.0 this is checked whether you can access your server via HTTPS, and if this is not the case "Force HTTPS" is reset to None
- you can set "Encrypt Login Form" for each site instance of the
mod_loginmodule individually to "Yes" - you can set "Encrypt Login Form" for the administrator instance of the
mod_loginmodule to "Yes"- note that with this setting you can effectively lock you out of your Joomla administration access, and the only way to undo this is by making a change in the database
- you can set "Secure" in the "Metadata" tab of most menu items to "On" or "Off"
My first intention when implementing this PR was to eliminate the "Encrypt Login Form" settings in the mod_login modules both for the site and the administrator and to replace the site setting by means of a new "Encrypt Login / Registration Forms" setting in com_users. The "Secure" setting in the menu items should only be available when "Force HTTPS" is set to "Administrator Only".
But now triggered by some of @andrepereiradasilva's remarks I think we have to split this into two parts, one that is B/C and continues to contain and honor all existing settings and one that will come with the next major Joomla release (Joomla 4) and that will remove some of the then obsolete or problematic settings.
The Joomla 3.6/3.7 implementation of this PR should IMO contain the following changes:
- the new "Encrypt Login / Registration Forms" setting in
com_userssuperseding the still existing "Encrypt Login Form" settings in the site instances of themod_loginmodule- if this new setting is "Yes" site login and registration forms will be encrypted (this means that the contents of these forms will be sent via HTTPS to the server)
- if this new setting is "No" login forms will be encrypted if the settings for these forms (
mod_loginmodules) say so - this new "Encrypt Login / Registration Forms" setting will be shown only when "Force HTTPS" is set to "Administrator Only"
- if "Force HTTPS" is set to "None" the existence of HTTPS is not guaranteed and tested
- if "Force HTTPS" is set to "Entire Site" all pages are shown via HTTPS
- the "Encrypt Login Form" settings in site and administrator
mod_loginmodules continue to exist- the setting in site
mod_loginmodules will be shown only when "Force HTTPS" is not "Entire Site" - the setting in the administrator
mod_loginmodule will be shown only when "Force HTTPS" is "None"
- the setting in site
- the "Secure" setting in the menu items continue to exist, it will be shown only when "Force HTTPS" is not "Entire Site"
The implementation for the next major release should contain the following changes with respect to the changes listes above for Joomla 3.6/3.7:
- the "Encrypt Login Form" settings in site and administrator
mod_loginmodules will be removed- for the site
mod_loginmodules the "Encrypt Login / Registration Forms" setting fromcom_userswill be dynamically copied to the module's settings such that templates overriding the form's HTML code continue to work as expected - the administrator
mod_loginmodule no longer needs to switch to HTTPS, instead you have to set "Force HTTPS" to "Administrator Only" (or "Entire Site")
- for the site
- the "Secure" setting in the menu items will be shown only when "Force HTTPS" is "Administrator Only"
What do you (and others) think about that?
@jo-sf
It's very important to not have a B/C break when making PRs for current major versions.
So splitting the PR is the way to go, as you describe yourself first adding features to the current branch and afterwards creating a PR for the next major (4.x or other number) to remove deprecated settings.
I think this does not mean you can hide the setting in mod_login when you have the Secure Form setting enabled in the User Configuration.
This only means you cannot remove the setting to keep the sites who upgrade working and make people can still find the setting to secure the form when choosing to only secure the administrator.
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11304.
@jo-sf i would also remove the link replacing in the templates files from this PR (the ones with $siteUri = JUri::siteScheme(JUri::root());)
because i think this is not the best way to do it. I proposed a patch to add the flexibility to JRoute (#11060) so we could do that whenever needed.
Also huge PRs normally take a loooong time to be merged... so IMHO it's better to make smaller PR
@jo-sf
The "perform logout: the user should be back in HTTP mode" step does not go back to HTTP, the site stays in HTTPS
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11304.
Added:
When I open the site without the patch on HTTPS after logon and I logout, I too keep the HTTPS connection. So with or without the patch I don't get redirected back to HTTP.
So it could be a General problem in Joomla
@conconnl @andrepereiradasilva
Based mainly upon your comments I think I need to redesign this PR - it's too large to be tested and reviewed thoroughly, it's very "colored" (9 tags attached in issues.joomla.org) and it's not B/C.
Unfortunately this means that you'll have to wait some more time until the resulting PRs can be tested and reviewed. I'm not yet sure how many this will be, but I expect three or so - and at least another one for the next major release that contains all the non B/C stuff.
Shall we close this here for now then?
@brianteeman if this is not a problem then please let this PR open until I managed to create the new PRs. This way I can use this PR and all the comments from you all as my source of inspiration...
It will still be accessible to you as a closed issue. But by closing it we
prevent people wasting their time commening or testing it
On 2 August 2016 at 20:06, jo-sf notifications@github.com wrote:
@brianteeman https://github.com/brianteeman if this is not a problem
then please let this PR open until I managed to create the new PRs. This
way I can use this PR and all the comments from you all as my source of
inspiration...—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11304 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8d7qBPOkVvyUqofhlDWaUTsMsEZ_ks5qb5U7gaJpZM4JUeEY
.
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/
@brianteeman
Yes it would really be wasting of time if someone would continue to test this PR since it will never be merged into the base branch. Moreover my PR is no longer working as I expected it to do (see e.g. the comment from @conconnl some days ago), and I see no good reason to inspect this further.
But commenting is (I think) another point. Maybe someone seeing this PR would like to comment on it although I plan to redesign it, moreover I thought of adding links to the redesigned PRs to this PR as soon as they are ready to be tested.
What is your standard procedure in such cases?
Usually we would close this. If/when you add links to the new PR to this
issue everyone subscribed to this issue would be notified of the new links
On 3 August 2016 at 08:14, jo-sf notifications@github.com wrote:
@brianteeman https://github.com/brianteeman
Yes it would really be wasting of time if someone would continue to test
this PR since it will never be merged into the base branch. Moreover my PR
is no longer working as I expected it to do (see e.g. the comment from
@conconnl https://github.com/conconnl some days ago), and I see no good
reason to inspect this further.But commenting is (I think) another point. Maybe someone seeing this PR
would like to comment on it although I plan to redesign it, moreover I
thought of adding links to the redesigned PRs to this PR as soon as they
are ready to be tested.What is your standard procedure in such cases?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11304 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8e-El5AYd177RDPwf67uYMrsg8c_ks5qcD_ugaJpZM4JUeEY
.
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/
@brianteeman
I wasn't sure whether I can add additional comments to a closed issue, but if that works and everybody subscribed to this issue will receive a notification you might safely close this issue now.
BTW may I also add a link to a closed issue to a new issue?
Closed. You can still comment if needed
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-08-03 17:27:45 |
| Closed_By | ⇒ | brianteeman |
@jo-sf
There is an error in the patch.
The patch changes the things needed but the registration button stops working.
Because he tries to do a post to: https:///index.php...............
Have not tested the rest, but this will probably happen too on the login button.