Muse Proxy Changelog

What's new in Muse Proxy 4.4 Build 02

• NEW FEATURES:
• Muse Proxy can now create access log files in the same configurable format as those created by standard web servers such as Apache HTTP Server, format which can be set via a % style pattern (an extension of the Common Logging format). In order to do this, the LOG_FORMAT element should have the type="apache" attribute set. To have a good base for statistical information, especially in a multi-tenant environment, we recommend using more items besides Common Logging, by adding the inbound server IP address, Muse Proxy application, user session, content type:%h %A %w %W %u %S %t "%r" "%{Content-Type}o"
• %s %b. On a fresh installation this format is already set up, while on an upgrade the old format is left in place to keep compatibility in case there are external log parsers set. If a different output is needed then more information can be found in the document ${MUSE_HOME}/proxy/doc/Muse Proxy.pdf in section "7.2 The access Log".
• Introduced support in ProxyLoginModuleSQL.xml for SQL statements. More details on how to use this feature are present in Muse Proxy Advanced Configuration.pdf, section 6.4.5.6 ProxyLoginModuleSQL. The backward compatibility for specifying a table is kept.
• Added support for IP ranges in ALLOW and DENY rules from ProxyLoginModuleIP.xml, and this range will be matched against the IP address the connection is coming from. Both IPv4 and IPv6 are supported. All types of rules can be mixed if need be, for example one allow/deny rule can be a wildcard such as 217.156.14.*, another rule can be a CIDR rule such as 217.156.0.0/16 and another one can be expressed using the range 217.156.11.0-217.156.15.255.
• Introduced redirection to remote Sources depending on the end-user IP (non-proxied links). This is done via Sources.xml file via the new REDIRECT section containing IP_RULES elements which are applied on a set of sources and, if the request is for a source that matches the APPLY pattern and the request's end-user IP satisfies the ALLOW/DENY sequences, then the response will be a native redirect to the source URL.
• Source parameters can be provided via Sources.xml level in the element via multiple children. Each parameter can be further referred in the Source Profile in or via ${name} syntax and its value will be resolved to the content of this node, exactly as if it were defined inside the source profile.
• The Single Sign-on Authentication (other than SAML) core was upgraded and part of the new features Central Authentication Service (CAS) is also supported. Upgrades instructions related to how to handle the changes in securityContext.xml are provided via the setup.
• Keep up with SHA1 deprecation.
• To avoid DNS limitation of 63 bytes per label in case of proxing https:// hosts via Rewrite by Host technique using https:// proxy URLs, there is now the possibility to map the very long FQDN to shorter names by using HOST_MAPPING elements in the source profile.
• This release contains an improvement for Multi tenant environments using the same host name for all tenants but individual IPs for each one. A chaining request to proxy itself on the different IP is no longer taking place for each request, rather the outbound IP is set directly to the one of the chainingproxy.Toachievethisonlythe PROXY_HOSTmustbeconfiguredtotheallocatedIPin the source profile or at the application level and the PROXY_PORT must remain empty.
• The generation of the Client Session cookie values was improved. The generation of the Connection ID values was also improved.
• Implement an improvement when action=source is called, and data is read from the Sources.xml application file.
• Refine the errors "Unexpected exception while accessing target source." to contain more details about what was wrong with the access.
• Added a limit for the size of multipart POST requests which will be kept in memory and requests which will exceed this limit will be temporary saved on the file system. The value of the limit is configured in USE_MULTIPART_TMP_AFTER tag from ${MUSE_HOME}/proxy/MuseProxy.xml.
• Added COOKIE_PASS_PATTERNS options and cookies with name matching these patterns are passed into the browser even if they have a domain. This configuration must be used with care and only where strictly required. Cookie name patterns can be specified such as SESSION*, separated by semicolon (;).
• Secured the /admin context availability.
• Related to proxy application IP Authentication, the REVERSE flag was added to control if reverse DNS is performed for the end-user IP. The trend is to set it false in the configuration files from now on. Reverse DNS is too costly and can slow down the authentication process.
• In case of HMAC, Referer and IP login modules there's no ID to check against a database and hence nothing to be written in the log file, however in case of various integrations we could be receiving a special parameter in the request for tracking purposes and we want to keep this for logging.
• Because JSESSIONID name is too general, the session cookie names for the embedded Jetty
• contexts (related to Single sign-on) were changed.
• Added encodeURIComponent and decodeURIComponent to be used for reference and parameter process for first source requests (including extract and navigate scenarios). The functions are compatible with the JavaScript ones. The existent encodeURL and decodeURL are based on JDK URLEncoder/URLDecoder which are using application/x-www-form-urlencoded MIME format which is not entirely the same as the URI encoding which, for example transforms space into instead of +, for example and some servers are sensitive to these differences.
• Bug fixes:
• Microsoft Azure AD OpenID Connect End Point v2.0 and End Point v1.0 can now be used for authentication without complex workarounds - guidelines and suggestions are available in the Ad ministrator Console in Configuration / SSO Authentication.
• Security constraints for SAML or SSO authentication when starting from plain http:// proxy links are by default not enforced.
• HttpModuleApache is now correctly sending post data for the extract and navigate scenarios as URL encoded data.
• Filtering on the exact Client Session ID in the Administrator Console was corrected.
• Fixed parameter name encoding for HMAC Link Generator page inside Administrator Console.
• Avoid redirect loops when a Type 2 (rewrite by path) link expires for SSO2 (OAuth / OpenID) authentication.
• Correctly persisting Tiny URLs, that are used in some cases for MuseKnowledge Search integration.
• Fixed memory usage when downloading more log files from the Administrator Console.
• Quicker release of file descriptors when local resources such as images, javascript or css are served by Muse Proxy.
• While rewriting object, embed and param elements the protocol relative URLs (the ones starting with //) are correctly treated.
• The starting point Type1 links used for MuseKnowledge Search integration can also be generated on https:// protocol.
• Existing navigation session were ignoring the FIND/REPLACE filters after a mnm.jar update - this is now fixed.
• A very rare deadlock appearing when a Muse Proxy under extremely heavy usage has its mnm.jar updated. This fix is actually carried by mnm.jar version 1.513 itself, so old versions of Muse Proxy can be updated without a full upgrade to fix this.
• Interpreting the request Forwarded headers was failing if no proto= was found in any of these headers. This is now fixed.
• The following rare case was fixed: if the same linkout source is in two different applications and the same end-user accesses both applications from the same browser at the same time it is possible that the source we link to is used via a navigation session from the other application yielding misleading statistics.
• Protocol relative URLs in HTTP redirects could have generated wrongly rewritten links - this was fixed.
• In case no ENCODING is defined in the source profile, first source request(s) (such as extract and navigate) are now considering UTF-8 as a default encoding for various processing such as parameter encoding processing or deserialization from gzipped content (also when no charset is present in the Content-Type reply).
• All multiple HTTP response header fields are now reaching the browser in the response to the first rewritten URL (by host or by path) request which is initiated by the source request (?action=source, ?url=).