This project is mirrored from https://git.typo3.org/typo3/typo3.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 10 Mar, 2021 2 commits
  2. 09 Mar, 2021 2 commits
  3. 08 Mar, 2021 1 commit
  4. 01 Mar, 2021 1 commit
  5. 24 Feb, 2021 1 commit
  6. 22 Feb, 2021 1 commit
  7. 19 Feb, 2021 1 commit
    • Oliver Bartsch's avatar
      [FEATURE] Introduce MFA in Core · 39145a46
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed
      A new API is introduced, providing multi-factor
      authentication for the Core. The API is furthermore
      directly used to add two MFA providers by default:
      
      * TOTP (time-based one-time passwords)
      * Recovery codes
      
      Even if the API is designed to allow MFA in both,
      backend and frontend, it is currently only implemented
      into the backend. Users can therefore configure their
      available MFA providers in a new backend module,
      accessible via their user settings.
      
      There are also some configuration options for
      administrators to e.g. define a recommended provider
      or to disallow available providers for specific users
      or user groups.
      
      Administration of the users' MFA providers is possible
      for administrators in the corresponding user records.
      
      New providers can be introduced by implementing the
      MfaProviderInterface and tagging the service with the
      `mfa.provider` tag.
      
      Note that the API is currently marked as internal since
      changes in upcoming patches are to be expected.
      
      Following dependencies are introduced:
      
      * bacon/bacon-qr-code "^2.0"
      * christian-riesen/base32 "^1.5"
      
      Possible features that could follow later-on:
      
      * MFA frontend integration
      * Webauthn core provider for FIDO2 and U2F.
      * Forcing users to set up MFA on login
      * Password-recovery with active MFA
      
      Resolves: #93526
      Releases: master
      Change-Id: I4e902be624c80295c9c0c3286c90a6a680feeb5d
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67548
      
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      39145a46
  8. 17 Feb, 2021 1 commit
  9. 15 Feb, 2021 2 commits
  10. 12 Feb, 2021 1 commit
  11. 10 Feb, 2021 2 commits
  12. 09 Feb, 2021 2 commits
  13. 08 Feb, 2021 3 commits
    • Benjamin Franzke's avatar
      [TASK] Drop unneeded renderElement from lit-helper · 8cbd504f
      Benjamin Franzke authored and Christian Kuhn's avatar Christian Kuhn committed
      renderElement() was added in patchset 2 of #93446.
      The code was then refactored to use renderHTML, but the method was
      forgotten to be removed in the final patchset.
      
      Now, the intention of the mentioned patchset 2 was to render nodes
      directly to the DOM in PageTreeDragHandler, instead of rendering to
      a temporary element, just to export and re-import as HTML string
      with jQuery/innerHTML.
      
      Therefore PageTreeDragHandler is now refactored to a new,
      (internal) method renderNodes() which allows the returned
      nodes to be directly attached to the document.
      
      Also, while at it, all other lit-helper methods are marked as
      internal as well, as they are still subject to change:
       * `renderHTML()` is only needed when mixing traditional jQuery
         rendering and lit-html (same as for the new `renderNodes()`.)
       * The `icon()` method could likely be replaced by a custom
         <typo3-backend-icon> component
       * `lll()` is only of use for globally available language identifiers
         (which are added via inline JS)  So this is also likely to change
         when more backend modules start to use lit-html/LitElement.
      
      Resolves: #93464
      Related: #93446
      Releases: master
      Change-Id: I61ab778e28e32b75b6e7965b75259beedbb10ae3
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67663
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      8cbd504f
    • Benni Mack's avatar
      [BUGFIX] Add autocomplete attribute for LoginRefresh form · 248c616e
      Benni Mack authored
      The Backend LoginRefresh password field now also
      contains "autocomplete=current-password" just like
      the login-form.
      
      Sidenote: The attribute (also for the username) must be added manually
      via jQuery as there is a strange bug not allowing "autocomplete".
      
      In addition, it fixes a typo for the rsa-encryption to be
      proper english, and not needing a special handling for
      LoginRefresh.js anymore.
      
      Resolves: #93448
      Releases: master
      Change-Id: Iedf306380a4dbfb5ec31c37f932f8d3b64daf366
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67654
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      248c616e
    • Benni Mack's avatar
      [TASK] Clean up Drag&Drop Handling in PageTree · 85c7264b
      Benni Mack authored and Georg Ringer's avatar Georg Ringer committed
      The PageTree components for the navigation area consists of:
      * PageTreeElement (container for rendering the navigation area w. toolbar + dragdrop + tree)
      * PageTreeToolbar (uses DnD for creating new items)
      * PageTree (JS, subclass of SvgTree)
      * PageTreeDragDrop
      
      This patch aims to rework the "PageTreeDragDrop" javascript file
      by moving separate logic into separate classes (as much as possible)
      and into a more stable API, being a first part.
      
      PageTreeDragDrop is a mixed code class currently,
      and is now split up in various separate classes:
      * DragDropHandler (interface)
      * ToolbarDragHandler -> used as the Toolbar Draggable Handler for new pages
      * PageTreeNodeDragHandler => used for moving/copying and deleting existing pages/nodes
      * PageTreeDragDrop now acts as a simple wrapper for d3-drag but still has some shared state
      
      For Future Reference:
      It is still up to decide on how to further decouple the code.
      
      Idea 1: Putting the d3-drag initialization into the right
      place and avoiding cross-dependencies. In general "initializeDragForNode"
      would also be handled via events, and all options / settings would be
      moved into the PageTreeDragDrop class.
      
      Ideally the PageTreeDragDrop contains the status of the
      current drag+drop action (position, node etc), so the PageTree
      would not know of anything itself.
      
      Idea 2: Another possibility is to use the current "PageTreeDragDrop"
      as a generic "TreeDragDropManager" because it does not
      contain any Page-Tree specific code anymore, but could be carried
      on later-on.
      
      The current change is already a good step as it moves all code
      to TypeScript and minimizes injection via constructors (except
      for the Tree itself).
      
      Resolves: #93446
      Releases: master
      Change-Id: Ibd7a067c1e6a821b138a8cc2971ec8133392b600
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67650
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      85c7264b
  14. 06 Feb, 2021 3 commits
  15. 04 Feb, 2021 2 commits
  16. 02 Feb, 2021 2 commits
  17. 01 Feb, 2021 1 commit
  18. 29 Jan, 2021 1 commit
  19. 27 Jan, 2021 3 commits
  20. 22 Jan, 2021 2 commits
  21. 20 Jan, 2021 1 commit
    • Martin Kutschker's avatar
      [FEATURE] Improve keyboard navigation for module menus · e3d34dd5
      Martin Kutschker authored and Richard Haeser's avatar Richard Haeser committed
      The module menu implements the keyboard navigation suggested
      by the ARIA Best Practices 1.1 for roles "menubar" and "menu".
      The first level menu has a "menubar" role, the second level
      submenus have a "menu" role. The buttons have the "menuitem"
      role. Both the "menubar" and the "menu" are oriented
      vertically for assistive technology matching the visual
      representation which affects the keyboard navigation.
      
      Space/Enter show the module unless the item has a submenu.
      Space/Enter and Right Arrow open a submenu and move focus to
      the first item.
      
      Up/Down Arrow and Home/End navigate within the current
      level of the menu.
      Ctrl + Home/End navigate within the first level of the menu
      (extension of the ARIA pattern).
      
      Left/Right Arrow moves to the parent item's predecessor/successor
      when on a submodule item. The submenu will not be closed
      (deviation from the ARIA pattern).
      
      Escape moves to the parent item of a submodule item.
      The submenu will not be closed (deviation from the ARIA pattern).
      
      Tab and Shift + Tab move to the next item outside of the
      module menu.
      
      The help menu implements the keyboard navigation suggested
      by the ARIA Best Practices 1.1 for the role "menu". This
      is the same as the module menu but limited to a single level.
      
      The change detaches again the module menu's event listener
      from the document as in #91642, but reinitializes
      the event listeners to handle situations as described in #93008
      properly.
      
      Resolves: #92704
      Resolves: #92634
      Resolves: #92613
      Releases: master
      Change-Id: I58ae5caa81882ccebd4e2ae2d944eb99e15a4b18
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66283
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Michael Telgkamp's avatarMichael Telgkamp <michael.telgkamp@mindscreen.de>
      Tested-by: default avatarGuido Schmechel <guido.schmechel@brandung.de>
      Tested-by: Richard Haeser's avatarRichard Haeser <richard@richardhaeser.com>
      Reviewed-by: Michael Telgkamp's avatarMichael Telgkamp <michael.telgkamp@mindscreen.de>
      Reviewed-by: Richard Haeser's avatarRichard Haeser <richard@richardhaeser.com>
      e3d34dd5
  22. 19 Jan, 2021 1 commit
  23. 18 Jan, 2021 1 commit
  24. 11 Jan, 2021 3 commits