{"action":"created","issue":{"url":"https://api.github.com/repos/joomla/joomla-cms/issues/11304","repository_url":"https://api.github.com/repos/joomla/joomla-cms","labels_url":"https://api.github.com/repos/joomla/joomla-cms/issues/11304/labels{/name}","comments_url":"https://api.github.com/repos/joomla/joomla-cms/issues/11304/comments","events_url":"https://api.github.com/repos/joomla/joomla-cms/issues/11304/events","html_url":"https://github.com/joomla/joomla-cms/pull/11304","id":167447687,"number":11304,"title":"Improvements for secure registration and login","user":{"login":"jo-sf","id":8342125,"avatar_url":"https://avatars.githubusercontent.com/u/8342125?v=3","gravatar_id":"","url":"https://api.github.com/users/jo-sf","html_url":"https://github.com/jo-sf","followers_url":"https://api.github.com/users/jo-sf/followers","following_url":"https://api.github.com/users/jo-sf/following{/other_user}","gists_url":"https://api.github.com/users/jo-sf/gists{/gist_id}","starred_url":"https://api.github.com/users/jo-sf/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jo-sf/subscriptions","organizations_url":"https://api.github.com/users/jo-sf/orgs","repos_url":"https://api.github.com/users/jo-sf/repos","events_url":"https://api.github.com/users/jo-sf/events{/privacy}","received_events_url":"https://api.github.com/users/jo-sf/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/joomla/joomla-cms/labels/Language%20Change","name":"Language Change","color":"eb6420"},{"url":"https://api.github.com/repos/joomla/joomla-cms/labels/PR-staging","name":"PR-staging","color":"c7def8"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2016-07-25T19:37:27Z","updated_at":"2016-07-29T07:02:22Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/joomla/joomla-cms/pulls/11304","html_url":"https://github.com/joomla/joomla-cms/pull/11304","diff_url":"https://github.com/joomla/joomla-cms/pull/11304.diff","patch_url":"https://github.com/joomla/joomla-cms/pull/11304.patch"},"body":"This is a revised version of PR #8619 based upon the current Joomla staging version.\r\n\r\nAssume the following setup:\r\n\r\n* the Joomla server is reachable via HTTP and HTTPS\r\n* the Joomla administration is accessed via HTTPS (\"Force HTTPS\" is set to \"Administrator Only\")\r\n* the Joomla site shall be accessed by default via HTTP\r\n* optionally the ports used for HTTP and HTTPS are non-standard and shall be configurable\r\n\r\nThis PR aims at the following:\r\n\r\n* there should be a single place for activating secure login and registration\r\n* user registration data shall be transferred via HTTPS to the server if activated\r\n* user login at the frontend shall always use HTTPS if activated\r\n* all pages shown when logged in at the frontend shall always be transferred via HTTPS if activated\r\n* user logout at the frontend shall always return to HTTP if secure login is activated\r\n* site preview from the administration shall always open the site home page in HTTP mode\r\n* switching between HTTP and HTTPS shall work even when non-standard ports are used\r\n* if \"Force HTTPS\" is set to None no switching between HTTP and HTTPS shall be done\r\n\r\nCurrently 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).\r\n\r\nIn 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.\r\n\r\nFor 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.\r\n\r\nIn order to handle internal URL checking even in the case of switching between HTTP and HTTPS I had to change the `JUri::isInternal()` method.\r\n\r\nI 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.\r\n\r\nIf 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.\r\n\r\nIf 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.\r\n\r\nAt all code locations where switching between HTTP and HTTPS is performed these ports if set are used accordingly.\r\n\r\nNote 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.\r\n\r\nThe 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.\r\n\r\nI 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).\r\n\r\nFinally 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.\r\n\r\n#### Testing Instructions\r\n\r\n*  set up current Joomla version including demo site and apply all changes from this PR\r\n* optionally apply the changes from PR #11207 \r\n* the webserver must be reachable via HTTP and HTTPS\r\n* log in to the backend as administrator\r\n* set \"Force HTTPS\" in Global Configuration, Server Settings to \"Administrator Only\"\r\n* the backend should now be accessed via HTTPS only\r\n* all site preview links should point to HTTP (hathor or isis template assumed)\r\n* frontend login (regardless which) continue in HTTP mode\r\n* go to the Users Configuration and enable \"Encrypt Login / Registration Forms\"\r\n* check registration form: the action URL should point to HTTPS\r\n* after successful registration the user will be back in HTTP mode\r\n* check frontend login form (regardless which): the action URL should point to HTTPS\r\n* after successful login all pages should be displayed via HTTPS\r\n* in case of a login failure the user should be back in HTTP mode\r\n* check frontend logout form: the action URL should point to HTTPS\r\n* perform logout: the user should be back in HTTP mode\r\n* check remind and reset links: the action URL for both of them should point to HTTPS\r\n* after performing remind / reset functions the user should be back in HTTP mode\r\n* set any menu item to \"Secure\" mode (tab \"Metadata\")\r\n* check in the frontend that this menu item now points to HTTPS\r\n* configure additional server ports usable for HTTP and HTTPS, e.g. to 8080 and 8443\r\n* configure these ports in Global Configuration, Server Settings (below \"Force HTTPS\")\r\n* check that switching between HTTP and HTTPS works as expected\r\n* check that the action URLs mentioned above contain the right HTTPS port\r\n* set \"Force HTTPS\" in Global Configuration, Server Settings to \"Entire Site\"\r\n* all pages should now be served via HTTPS, no switching when logging in or out\r\n* if PR #11207 was applied too:\r\n * the field \"Encrypt Login / Registration Forms\" in the Users Configuration is no longer rendered\r\n * the field \"Secure\" in menu items (tab \"Metadata\") is no longer rendered\r\n\r\nNote: 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."},"comment":{"url":"https://api.github.com/repos/joomla/joomla-cms/issues/comments/236109481","html_url":"https://github.com/joomla/joomla-cms/pull/11304#issuecomment-236109481","issue_url":"https://api.github.com/repos/joomla/joomla-cms/issues/11304","id":236109481,"user":{"login":"brianteeman","id":1296369,"avatar_url":"https://avatars.githubusercontent.com/u/1296369?v=3","gravatar_id":"","url":"https://api.github.com/users/brianteeman","html_url":"https://github.com/brianteeman","followers_url":"https://api.github.com/users/brianteeman/followers","following_url":"https://api.github.com/users/brianteeman/following{/other_user}","gists_url":"https://api.github.com/users/brianteeman/gists{/gist_id}","starred_url":"https://api.github.com/users/brianteeman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/brianteeman/subscriptions","organizations_url":"https://api.github.com/users/brianteeman/orgs","repos_url":"https://api.github.com/users/brianteeman/repos","events_url":"https://api.github.com/users/brianteeman/events{/privacy}","received_events_url":"https://api.github.com/users/brianteeman/received_events","type":"User","site_admin":false},"created_at":"2016-07-29T07:02:21Z","updated_at":"2016-07-29T07:02:21Z","body":"Yeah you guessed what I meant correctly and no its not possible\nautoamtically via the web interface as far as I know.\n\nI am going out for a few hours but will take a deeper look at this for you\nwhen I get back (unless someone else helps in the meantime)\n\nOn 29 July 2016 at 07:57, jo-sf <notifications@github.com> wrote:\n\n> @brianteeman <https://github.com/brianteeman>\n> Sorry for being ignorant, but how can I update my own branch (I think you\n> mean the \"patch-XX\" branch from where I created this PR) to the latest\n> staging (here I assume you mean the latest \"joomla/joomla-cms\" staging)? I\n> searched for any way to do this in the github web interface, but I didn't\n> find any way to do so. Is this at all possible via the web interface?\n>\n> —\n> You are receiving this because you were mentioned.\n> Reply to this email directly, view it on GitHub\n> <https://github.com/joomla/joomla-cms/pull/11304#issuecomment-236108707>,\n> or mute the thread\n> <https://github.com/notifications/unsubscribe-auth/ABPH8aP5mXsLeL_xAx8onfmFlrcKsbiSks5qaaQ_gaJpZM4JUeEY>\n> .\n>\n\n\n\n-- \nBrian Teeman\nCo-founder Joomla! and OpenSourceMatters Inc.\nhttp://brian.teeman.net/\n"}}
{"actor":{"display_login":"brianteeman"}}