PR-staging

Pending

User tests: Successful: Unsuccessful:

avatar jo-sf
jo-sf
16 Aug 2016

This PR is a followup to #11533, it handles the two issues mentioned in the testing instructions:

  • the page shown after a secure login is the user profile
  • the page shown after logging out is still served via HTTPS

Both issues are caused by ignoring the "usesecure" option when setting up the return URL for the login resp. logout form (see modules/mod_login/helper.php, method getReturnUrl()). An additional issue coming up when using the correct return URL is that the method JUri::isInternal() treats any URL as internal only if scheme, host and port are identical - when switching between HTTP and HTTPS (as is done when logging in or out with "usesecure" being set) this always causes a return URL with a differing scheme to be treated as external URL.

Moreover this PR implements parts of the changes I had in mind when I wrote PR #11304, which in turn was a revised version of PR #8619.

Testing Instructions

For testing this change you need a current Joomla installation with the sample data installed.

Preparations

  • log in to the administration
  • important: check that caching is disabled, if not disable it and clear the site cache
  • open "Extensions", "Modules"
  • search for all site modules containing the string "login" - you should find 3 such modules
  • open the "Login Form" module (this should be positioned at "position-7")
  • change "Encrypt Login Form" to "No" if necessary, change login and logout redirection pages to "Default" if necessary and save the settings
  • check the global configuration, especially the SEO settings: SEF URLs should be active, URL rewriting, adding suffixes to URLs and unicode aliases should not be active, change accordingly if necessary and save the settings

Status Quo

Login/logout without encrypting the login form and without login/logout redirection pages

  • open the site homepage via HTTP
  • go to any page, e.g. follow the link "Banner" below "All Modules"
  • locate the login form in the bottom right of the page
  • log in using any valid username and password
  • you should not be redirected to HTTPS, the page shown is the page where you logged in
  • locate the logout form in the bottom right of the page
  • log out, afterwards you're still at the page where you logged out and this page is served via HTTP
  • close the site homepage

Login/logout without encrypting the login form and with login/logout redirection pages

  • change the login and logout redirection pages for the "Login Form" module to two different menu items, e.g. "Users Component" for login and "Password Reset" for logout, and save the settings
  • open the site homepage via HTTP
  • go to any page, e.g. follow the link "Banner" below "All Modules"
  • locate the login form and log in using any valid username and password
  • you should not be redirected to HTTPS, the page shown is the login redirection page configured for the "Login Form" module, e.g. "Users Component"
  • locate the logout form and log out
  • afterwards you're still visiting the site via HTTP and the page shown is the logout redirection page configured for the "Login Form" module, e.g. "Password Reset"
  • close the site homepage
  • reset the login and logout redirection pages to "Default"

"Login Form" module with encrypting the login form and without login/logout redirection pages

  • change "Encrypt Login Form" for the "Login Form" module to "Yes" and save the settings
  • open the site homepage via HTTP
  • go to any page, e.g. follow the link "Banner" below "All Modules"
  • locate the login form in the bottom right of the page
  • check the contents of the hidden field "return" of this login form, after base64 decoding it should be something like http://<server>/index.php/banner-module (note the scheme "http")
  • log in using any valid username and password
  • you should be redirected to HTTPS, the page shown is the user profile page
  • go to the page where you performed the login
  • locate the logout form in the bottom right of the page
  • check the contents of the hidden field "return" of this logout form, after base64 decoding it should be something like https://<server>/index.php/banner-module (note the scheme "https")
  • log out, afterwards you still visit the site via HTTPS and you're still at the same page
  • close the site homepage

"Login Form" module with encrypting the login form and with login/logout redirection pages

  • change the login and logout redirection pages for the "Login Form" module to two different menu items, e.g. "Users Component" for login and "Password Reset" for logout, and save the settings
  • open the site homepage via HTTP
  • go to any page, e.g. follow the link "Banner" below "All Modules"
  • locate the login form and check the contents of the hidden field "return" of this login form, after base64 decoding it should be something like index.php?Itemid=271
  • log in using any valid username and password
  • you should be redirected to HTTPS, the page shown is the login redirection page configured for the "Login Form" module, e.g. "Users Component"
  • locate the logout form and check the contents of the hidden field "return" of this logout form, after base64 decoding it should be something like index.php?Itemid=409
  • log out, afterwards you still visit the site via HTTPS and the page shown is the logout redirection page configured for the "Login Form" module, e.g. "Password Reset"
  • close the site homepage
  • reset the login and logout redirection pages to "Default"

Completely activated SEO settings

  • change "Encrypt Login Form" for the "Login Form" module to "No" and save the settings
  • activate URL rewriting, adding suffixes to URLs and unicode aliases in the global configuration
  • repeat the above four status quo test scenarios
    • for Login/logout without encrypting the login form and without login/logout redirection pages no differences should be encountered
    • for Login/logout without encrypting the login form and with login/logout redirection pages no differences should be encountered
    • for "Login Form" module with encrypting the login form and without login/logout redirection pages the following differences should be encountered:
      • the hidden return URL in the login form is http://<server>/banner-module.html
      • the hidden return URL in the logout form is https://<server>/banner-module.html
    • for "Login Form" module with encrypting the login form and with login/logout redirection pages no differences should be encountered
  • deactivate URL rewriting, adding suffixes to URLs and unicode aliases in the global configuration

Changes

  • install this PR
  • change "Encrypt Login Form" for the "Login Form" module to "No" and save the settings

Login/logout without encrypting the login form and without login/logout redirection pages

  • repeat the test as described above, you shouldn't encounter any differences

Login/logout without encrypting the login form and with login/logout redirection pages

  • repeat the test as described above, you shouldn't encounter any differences

"Login Form" module with encrypting the login form and without login/logout redirection pages

  • change "Encrypt Login Form" for the "Login Form" module to "Yes" and save the settings
  • open the site homepage via HTTP
  • go to any page, e.g. follow the link "Banner" below "All Modules"
  • locate the login form in the bottom right of the page
  • check the contents of the hidden field "return" of this login form, after base64 decoding it should be something like https://<server>/index.php/banner-module (note the scheme "https")
  • log in using any valid username and password
  • you should be redirected to HTTPS, the page shown is the same page as before you logged in
  • locate the logout form in the bottom right of the page
  • check the contents of the hidden field "return" of this logout form, after base64 decoding it should be something like http://<server>/index.php/banner-module (note the scheme "http")
  • log out, afterwards you visit the site via HTTP and you're still at the same page
  • close the site homepage

"Login Form" module with encrypting the login form and with login/logout redirection pages

  • change the login and logout redirection pages for the "Login Form" module to two different menu items, e.g. "Users Component" for login and "Password Reset" for logout, and save the settings
  • open the site homepage via HTTP
  • go to any page, e.g. follow the link "Banner" below "All Modules"
  • locate the login form and check the contents of the hidden field "return" of this login form, after base64 decoding it should be something like https://<server>/index.php/users-component
  • log in using any valid username and password
  • you should be redirected to HTTPS, the page shown is the login redirection page configured for the "Login Form" module, e.g. "Users Component"
  • locate the logout form and check the contents of the hidden field "return" of this logout form, after base64 decoding it should be something like http://<server>/index.php/password-reset
  • log out, afterwards you visit the site via HTTP and the page shown is the logout redirection page configured for the "Login Form" module, e.g. "Password Reset"
  • close the site homepage
  • reset the login and logout redirection pages to "Default"

Completely activated SEO settings

  • change "Encrypt Login Form" for the "Login Form" module to "No" and save the settings
  • activate URL rewriting, adding suffixes to URLs and unicode aliases in the global configuration
  • repeat the above four test scenarios for this PR
    • for Login/logout without encrypting the login form and without login/logout redirection pages no differences should be encountered
    • for Login/logout without encrypting the login form and with login/logout redirection pages no differences should be encountered
    • for "Login Form" module with encrypting the login form and without login/logout redirection pages the following differences should be encountered:
      • the hidden return URL in the login form is https://<server>/banner-module.html
      • the hidden return URL in the logout form is http://<server>/banner-module.html
    • for "Login Form" module with encrypting the login form and with login/logout redirection pages the following differences should be encountered:
      • the hidden return URL in the login form is https://<server>/users-component.html
      • the hidden return URL in the logout form is http://<server>/password-reset.html
  • deactivate URL rewriting, adding suffixes to URLs and unicode aliases in the global configuration
avatar joomla-cms-bot joomla-cms-bot - change - 16 Aug 2016
Category Front End Components Libraries Modules Unit Tests
avatar jo-sf jo-sf - open - 16 Aug 2016
avatar jo-sf jo-sf - change - 16 Aug 2016
Status New Pending
avatar joomla-cms-bot joomla-cms-bot - change - 16 Aug 2016
Labels Added: PR-staging ?
avatar jo-sf jo-sf - change - 16 Aug 2016
The description was changed
avatar jo-sf jo-sf - change - 17 Aug 2016
The description was changed
avatar yvesh
yvesh - comment - 17 Aug 2016

One general question: What is planned when the port is set to non default, e.g. when people for example use 8080 or 8443 or whatever (which is valid and many people do - i know your PR does not cover this)?

avatar jo-sf
jo-sf - comment - 17 Aug 2016

@yvesh You're right that using the feature "Encrypt Login Form" as well as "Force HTTPS" will currently only work if the standard ports 80 (HTTP) and 443 (HTTPS) are used. Switching "Force HTTPS" from "None" to anything else no longer works with non-standard ports since version 3.6 because a check was added (not by me) that tests whether it is possible to access the Joomla instance via HTTPS and port 443. Currently there is no such check when enabling "Encrypt Login Form" and I think it is not necessary as long as you can access the administration interface for disabling it if it doesn't work (and it won't work if you use non-standard ports).

About my plans regarding non-standard ports: I plan to add two new fields to the global configuration that allow to set the HTTP and the HTTPS ports, these settings will be checked as is the case today for the "Force HTTPS" setting. Together with these two new fields I will check and change all places where switching between HTTP and HTTPS is done today (and in the near future).

As you've maybe seen I already had a PR (#11304) but this was way too complex for being tested throughly, and so we (@conconnl, @andrepereiradasilva, @brianteeman and I) decided to close that PR, and afterwards I started with smaller PRs covering one topic of the large PR after the other, and I hope I'll come finally to the point where all topics of that large PR are covered by smaller PRs that can be tested without much effort.

There is also a B/C issue to be considered. I'd like to remove the "Encrypt Login Form" from the mod_login module and to add a new setting "Encrypt Login / Registration Forms" to the com_users component, the reason for that is that at least one login form cannot be set to use HTTPS for sending the login information to the server (I mean the login form within com_users that is used whenever you entered wrong login information), moreover all registration information including the initial password is currently sent by default via HTTP to the server.

As @andrepereiradasilva rightly stated this cannot be done with Joomla 3.x, the existing settings must be retained and the new setting may be used in addition (something like "first check the mod_login setting, and if it is not set check the com_users setting").

Another point to consider is that I'd like to allow "Encrypt Login / Registration Forms" only if "Force HTTPS" is set to "Administrator Only". I think if HTTPS is available the administration interface shall (and will) use it, moreover HTTPS has been tested for availability when it was switched on. And if "Force HTTPS" is set to "Entire Site" it is no longer necessary to explicitly encrypt login / registration forms since the entire traffic between the browser and the server is encrypted using HTTPS. But even that is a B/C issue and can only be implemented for Joomla version 4 I think.


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11632.

avatar jo-sf jo-sf - change - 6 Nov 2016
The description was changed
avatar jo-sf jo-sf - edited - 6 Nov 2016
avatar anjahage
anjahage - comment - 3 Jun 2017

Looking into


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/11632.

avatar anjahage
anjahage - comment - 3 Jun 2017

@jo-sf Is this issue still relevant?

@nibra


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/11632.

avatar franz-wohlkoenig franz-wohlkoenig - change - 3 Jun 2017
Status Pending Information Required
avatar jo-sf
jo-sf - comment - 3 Jun 2017

@anjahage yes this issue is still relevant - and it is a prerequisite for another PR I've in mind (that other PR shall cover the topic of non-standard ports, see comment by @yvesh and my answer).

avatar franz-wohlkoenig franz-wohlkoenig - change - 22 Jun 2017
Status Information Required Needs Review
avatar franz-wohlkoenig
franz-wohlkoenig - comment - 22 Jun 2017

changed Status on "Needs Review".


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/11632.

avatar Kev1n337
Kev1n337 - comment - 21 Aug 2017

@jo-sf Please update your pull request. It has merge conflicts, so I can not test it at the moment.
@icampus

avatar joomla-cms-bot joomla-cms-bot - change - 23 Aug 2017
Category Front End Components Libraries Modules Unit Tests Front End com_users Libraries Modules Unit Tests Components
avatar jo-sf
jo-sf - comment - 23 Aug 2017

@Kev1n337 I just updated my pull request, so it currently should no longer have merge conflicts. Travis tests have been completed successfully, at least all mandatory tests.

avatar brianteeman
brianteeman - comment - 4 Jan 2018

@SniperSister can the JSST review this please

avatar SniperSister
SniperSister - comment - 4 Jan 2018

@PhilETaylor can you check the isInternal changes, as you did some work on that in the past?

avatar PhilETaylor
PhilETaylor - comment - 4 Jan 2018

(not reviewed, just commenting)

IIRC there was a test suite developed for isInternal when I last worked on it - and none of those existing tests have been changed, only added more tests, so one hopes that this still fulfils the use cases. The last test suite was not developed to test any security issue, it was for redirection issues - so I cannot (yet) comment on the 'secure' ness ofthe changes.

avatar roland-d
roland-d - comment - 22 Jul 2018

@SniperSister Does anything need to be done by JSST or is this ready to be tested?


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/11632.

avatar SniperSister
SniperSister - comment - 22 Jul 2018

Fine from my side!

avatar Schmidie64 Schmidie64 - test_item - 23 Jul 2018 - Tested unsuccessfully
avatar Schmidie64
Schmidie64 - comment - 23 Jul 2018

I have tested this item 🔴 unsuccessfully on 6d97817

I followed the test-instructions step by step. After I applied the patch and change the redirection Page, I've got the error message: "Object not found!"
see screenshot. http://www.picfront.org/d/9Odh


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/11632.

@icampus

avatar jo-sf
jo-sf - comment - 15 Aug 2018

@Schmidie64 Sorry for the delay in answering you and checking the problem you encountered.

First thing I mentioned is that the URL visible in your screen shot doesn't fit the test instruction steps where you got the error.

Something like http://localhost/joomla3/users-component.html is valid only when the SEO settings are completely activated which shouldn't be the case in the test instruction steps where you got the error. At that moment the URL should look like http://localhost/joomla3/index.php/users-component.

Can you please check that the SEO settings are deactivated as described, that caching is disabled and that you closed the site homepage every time you completed each group of test instruction steps. The latter is especially importent with respect to changes to the login form: if you change the settings for the login form in the backend when having the site homepage open at that time and then locate the login form at the currently open frontend page and log in using that login form previous settings for the login form will be applied (e.g. the previous login redirection page). If you don't want to close the site homepage between the groups of test instruction steps you should at least reload the current frontend page before using the login form located at that page.

With this mind can you please repeat your tests and inform me whether you still got problems or whether everything worked fine as described and expected. Thanks!


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/11632.

avatar rdeutz
rdeutz - comment - 18 Aug 2018

for the test can you make a PR against this Repo https://github.com/joomla/test-integration JUri Test is in the 4.0-dev branch /legacy and remove the file from your PR here, thanks

avatar franz-wohlkoenig franz-wohlkoenig - change - 18 Aug 2018
Status Needs Review Information Required
avatar franz-wohlkoenig
franz-wohlkoenig - comment - 19 Jul 2019

guessing comment above from @rdeutz is for @jo-sf: Was this be done?

avatar jwaisner
jwaisner - comment - 11 Mar 2020

@jo-sf Are you able to make the changes advised by @rdeutz ?


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/11632.

avatar wilsonge
wilsonge - comment - 4 Apr 2020

Robert's changes aren't required - this PR is to staging not 4.x (and that repo has now been retired and stuff moved back to 4.x). Just get this tested as is.

avatar particthistle
particthistle - comment - 14 Jan 2021

I have tested this item successfully on 6d97817

Based on @wilsonge last remark back in April 2020, @Quy or another maintainer could have removed the Updates Requested label, which may have been why this has continued sitting in place since August 2016 and not seen final testing.

After going through the loop of 16 tests in total (scenarios with and without patch, with and without SEO), on a hosted Joomla 3.9.24 site (vs localhost) the PR has tested successfully.

It's fixing one of those quirky issues that's been curious for a while... I couldn't work out why it sent users to the User Profile even when it wasn't specified as the URL to go to... now I know why.

Testing this as part of a "Outstanding PR Status List" exercise to work on reducing the number of outstanding PR that have been otherwise orphaned, neglected or forgotten instead of being merged. See Glip Bugs & Fun @ Home channel for more information.


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/11632.

avatar particthistle particthistle - test_item - 14 Jan 2021 - Tested successfully
avatar gostn
gostn - comment - 14 Jan 2021

See Glip Bugs & Fun @ Home channel for more information.

?

avatar particthistle
particthistle - comment - 17 Apr 2021

@gostn apologies to not reply back in January to your ?

I'd message you but you're an enigma on here choosing to be anonymous. Find out more: https://docs.joomla.org/Bugs_%26_Fun_@Home


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/11632.

Add a Comment

Login with GitHub to post a comment