My PHP version is : 7.4.29 My MySQL/MariaDB version is (delete as applicable): 10.3.34-MariaDB, pdo_mysql
Updating/Installing Errors I am (delete as applicable): Installing / Updating Upgrading/installing via (delete as applicable) : Command Line
After another painful three week upgrade, my installation now seems to be working OK again on version 4.3.1, but only if I remove this entire block from .htaccess:
# Apache 2.4+
<IfModule authz_core_module>
# Deny access via HTTP requests to all PHP files.
<FilesMatch "\.php$">
Require all denied
</FilesMatch>
# Deny access via HTTP requests to composer files.
<FilesMatch "^(composer\.json|composer\.lock)$">
Require all denied
</FilesMatch>
# Except those allowed below.
<If "%{REQUEST_URI} =~ m#^/(index|index_dev|upgrade/upgrade)\.php#">
Require all granted
</If>
</IfModule>
# Fallback for Apache < 2.4
<IfModule !authz_core_module>
# Deny access via HTTP requests to all PHP files.
<FilesMatch "\.php$">
Order deny,allow
Deny from all
</FilesMatch>
# Deny access via HTTP requests to composer files
<FilesMatch "^(composer\.json|composer\.lock)$">
Order deny,allow
Deny from all
</FilesMatch>
# Except those allowed below.
<If "%{REQUEST_URI} =~ m#^/(index|index_dev|upgrade/upgrade)\.php#">
Order allow,deny
Allow from all
</If>
</IfModule>
If I leave this in, I get a white screen and 403 redirect. This issue was also found here and the solution (?) came from @rcheesleyhere.
I was not able to get it working by editing out one line, I had to remove the entire block. Either way, I am probably opening up big security holes?
How can I fix this?
My Mautic installation is on a subdomain → mywebsite.com/mautic . I remember seeing that was a problem for recent upgrades that you had to work around by changing a line in .htaccess. Is it related to that mess?
Please check the release notes where we made a security fix to the htaccess file:
Removing that entire block is really a very bad idea for security reasons.
You could compare the differences between your pre-upgrade htaccess with the one in the release and focus specifically on that part - the fix for subfolders was provided in the issue here:
If you cannot figure out the changes you need to make to support your current Mautic setup in a subfolder (eg the regex to use) then maybe consider hiring someone to help with that - it should be a relatively simple job.
We are already working on improving the upgrade process, however sometimes we do have to make changes to files like the htaccess as part of a security fix - as was the case in this release.
The fix could have been better implemented and communicated at the time, however we are extremely short handed when it comes to people helping us to test fixes and releases (especially within the security team), so sometimes things are missed. In this case, the volunteer contributing the fix and everyone testing did not think to test with a sub-folder, as all of us use a subdomain and when we test we are always testing in a subdomain. You can be sure we will learn from this going forward when making changes to the htaccess file and make sure we do factor into the equation that folks may be using a subdirectory.
Once the problem became apparent, suggestions for working around this were provided, as you will see in the issue. This should give sufficient information on how to address this if you happen to be using Mautic in a subfolder.
Ultimately, before updating you must read the release notes to check for any important messages about the release. A link is provided with every release notification to the release notes for that release. There will always be times, especially with minor (4.2, 4.3) or major (4.0, 5.0) and sometimes with security fixes, where you will have to take action to amend or tweak your configuration due to changes introduced.
If you feel this can be better managed and communicated then you are warmly invited to be a part of the solution and join the community as an active contributor. You can get involved with the product team to help with reviewing/testing, with the release team who work through making the actual releases, with the marketing or community team - lots of ways to help us to improve the release and upgrade process and help to make Mautic better.
Awesome! Please do join us on Slack in #t-product - that is where we share what is being targeted for consideration, and what we need help with testing. You can get an invite at Mautic Community On Slack
Maybe by adding a helpful comment to the lines that the upgrade script inserts into .htaccess? ‘If 403, remove/edit these lines…’
There’s nothing in the release notes for the ‘Mautic Community 4.4.0’ upgrade, so I am now searching through the old release notes to find the solution.
Hello there, I updated mautic on one of my sub domain and eventually ran into the error 403, I’ve gone through the posts but did not manage to find a solution. could you please be kind to help me out here.
# Use the front controller as index file. It serves as a fallback solution when
# every other rewrite/redirect fails (e.g. in an aliased environment without
# mod_rewrite). Additionally, this reduces the matching process for the
# start page (path "/") because otherwise Apache will apply the rewriting rules
# to each configured DirectoryIndex file (e.g. index.php, index.html, index.pl).
#DirectoryIndex index.php
<IfModule mod_rewrite.c>
RewriteEngine On
# Set Authorization header for OAuth2 for when php is running under fcgi
RewriteCond %{HTTP:Authorization} .+
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
# Determine the RewriteBase automatically and set it as environment variable.
# If you are using Apache aliases to do mass virtual hosting or installed the
# project in a subdirectory, the base path will be prepended to allow proper
# resolution of the app.php file and to redirect to the correct URI. It will
# work in environments without path prefix as well, providing a safe, one-size
# fits all solution. But as you do not need it in this case, you can comment
# the following 2 lines to eliminate the overhead.
RewriteCond %{REQUEST_URI}::$1 ^(/.+)/(.*)::\2$
RewriteRule ^(.*) - [E=BASE:%1]
# Redirect to URI without front controller to prevent duplicate content
# (with and without `/app.php`). Only do this redirect on the initial
# rewrite by Apache and not on subsequent cycles. Otherwise we would get an
# endless redirect loop (request -> rewrite to front controller ->
# redirect -> request -> ...).
# So in case you get a "too many redirects" error or you always get redirected
# to the start page because your Apache does not expose the REDIRECT_STATUS
# environment variable, you have 2 choices:
# - disable this feature by commenting the following 2 lines or
# - use Apache >= 2.3.9 and replace all L flags by END flags and remove the
# following RewriteCond (best solution)
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^index\.php(/(.*)|$) %{ENV:BASE}/$2 [R=301,L]
# If the requested filename exists, simply serve it.
# We only want to let Apache serve files and not directories.
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule .? - [L]
# Rewrite all other queries to the front controller.
RewriteRule .? %{ENV:BASE}/index.php [L]
</IfModule>
<IfModule !mod_rewrite.c>
<IfModule mod_alias.c>
# When mod_rewrite is not available, we instruct a temporary redirect of
# the start page to the front controller explicitly so that the website
# and the generated links can still be used.
RedirectMatch 302 ^(?!/(index\.php|index_dev\.php|app|addons|plugins|media|upgrade))(/(.*))$ /index.php$2
# RedirectTemp cannot be used instead
</IfModule>
</IfModule>
<IfModule mod_php5.c>
# @link https://github.com/mautic/mautic/issues/1504
php_value always_populate_raw_post_data -1
</IfModule>
<IfModule mod_deflate.c>
<IfModule mod_filter.c>
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
# Do not enable compression for file types that could contain secrets
#AddOutputFilterByType DEFLATE text/html
#AddOutputFilterByType DEFLATE text/plain
#AddOutputFilterByType DEFLATE text/xml
#AddOutputFilterByType DEFLATE application/xhtml+xml
#AddOutputFilterByType DEFLATE application/xml
#AddOutputFilterByType DEFLATE application/json
<IfModule mod_setenvif.c>
<IfModule mod_header.c>
# Remove browser bugs (only needed for really old browsers)
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
Header append Vary User-Agent
</IfModule>
</IfModule>
</IfModule>
</IfModule>
# Apache 2.4+
<IfModule authz_core_module>
# Deny access via HTTP requests to all PHP files.
<FilesMatch "\.php$">
Require all denied
</FilesMatch>
# Deny access via HTTP requests to composer files.
<FilesMatch "^(composer\.json|composer\.lock)$">
Require all denied
</FilesMatch>
# Except those allowed below.
<If "%{REQUEST_URI} =~ m#^/(index|index_dev|upgrade/upgrade)\.php#">
Require all granted
</If>
</IfModule>
# Fallback for Apache < 2.4
<IfModule !authz_core_module>
# Deny access via HTTP requests to all PHP files.
<FilesMatch "\.php$">
Require all denied
Deny from all
</FilesMatch>
# Deny access via HTTP requests to composer files
<FilesMatch "^(composer\.json|composer\.lock)$">
Order deny,allow
Deny from all
</FilesMatch>
# Except those allowed below.
<If "%{REQUEST_URI} =~ m#^/(index|index_dev|upgrade/upgrade)\.php#">
Order allow,deny
Allow from all
</If>
</IfModule>
If you host Mautic in a sub-folder (e.g. example.com/mautic) please review the guidance in this GitHub issue before updating, as you will probably need to make some changes to the .htaccess file after you update.
@xiv89 - if you have Mautic on a subdomain like mywebsite.com/mautic, you manually have to add/change this in your .htaccess file after every upgrade:
# Except those allowed below.
<If "%{REQUEST_URI} =~
m#^/mautic/(index|index_dev|upgrade/upgrade)\.php#">
Require all granted
</If>
If you put your Mautic installation on another subdomain name than /mautic/, like /crm/ or something creative, use that of course.
You may see that line twice. On my server I have it in an ‘# Apache 2.4+’ and in a ‘# Fallback for Apache < 2.4’.
In general 404 errors after installation could be caused by file permission errors, for example if you went through the installation process via command line as root, instead of as user.
If you host Mautic in a sub-folder (e.g.