[#11632] - Set correct return URL for secure login/logout
- Closed
- 11 Mar 2022
- Medium
- Build: staging
- # 11632
- Diff
- jo-sf:patch-25
- Success hound No violations found. Woof! Details
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
- Success continuous-integration/appveyor/pr AppVeyor build succeeded Details
- Pending JTracker/HumanTestResults Human Test Results: 1 Successful 1 Failed. Details
User tests: Successful: Unsuccessful:
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
- the hidden return URL in the login form is
- 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
- the hidden return URL in the login form is
- 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
- the hidden return URL in the login form is
- deactivate URL rewriting, adding suffixes to URLs and unicode aliases in the global configuration
joomla-cms-bot
- | Category | ⇒ | Front End Components Libraries Modules Unit Tests |
| Status | New | ⇒ | Pending |
| Labels |
Added:
?
?
|
||
@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.
Looking into
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/11632.
@jo-sf Is this issue still relevant?
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/11632.
| Status | Pending | ⇒ | Information Required |
| Status | Information Required | ⇒ | Needs Review |
changed Status on "Needs Review".
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/11632.
| Category | Front End Components Libraries Modules Unit Tests | ⇒ | Front End com_users Libraries Modules Unit Tests Components |
@SniperSister can the JSST review this please
@PhilETaylor can you check the isInternal changes, as you did some work on that in the past?
(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.
@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.
Fine from my side!
I have tested this item
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.
@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.
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
| Status | Needs Review | ⇒ | Information Required |
@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.
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.
I have tested this item
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.
See Glip Bugs & Fun @ Home channel for more information.
?
@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.
The user with username @gostn was banned from the project iirc.
gostn !== ghost - he was a real contributor, who fell foul of almost everyone. Looks like his whole Github account has been deleted now https://github.com/gostn he then renamed to gostn2
Yes I know that but in this case ghost = franz
What Im trying to work out is, if this PR wrongly assumes all traffic can only use 80/443 ports, or if, like in the real world, one could still run non-ssl traffic on port 8080 and SSL traffic on 8081...
Im not sure how much time to invest in it though, given that its been open since 2016, and its directed at staging...
Closing this one as there is a risk that it break things and the code should be simplified in the Uri class anyway. If the author has interest or somebody else please rebase to 4.2 branch or create a new pr.
Thanks for your help making Joomla better and looking forward to more contributions from you.
| Status | Information Required | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-03-11 17:09:59 |
| Closed_By | ⇒ | laoneo | |
| Labels |
Added:
?
?
Removed: ? |
||
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)?