Mike Street
  1. Home
  2. Blog
  3. TYPO3 Developer Days 2024: Day 2 - 2nd August 2024

TYPO3 Developer Days 2024: Day 2 - 2nd August 2024

Posted on 2nd August 2024. 6 mins reading time

My notes, links and useful points from second day of TYPO3 Developer Days.

See other days:

Our quest for ACL improvements in TYPO3 Core - Tomasz Woldański

T3DD Schedule Link / Slides (tbc) / Video (tbc)

  • No change for TYPO3 user permissions over the last few years
  • Lots of little things can make a big difference
  • Survey results
    • Missing best practices
    • Complex UI/UX
    • Deployable permissions
  • Best practices
    • Avoid setting permissions on a user
    • Have a login for every user (no sharing)
    • Create a different BE User group for each category/role
      • System: User groups for file & database mounts
      • ACL: Content & page permissions
      • Role: No permissions per se, but inherits from all the others
  • Documentation was updated
  • Addition of creating BE user group on initial site setup (v13.1)
  • Addition of CLI commands to create predefined user groups
  • UX Improvements for ACL
    • Split record & modal permissions into different tabs
    • Combined Access with User permissions
    • Searchable fields in the exclude fields permissions
    • Combined read & write (view & modify) permissions into a nicer table
    • Can add & edit users in a when editing the group
  • Extension presets - predefine different roles & permissions in your extension to be loaded
  • Deployable permissions most likely to be v14

Innovating Integration: A Case Study on B2B with TYPO3 Headless - Łukasz Uznański

T3DD Schedule Link / Slides (tbc) / Video (tbc)

Because this was a case study, it was demonstrating what was achieved so there weren't too many notes.

  • Improved their sales process - used TYPO3 as a content hub
  • Vue.js frontend and using TYPO3 headless
  • Choose the right tool for the job
  • Vue front end pulls in different data from different services
  • Nuxt - authenticates with TYPO3 which then connects to Magento
  • Only Magento UID & user group is stored - this allows restricting of content & showing different promotions to different groups - also helps with GDPR

Language Overlay - How it works - Benni Mack

T3DD Schedule Link / Slides (tbc) / Video (tbc)

  • Overlays are used for languages & workspaces
  • Context API has language and workspace state/aspect
  • Language - started as TypoScript but is now a single source of truth in the site config which can be used in FE and BE. This contains all the language config
  • l10n_parent field is used everywhere for localisation config, except tt_content which uses i18n_parent
  • When loading a different language, the default lang record is loaded and then the translation - all the fields are then replaced except the uid. The UID of the translated page is put into _OVERLAY_UID
  • If no translation is found, the fallback chain is referred to
  • Overlay replaces all the data except the UID because:
    • All links point to the default language
    • PID is always the default language
  • Fallbacks are essentially overlays but in the other direction
  • Workspaces
    • t3ver_wsid - What workspace is this?
    • t3ver_oid - The ID of the original/online/live page
    • t3ver_state - Is this a change/deletion/addition
  • When viewing the FE of a workspace, every content & page record is checked for a workspace overlay
    • If a version is found, every field is replaced except PID and UID
  • When loading a language in a workspace, several hops are made:
    1. Live, Default lang
    2. Versioned (workspaced), Default lang
    3. Live, translated version
    4. Versioned, translated version
  • Why is it complicated?
    • Historical reasons
    • No better solution
    • TYPO3 are trying to make it less complicated
    • Keeps the sorting & position accross translations
    • In an ideal world, overlays and sys_language_uid wouldn't be needed
    • Saves space (instead of duplicating the DB, only needed records are made)
      • But does mean more queries
  • Just use the APIs
  • PageRepository has uses the Context API
    • Access Workspace & Language overlays in FE
  • cObj uses PageRepository
  • PageRepository has plenty of PSR-14 events to use
  • BackendUtility for getting Workspace and Language overlays in BE
  • You can use PageRepository in the BE
  • RelationHandler to read & write related DBs
  • Use DataHandler for writing
  • You always need a default language, but can use the "Hide default language of a page" checkbox in page properties

The SAST and the furious - Zack Lott

T3DD Schedule Link / Slides / Video (tbc)

  • Application security
    • Testing security features
    • Prevents users from doing unauthorised actions
  • OWASP Top 10
  • Normal methods for finding security issues
    • Code reviews
    • Previous experience
    • Own Tools
    • Security tools
  • SAST Scanners
    • Analyse your code, like PHPStan
  • Can run during development locally or on CI
  • Doesn't require infrastructure like database
  • Lean on the experts to find issues with predefined rules
  • Semgrep
    • Open source
    • PHP & JS
    • Custom rules
    • Integrate pipelines & run locally
    • Has a library of rules
    • brew install semgrep
  • Supply chain attacks
    • Targets third party vendors (e.g. Crowdstrike)
  • Do you know your dependencies & sub dependencies and if they have CVEs?
  • Trivy
    • Scans NPM, Composer, APT & APK and OS
    • Will identify common CVE
    • Local scanning on computer or server
    • Scan against a repo
    • Scan docker images
    • brew install trivy
  • Gitlab requires setting up with YAML, Github you can "add" it
  • Semgrep and Trivy export JSON, SARIF
  • SBOMs list all your dependencies and are sometimes requested

TYPO3-Rector v2 - Henrik Elsner

T3DD Schedule Link / Slides (tbc) / Video (tbc)

  • Upgrades are long and expensive
  • Any problem that arises after an upgrade is always a problem of the upgrade
  • Rector
    • Migrate TYPO3 TCA
    • Classes/Extbase/Icons PHP
    • TypoScript/YAML/Fluid
    • Will also tell you what it can't do automatically
  • Benefits
    • More time for testing
    • Learn changes you didn't know
    • More efficient
    • Keeps knowledge which gets lost
  • Typo3 Rector is a wrapper for Rector
  • Trust Rector
    • Each rule has tests
    • Dry run on the first run
    • Rector detects the class and ensures the methods are ok (unlike scanner in TYPO3)
    • Treat Rector like a junior employee - not a senior
  • Best practice
    • Clean up your files first (delete unused code)
    • Run Rector for the current version you are on
      • E.g. if you are doing 11 -> 12, run it for 11 first to ensure you are up-to-date
    • Run the latest rector first (v2) then run v1 to catch old rules - then run v2 again in case any rule got updated
  • Tips
    • For TCA it needs a ctrl and columns array keys
    • For selects it needs 'type' => 'select' - even in a TCA override
  • Fractor for files
  • Consider running Rector in CI to prevent old code from being copied/used

Securing TYPO3 Web Applications - Oliver Hader

T3DD Schedule Link / Slides (tbc) / Video (tbc)

  • XSS
    • Allow injection of JS
    • Can lead to remote controlling (e.g. key logger or crypto miner)
    • Different types
    • Protect against SVG uploads
  • GET Param
    • htmlspecialchars
    • json_encode
  • TYPO3
    • <f:format.raw> and <f:format.htmlentitiesDecode> do not sanitise
    • Use <f:format.html> or <f:sanitize.html> instead
  • Be aware of securing your JS files (outside of TYPO3)
  • Encode HTML and JSON
  • Use HTML sanitiser (lib.parseFunc)
  • Use SVG sanitiser for uploaded files
  • Apply a Content Secruity Policy
  • Introduce Trusted Types in your JS
  • SQL Injection
    • Allows injection of SQL
    • Could lead to leaking of sensitive data
  • sqlmap - Runs common SQL injection commands
  • Create named parameters when interacting with the DB
  • Use prepared statements
  • Insecure direct object reference (IDOR)
    • Manipulate/retrieve internal resources by knowing identifiers
    • E.g. UIDs, filenames etc
  • Ensure different values can't be used (i.e. changing an ID in a "update" form)
  • Cross-site Request Forgery
    • Tricked into visiting a malicious website
    • Use strict cookies where possible
    • lax is still a bit stricter than none
    • Dissallow GET method for actions (e.g. creation & deletion)
    • Use CSRF tokens where possible
    • Enable "Enforce referrer" in TYPO3
  • File upload
    • Could allow remote code execution
    • Give you a bad site reputation
    • Could allow information disclosure
  • Checks on file uploads
    • File size
    • File extension
    • Mime type
    • Mime type matches file extension

The Art of Deployment - Martin Helmich

T3DD Schedule Link / Slides / Video (tbc)

  • Deployment evolution
    • FTP
    • FileZilla
    • Rsync
    • Version Control (e.g. git pull on live server)
    • Atomic deployments
  • Deployments should be repeatable and automatable
  • Deployments should not cause downtime
  • Deployments should be reversible
  • There is already Gitlab & TYPO3 deployment configuration
  • Atomic Deployments
    • TYPO3 Surf
    • PHP Deployer
  • Code is straight-forward to deploy
  • Database is harder as it is more difficult to rollback - your app needs to be compatible with both version of the DB
  • Automated deployments need quality control
    • Testing (PHPUnit, Jest)
    • Coding Style (CSFixer, Code Sniffer)
    • Type Checking (PHPStan, PSALM)
  • Containers remove environment disparity
  • Helm is deployment for Kubernetes
  • MACH
    • Microservices
    • API first
    • Cloud Native
    • Headless
      • Microservices create more deployment services
      • Which order do you release?
  • Dark launching
    • Launching code behind a feature flag
    • doesn't matter which order you deploy as you enable the feature after deployment
  • Unleash - an open source feature flag service
    • It's what Gitlab uses under the hood
  • openfeature.dev

Other Talk Resources

TYPO3 Ramblings

View this post on Github

You might also enjoy…

Mike Street

Written by Mike Street

Mike is a CTO and Lead Developer from Brighton, UK. He spends his time writing, cycling and coding. You can find Mike on Mastodon.