Mule has recommended a security update on 19th March which was supposed to be for all supported version of Mule. The below URL is dead:
https://help.mulesoft.com/s/article/High-security-issue-affecting-Mule-runtimes-of-all-supported-versions-March-19th-2020
Could someone help what this vulnerability or security patch was about?
I am using Mule runtime v3.9.0
As per the latest article, I could only find out that the security patch on 19th March has some issues and was fixed by mule through https://help.mulesoft.com/s/article/Error-Provided-value-xx-is-not-compliant-with-the-format-datetime-provided-in-rfc3339
The URL is valid but it requires to be logged in from a customer account to access it. If you are a customer you have to be logged in Help Center before accessing the URL.
If you are not a customer I would assume that you are using Mule Community Edition 3.9.0. I'm not sure if the community edition is affected by the issue or not. You should download the latest hotfix release, 3.9.0-hf2, just in case.
The security patch introduced more strict date time validation, which could cause issues for applications that previously accepted invalid date time values, as explained in the second KB article you shared.
Related
I am facing a weird problem today, when running my MuleSoft application locally from my AnypointStudio and firing a request from postman, I am getting 403 error. When debugging I found out that the application is checking for flowVars._clientName, however it is missing. According to this documentation, actually yes flowVars._clientName is expected.
https://help.mulesoft.com/s/article/How-to-get-the-client-application-name-in-a-flow-based-on-the-client-id-and-client-secret.
So my application fails with 403 error. Seems that other environments are working perfectly fine.
And yes it is using Client Id enforcement.
Any clues?
Without more details it looks like the issue is inside the logic of your application. The KB article that you referenced is a how to in case you need to obtain the client name. It doesn't say that you have to use for authentication. You don't describe how the application does authentication/authorization. Is it in a flow? Or in a policy? If it is the standard Client ID enforcement policy, the expressions to evaluate client id and secret can be configured, but I don't think the default is not #[flowVars._clientName] nor #[flowVars._clientId].
Note that Exchange is basically a repository of APIs and other artifacts. It doesn't authenticate anything at execution time. Unless your application is trying to use it somehow, but I can't think of a reason for that.
The issue was resolved only by re-downloading Anypoint Studio and mule runtime. Very weird, it was happening only for one application, not for the others. Creating a new workspace did not help, deleting the application and re-cloning and installing did not help, even recloning in a new directory did not help. Only using a new Anypoint Studio and runtime installation resolved it (even with the old code base) ...
Using MFP8, I have truncated MFP_PERSISTENT_DATA and MFP_TRANSIENT_DATA of more than 0.8 million records in live.
Currently, iOS users are facing issues and can see the below logs in server. How to rectify the same
ibm.mfp.server.registration.internal.RegistrationServiceImpl E FWLSE4213E: Client JWT authentication failed - public keys do not match com.ibm.mfp.server.security.shared.webtoken.WebTokenException: Invalid signature
ibm.mfp.server.registration.internal.rest.RegistrationEndpoint E FWLSE4225E: Invalid update self registration request, client signature could not be verified com.ibm.mfp.server.security.shared.webtoken.WebTokenException: Invalid signature
ibm.mfp.server.registration.internal.rest.RegistrationEndpoint E FWLSE4224E: Failed to process registration request.
com.ibm.mfp.server.core.shared.MFPRESTException: 400; headers=[]; body={ errorCode=APPLICATION_DOES_NOT_EXIST errorMsg=Application doesn't exist}
Firstly, random deletion of entries from the MFP-PERSISTENT_DATA is not at all recommended thing to do.for any cleanup of tables, we would recommend you to do so via https://mobilefirstplatform.ibmcloud.com/blog/2018/12/27/purge-mfp-runtime-tables/. suggestions given your current scenario is
1) Starting Nov 2018 level of SDK, Intelligence is incorporated in to MFP SDK to take care of such accidental deletions by cleaning up client context and doing fresh registration. If the customer’s application has a client SDK level that takes care of auto registration , this issue would not appear and MFP SDK will recover from the above error scenario by cleaning up and doing fresh registration . As per information provided below, customer is in a older level of SDK and the auto re registration feature requires an SDK level of Nov 2018 or later.
2) Is there a way to backup / restore data which you have truncated ? if you have taken backup / can you restore and follow proper instructions to clean up as updated in the blog above ?
3)Provided there is no way to restore / cannot upgrade their application to a newer level of SDK , options are to manually clear the application cache /uninstall and reinstall of the application which needs end user actions to recover.
4) Another option is to update your application to setServerURL() method upon this error, but this would again need update to application and careful planning to ensure it is added appropriately only to the exact error scenario in the application logic as it clears the client context completely
https://mobilefirstplatform.ibmcloud.com/api-ref/wl-android-n-java-apidoc/html/refjava-worklight-android-native/html/com/worklight/androidgap/api/WL.html#setServerUrl(java.net.URL)
Firstly, there are related posts:
GlassFish Server update center installation times out
Java EE 7 updatetool installation fails
I got my Java EE 7 SDK (Update 3) from here: http://www.oracle.com/technetwork/java/javaee/downloads/index.html
I have tried each of the solutions in the above posts and here: https://blogs.oracle.com/dipol/troubleshooting-glassfish-update-center
Including:
In the cmd prompt running set PKG_CLIENT_CONNECT_TIMEOUT=300 and set PKG_CLIENT_READ_TIMEOUT=300 before updatetool in C:\glassfish4\bin\updatetool.bat (c:\glassfish4 in my install directory - all settings were default, including install update tool...).
Set above mentioned timeout to much larger values - doesn't appear to make a difference at all, the process basically bombs immediately.
Running C:\glassfish4\bin\updatetool.bat many times.
Triple checking that I didn't somehow configure a proxy server in my sleep.
Use the update tool via the Glassfish admin console at http://localhost:4848 (seems to show no available update or add-ons, which seems odd..)
I get the following screenshot when I run C:\glassfish4\bin\updatetool.bat
I have no idea why the error would be proxy related, unless it happened to be something on their end. Interestingly, If I go directly to the URL mentioned (via Chrome) I get the following page:
What could possibly be going wrong here?
The updatetool was a commercial feature of Oracle GlassFish. Any update functionality relied on Oracle providing a site where updates could be hosted. Since Oracle GlassFish is no longer supported, this site no longer exists so the updatetool won't work any more.
Rather than downloading GlassFish from Oracle, you should download it from the official open source site, hosted on GitHub. Alternatively, if you really do need support, you could try Payara Server which is open source, and derived from GlassFish, but has support available (disclaimer: I work for Payara)
I use GlassFish 4.1 single cluster with two instances on same node.
My steps for rolling upgrade:
deploy app with old version ClusterTest:1.0
(asadmin deploy --target=cluster1 --enabled=true --availabilityenabled=true --name=ClusterTest:1.0 ClusterTest.ear)
deploy new version app with disabled state ClusterTest:1.1
(asadmin deploy --target=cluster1 --enabled=false --availabilityenabled=true --name=ClusterTest:1.1 ClusterTest.ear)
enable app on 1st instance
(asadmin enable --target=instance1 ClusterTest:1.1)
On 1st instance new app is available, but on 2nd: 404 error (i expect available old version)
what i do wrong?
There are a lot of problems with rolling upgrades on GlassFish. Many of these problems have been fixed in the latest version of Payara Server. It may be that you aren't hitting any of these issues, but there is a very detailed discussion on the Payara GitHub repository:
https://github.com/payara/Payara/issues/455
You may also want to look at this video which describes basic application versioning which may contain the information you need
https://www.youtube.com/watch?v=6QVBsH6IjEA
Does Mule community edition v3.3.0 support shutdownTimeout feature?
The documentation at http://www.mulesoft.org/documentation/display/current/Global+Settings+Configuration+Reference suggests that the shutdowntimeout feature is supported from v2.2.0 but I am not able to get that shutdownTimeout feature to work?
Does anybody has implemented that shutdown feature in Mule v3.3.0 CE? Please help me in configuring that and get that feature to work.
Is this feature available only for EE or it is available in CE too?
the attribute is present and taken into account in 3.3.0.
In order to use it you should add a configuration tag in your config file and set a value for that attribute:
<mule>
...
<configuration shutdownTimeout="60000" />
...
However, as reported in https://www.mulesoft.org/jira/browse/MULE-6816 depending on the message processors present in your flow, the shutdown process could fail, if that's the case you could review the code changes in the fix and apply them.
What problem are you facing?
Regards,
Marcos