nitriques on 3.0.x
Redirect loggued in users to AP… Add documentation about unambig… Allow numeric values in schema … (compare)
nitriques on 3.0.x
Avoid double insert (write) exe… (compare)
Me too, thought I must be missing it.
Thing is, I THINK (it's been DAYS ago) when I first upgraded to 2.7.10 that I got a blank white page, with no detail. On the old forum I found a post where @brendo suggested adding "ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(-1);"
to index.php so you could see the error. So I did add it and could see the details., but removed it after I fixed the error. Now it seems I can't go back.
maplocationfield
that gets rid of all Google Maps and Geocoding and uses Openstreetmap/Nominatim instead. It can be used as a drop-in replacement for the former version. Only limitation is that location names in stored fields and datasource filters are not supported any more, only latlng. I’m happy if anyone is interested in testing: https://github.com/animaux/maplocationfield
2.7.x
(is LTS even an issue any more?) in the main repo3.x
in the main repo2.7.x
and 3.x
while retaining backwards compatibility with PHP7?symphonists
account in order to check/approve PRs 3.x
? I have not been able to use it at all.
I have just finished a major new version of the
maplocationfield
that gets rid of all Google Maps and Geocoding and uses Openstreetmap/Nominatim instead. It can be used as a drop-in replacement for the former version. Only limitation is that location names in stored fields and datasource filters are not supported any more, only latlng. I’m happy if anyone is interested in testing: https://github.com/animaux/maplocationfield
@animaux nice, actually my current project uses maps services (Google), and I was also looking at this extension for backend use but went without it, though the extension was working fine. Anyway, the idea of Openstreetmap/Nominatim is very interesting.
Hi Everyone,
Hope all of you guys doing well. We are trying to secure our very few Symphony apps until they are migrated to new platform and we ran some security tests against those recently and found that if someone gets into the backend somehow they of course can take control over the server via following steps.
1) Create a new section with a file upload input without any restrictions
2) Upload an htaccess file by letting it run phpcode via a different extension
3) Run malicious php code and gain control over important assets on the server (Possibly the whole server via other possible attacks)
For the above particular issue we got an advice from the security team so that there should be a global file extensions whitelist (Not a blacklist) so that it's not possible to upload files such as .htaccess, .sh, .js etc... Restricting certain file extensions to the file upload input (in a specific section) is not an option here as we are talking about someone who already got into the backend. So only way to avoid this is to have a global level file extension whitelist so uploading any files other than in the whitelist is prohibited. We couldn't find a way to do this in the Apache config level and we think the only possibility would be to have a global level extension that will be in effect on file upload inputs.
Please can you guys share your thoughts on this ? WE STRONGLY BELIEVE THIS RISK COULD BE THERE FOR ALMOST ALL THE SYMPHONY SITES.
PLEASE NOTE THAT WE ARE NOT ALLOWED TO SHARE MORE INFORMATION OTHER THAN THE ABOVE STEPS.
.php
upload is blocked.