I have a server which has been upgraded from IBM Worklight 6.0 to IBM Mobilefirst 6.3
The server is currently running older versions of my mobile application, which do not have AppAuthenticity enabled.
When I uploaded the newer version of Application, AppAuthenticity option became enabled ONLY for one (windows) environment, while others stayed disabled.
After a restart, Windows Environment version became like others, while iPAD environment started giving option to change the AppAuthenticity.
I listed the application through WLADM CLI, and it gave me below error:
XML validation error, reading from
https://URL/wladmin/management-apis/1.0/runtimes/worklight/applications/MYAPPS?locale=en_US:
cvc-complex-type.4: Attribute 'downloadLink' must appear on element
'applicationEnvironmentDataAccess'.
Please note, the application if ran alone on other server is working fine with same Application-descriptor and WAR file, only when Old and new versions are uploaded on same server, this problem comes.
Are you saying your server has a single .war file with 2 apps on it, one from 6.0 and one from 6.3?
There are very different Application Authenticity Protection implementations in 6.0 and 6.3. These cannot co-exist in the same single .war file.
You need to deploy to your application server 2 .war files - one for handling the 6.0 app and another for handling the 6.3 app.
Relevant user documentation can be read here: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_6.3.0/com.ibm.worklight.upgrade.doc/devenv/c_upgrade_to_srvr_in_production_env.html
As Idan said, the 6.0 and 6.3 app can not be handled together, since I only wanted to enable the App Authenticity in the newer version, what I did as a workaround was to connect via WLADM tool and disable the App Authenticity for Older Versions via command line.
Below are the commands one needs to use:
\Worklight\shortcuts>wladm --url=https://server.url/wladmin --user=admin --passwordfile=password.properties
to verify the application's current Authenticity :
app version %CONTEXT% %APP_NAME% %Environment_Name% %versionCode% get authenticitycheckrule
To Disable
app version %CONTEXT% %APP_NAME% %Environment_Name% %versionCode% set authenticitycheckrule DISABLED
Related
I have MFP Server version: 7.1.0.00.20160401-2103
I'm trying to accomplish the following:
MyApp runtime (WAR file) is built using MFP 7.1
My WLAPP's, Adapters and device binaries are built using WL 6.2
Where I need to run 6.2 app inside MFP 7.1 container to mimic my production environment as I can't have two stand alone live server in PROD, one for WL 6.2 and the other for MFP7.1.
My concern is the following for iOS (9+):
The iOS app that is live is built with ATS not configured and bit code disabled using xCode (Version 6.3.1).
What is the configuration on MFP 7.1 that needs to be done to allow the connection from my live application.
WAS security level:
My IHS which is in front of my MFP server has the SSLCipherSpec as:
When I compile the xCode project I'm getting :
[https://IP:PORT/MobileBanking/apps/services/api/MobileBanking/iphone/query] Host is not responsive.
How can I make my 6.2 app works on MFP 7.1.?
Is there a missing configuration I need to add/remove?
I can't make any changes on App level as it is already in PROD. Also I can't migrate the 6.2 app yet as we have timeline/outage issues that we can't meet.
Please see this blog post: https://mobilefirstplatform.ibmcloud.com/blog/2015/09/07/preparing-ibm-mobilefirst-platform-server-app-transport-security-ios-9/
7.1 can run wlapp files that were built by 6.2, but those apps (assuming your server is not configured with session independence), but those apps will not benefit of any 7.1 features because you did not re-build them with 7.1 Studio...
Additionally you must have the server configured with TLS 1.2 support and the client application must be configured with TLS. So yes, you must re-build the app even with 6.2 Studio and re-submit to the App Store.
Previously I had a different version of WAS (8.5.5.3) this morning I installed WAS (8.5.5.6) on my laptop. Also I reinstalled MFP Server to point to new WAS
I started using 'Server configuration tool' then but somehow the tool remembers the old path '/opt/ibm/Websphere/Liberty' and all other old settings
Even I tried removing 'runtime' and 'application' and recreated but still 'tool' picks up the same old details by default
Is there any way to clear the old details (or cache) of 'Server configuration tool' ?
Thanks
Sathish kumar
In the current versions of MFP, there is no link between the application server you selected in Install Manager to deploy Application Center, and the application server that is presented first by the Server Configuration Tool when you deploy an MFP Server. The Server Configuration Tool looks at the list of application servers installed with Install Manager and presents them in the order in which it did find them.
I am trying to install and configure Worklight application center on liberty profile.
I have installed the worklight 6.2 using the installation manager. Along the installation process i have installed the appcenter as well.
The installation was successful. But when i try to access the console it giving me "Context root not found".
Also I have checked the server.xml of the liberty server. It contains the appcenterconsole.war and the applicationcenter.war mapped.
Does anyone experience this problem as well?
This might be the same problem as mentioned here: Worklight Development Server does not start
Please make sure you use Oracle Java, not IBM Java!
I have configured and enabled the App Authenticity in my application using custom Security. Added the security test property in my Application discriptor xml file. In my worklight console the respective application gives me the option to enable the App Authenticity.
Now how to test this feature. Fail case senario. How to explicitly fail the client app for app authenticity. My eithcal Hacking team want to perform this testing.
Thanks.
Easiest way to simulate it would be to:
Deploy your application to the server, build the generated project and install it on the device. See that it works.
Depending on the environment, in application-descriptor.xml:
for Android, alter the signing key used and re-deploy to the server
for iOS, alter the bundleId and re-deploy to the server
Re-launch the already install application, it should now fail.
Note:
In Worklight 6.2 application authenticity will only work with an external application server that Worklight Server is deployed to. Otherwise the feature will "always work" when testing in the Worklight Development Server.
In Worklight 6.1 application authenticity will use a "dummy" challenge when used in the Worklight Developer edition; to really test the feature in v6.1, you must use Worklight Studio and Server based on the Consumer or Enterprise editions.
I am running Worklight Studio 6 from Worklight Enterprise Edition download with Eclipse Juno.
My application is using form security with the WASLTPA login module. The application tests correctly.
When I add AppAuthenticity (needed for device provisioning) my client sees the following error in the console. (None in the server log)
Failed to load resource: the server responded with a status of 401 (Unauthorized)
drilling deeper I see:
/*-secure-
{"challenges":{"wl_authenticityRealm":{"WL-Challenge-Data":"o97e2ph8kguqh1vpljbio1o5k3+23.507-9.852-31.807 "}}}*/
I am running this on the Worklight Development Server packaged with Worklight Studio.
You have mentioned both the Enterprise Edition and Developer Edition.
Please clarify your question with the following: You have installed Worklight using the IBM Installation Manager, yes?
You have an application server (Tomcat/WebSphere/Liberty) installed and you've used the supplied Ant scripts to create the Worklight database(s), configure them, deploy the Worklight platform files to the application server, as well as deploy your project's .war file? (and of course the .wlapp /.adapter file(s)...).
If you have done the above, then you will have in your Worklight Server, now installed on the application server, the required components for App Authenticity to work.
Then there is the case of how you actually configured your project for App Authenticity.
Make sure you follow these steps to set up App Authenticity