This release is a Beta developer preview of an upcoming 3.1 version of OroPlatform.. In this release we focused on application stability and security.
Oro applications may now connect to websocket server via SSL/TLS connection and pass SSL connect options if necessary. To enable this connection, use the following parameters in the application configuration:
websocket_backend_transportdefines the transport to be used for connection. This option may be set to any registered transport returned by
[stream_get_transports](http://php.net/manual/en/function.stream-get-transports.php); the default value is
websocket_backend_ssl_optionsspecifies the SSL context options that will be passed when establishing the connection.
These configuration options are not exposed on the UI and should be set during the installation or changed in
Connection origin check
To further improve the security of websocket connection and eliminate Cross-Site WebSocket Hijacking (CSWSH) attacks, Origin headers will be checked against the list of allowed origins after the websocket connection is established. This feature utilizes the existing OriginCheck functionality of GoS WebSocket bundle.
New Case-Insensitive Email Addresses configuration option allows the system administrator to restrict user email addresses acceptable for registration. When this option is turned on, all different capitalizations of a same email (e.g. email@example.com and JohnDoe@example.com) will be treated as the same address so only one of them could be used to register a user. This option is off by default, as prescribed by RFC 5321 2.4.
Application ACL model (
OroBundleSecurityBundleORMWalkerAclHelper) can now be extended with access restrictions based not only on the existing ACL model but also on additional data access rules, allowing developers to implement different access models to better suit the business-specific requirements of information visibility.
Please check the Access rules documentation page for additional details on ACL extension mechanism and extension points.
- JSON API is now the default REST API sandbox
- API filters are now enabled by default for one-to-many relations
- We created developer documentation for API filters
- We added data flow diagrams to API action documentation to clarify the use of API processors in customizations
- Schema migrations are now excluded from class docblock validation
customize_loaded_dataprocessors are disabled by default for better application performance
Due to deprecations of Elasticsearch 6 the following changes were introduced:
- Fulltext search will match words only from the beginning of the word – e.g.
Foldable Wheelchairwill be found by
wheel, but not by
- In case of multiple words,
ANDstrategy will be used