willdurand/js-translation-bundle
Full Changelog: https://github.com/willdurand/BazingaJsTranslationBundle/compare/7.0.0...8.0.0
Full Changelog: https://github.com/willdurand/BazingaJsTranslationBundle/compare/6.1.0...7.0.0
Thanks @karion @tacman and @stof for helping this release.
Full Changelog: https://github.com/willdurand/BazingaJsTranslationBundle/compare/6.0.0...6.1.0
Full Changelog: https://github.com/willdurand/BazingaJsTranslationBundle/compare/5.1.0...6.0.0
Full Changelog: https://github.com/willdurand/BazingaJsTranslationBundle/compare/5.0.0...5.1.0
Full Changelog: https://github.com/willdurand/BazingaJsTranslationBundle/compare/4.0.2...5.0.0
Added: Github action support (https://github.com/willdurand/BazingaJsTranslationBundle/pull/309)
Fixed: Fixed: Fix get_message on intl_icu if domain is undefined (#314) - Thanks @spras Fixed: Prevent translation files overwriting files from addResource calls (#320) - Thanks @carakas
Fixed: Check the commonJS before AMD dependency for intl-messageformat (#304) - Thanks @ChristianVermeulen
Added: Support for Composer 2.0 (https://github.com/willdurand/BazingaJsTranslationBundle/pull/282) - Thanks @blankse Added: Support for ICU-based message formatting (https://github.com/willdurand/BazingaJsTranslationBundle/pull/288) - Thanks @Kocal Removed: support for Symfony < 3.3 constructor signature (#214) - Thanks @pierredup Fixed: All Travis tests, dropping officially the support of Symfony 3.4 (#296, #300) - Thanks @craigh
Fix: IE bug related to $0 in target placeholder value (#207)
Fix: replace phantom.args by system.args to run the latest version of phantomJS (#215)
Fix: Register command manually to avoid warning in Symfony 3.4 (#220)
Drop PHP 5.3 Support (#218)
Added: Symfony 4 support (#224)
Build URL for specific locales with Symfony Router (#234)
Remove templating dependency (#213)
Remove container injection (#221)
npm run build command inside Resources/ to minify the translator.js file.framework.translator.paths configuration (more information in http://symfony.com/doc/2.8/translation.html)--format and --merge-domains options to bazinga:js-translation:dump command:
--format allows you to specify which formats must be included in the output--merge-domains when set will generate only one file per locale with all the domains in itTranslationFinder. Every translation file is fetched from the Symfony's FrameworkBundle.TranslationFinder::getLocations() visibility to use is in an inheritant classbazinga_jstranslation_jsConfigCache instance with getPath() to omit deprecated warningValidator classname with Validation to omit deprecated warningFixed: allow all sort of locales (see #119)
Fixed: better locale filtering
This is a security release. All users MUST upgrade to this release to prevent two potential security issues:
These two security issues have been reported by Andreas Forsblom. THANKS!
Below is the original report Andreas sent me:
Hi William,
First, thank you for a very useful bundle :)
Unfortunately, while investigating if a Symfony project I'm working on was vulnerable to the recent translation-related Symfony security issue (CVE-2014-4931), fixed in Symfony 2.5.2, I discovered that JsTranslationBundle seems to be vulnerable to a unrelated path traversal attack, and potentially also a js injection attack.
---
If I try to retrieve the translations using the following url:
http://localhost/translations?locales=randomstring/something
the file something.js gets created in the subdirectory messages.randomstring of the cache directory:
/var/www/someproject/app/cache/dev/bazinga-js-translation/messages.randomstring/something.js
(this is the actual string that gets passed to the constructor of ConfigCache by the JsTranslationBundle controller)
I can now traverse down from the JsTranslationBundle cache directory (without first creating the "messages.randomstring" directory using the previous step, this won't work):
http://localhost/translations?locales=randomstring/../../evil
becomes
/var/www/someproject/app/cache/dev/bazinga-js-translation/messages.randomstring/../../evil.js
... and depending on the configuration of the server, I could also do
http://localhost/translations?locales=randomstring/../../../../../web/evil
=>
/var/www/someproject/app/cache/dev/bazinga-js-translation/messages.randomstring/../../../../../web/evil.js
thus creating the file evil.js (and evil.js.meta) under the Symfony web root. Depending on file system permissions, this will also overwrite existing files.
---
Again depending on the server configuration, it also seems to be possible to inject actual JavaScript code:
http://localhost/translations?locales=foo%0Auncommented%20code;
=>
(function (Translator) {
Translator.fallback = 'en';
Translator.defaultDomain = 'messages';
// foo
uncommented code;
})(Translator);
This works on some systems I tried, but not others. I suspect it might be related to the character set configuration, but I haven't investigated it further yet.
---
I did my testing using JsTranslationBundle 2.1.0 and Symfony 2.5.2.
Since this is a security issue, I didn't want to submit a pull request or use the GitHub issue tracker.
Three commits fixed these issues: df6c0fd603c0192ebc5584991a52a1092c5f60bd, 7accee93569c3f3d2379f035a41ece66522801fc, and 6ee06b9e974b9b768544fbbd6e1432773d205ebd.
You will find three patch files below in case you can't easily upgrade to this release.
locale parameteres5-shim and transChoice in MSIE8pt-BR lang attributeArray.prototype methodsImportant: This bundle is now tested against PHP 5.4, 5.5, and 5.6. No effort will be made to keep the code "5.3 compliant".
Thanks to all contributors!
How can I help you explore Laravel packages today?