We are having an issue with an adapter procedure that uses xsl… To isolate I created a new adapter and ran with the example procedures (getStories, getStoriesFiltered) via procedure invocation via a direct HTTP request and via a native mobile application (iOS).
“Just in case” both procedures were tested both without the securityTest attribute and with.
In the case of getStories (which has no xsl filtering) the result was returned on both the http request and the native app. This is both in the local dev WL server and when deployed to the remote WL test server.
In the case of getStoriesFiltered (which has an xsl filter) on the local dev WL server it runs fine. With the adapter deployed to the remote WL test server we get an error… details are:
Error from Invoking from a browser:
/-secure- {"errors":["Verify Error: java.lang.VerifyError: JVMVRFY013
class loading constraint violated;
class=org/apache/xalan/xsltc/dom/SAXImpl,
method=getAxisIterator(I)Lorg/apache/xml/dtm/DTMAxisIterator;,
pc=0"],"isSuccessful":false,"warnings":[],"info":[]}/
Error from invoking from a native mobile client (iOS):
2014-05-16 16:36:46.681 iOSNativeApp[1109:60b] Procedure Invocation
Failure: Invocation failure. /-secure-
{"responseID":"1","errors":["Verify Error: java.lang.VerifyError:
JVMVRFY013 class loading constraint violated;
class=org/apache/xalan/xsltc/dom/SAXImpl,
method=getAxisIterator(I)Lorg/apache/xml/dtm/DTMAxisIterator;,
pc=0"],"isSuccessful":false,"WL-Authentication-Success":{"wl_remoteDisableRealm":{"userId":"null","attributes":{},"isUserAuthenticated":1,"displayName":"null"},"wl_antiXSRFRealm":{"userId":"u9eb8v4tpofoartngepouli22q","attributes":{},"isUserAuthenticated":1,"displayName":"u9eb8v4tpofoartngepouli22q"},"wl_deviceNoProvisioningRealm":{"userId":"10C0FDF9-8537-47E7-99B3-99E41ABC7956","attributes":{"mobileClientData":"com.worklight.core.auth.ext.MobileClientData#2b13dac8"},"isUserAuthenticated":1,"displayName":"10C0FDF9-8537-47E7-99B3-99E41ABC7956"},"wl_anonymousUserRealm":{"userId":"484ed960-5aaf-48b0-a05d-166e38613d47","attributes":{},"isUserAuthenticated":1,"displayName":"484ed960-5aaf-48b0-a05d-166e38613d47"}},"warnings":[],"info":[]}/
Running Worklight on Liberty.
Please always mention your Worklight version when asking a question...
In any case, this specific error is due to a regression in recently released versions of Worklight:
5.0.6.2-IF201403101802
6.0.0.2
6.1.0.1
An iFix for 6.1.0.1 should be released shortly, with iFixes for 5.0.6.2 and 6.0.0.2 to arrive soon.
To access an iFix, login to IBM Fix Central and download the latest iFix available for your version of Worklight (released on or after May 15th)
Related
I encounter this error on the console logs of an iPad hybrid app built on MobileFirst Platform 7.1, when using WL.Client.connect():
2017-03-14 01:45:34.552 myApp[37732:5685087]
[ERROR] [WL_REQUEST] __43-[WLRequest processFailuresWithDictionary:]_block_invoke in WLRequest.m:694 ::
Challenge handler does not exist. There is no registered challenge handler with key wl_sessionIndependentSupport
It seems, however, wl_sessionIndependentSupport is not documented anywhere, so I have no clue on how to solve this error.
Our server is configured for session-independent mode, but I am not aware of it requiring any client-side changes.(See here, for example).
I'm trying to register my app in SITServer using MobileFirst 8.0 by following this tutorial
1) Hitting this error:
mfpdev app register SITServer
Verifying server configuration... Error: Cannot connect to server
'SITServer' at 'http://xxx.xxx.xxx.xxx:9080'. Reason: Failed to set
runtime details.: Unexpected token < in JSON at position 0: HTTP 404 -
Not Found
$ mfpdev server info
2) Is it caused by the difference in server version? My Local server version is 8.0.0-2016101416 and SITServer version is 8.0.0.00-20160822-2140
I suspect this happened due to some of the changes you've made to the server.xml; you did not mention which changes you've done so I would advise to double check those (any real reason to change these?).
Either way, both HTTP and HTTPS are supported, yes.
after the fixpack in subject, i cannot manage to direct update my application.
It notify me that there is a new version available, but when i hit Update it keeps saying that the download failed (both on iOS and Android).
I attached my android to adb and i noticed those lines in the console:
Authentication error: Unable to respond to any of these challenges:
{wl-composite-challenge=WWW-Authenticate: WL-Composite-Challenge}
java.io.IOException: Error downloading update file The following
message has been received from the server instead of the expected
application update zip file: HTTP/1.1 401 Unauthorized
/-secure-{"challenges":{"wl_deviceNoProvisioningRealm":{"token":"1or0tj7gnoev1rn06s188j4u9h"},"wl_antiXSRFRealm":{"WL-Instance-Id":"np8c8o3c4dk1k7s79i2ikddfab"}}}/
at
com.worklight.androidgap.plugin.WebResourcesDownloaderPlugin$WebResourcesDownloader.downloadZipFile(WebResourcesDownloaderPlugin.java:364)
To complete the information I deployed the IBM_Worklight_Console with no security role in its web.xml and we have Worklight 6.1.0.1 installed on WAS Network Deployment 7.0.0.23 running AIX.
Before the fixpack, everything worked well.
Thank you
EDIT: here you can see my application-descriptor.xml and my server configuration:
I forgot about this stack, however I found the problem.
When I open my application, the WL Framework asks for new available update. In the same time, my application ask an adapter for some data, before the WL server can response about the Update. So if it arrives first the response of my adpater, then the Update response will contain a different requestID causing a 403 forbidden.
I don't know if I explained it clearly, however the temporary fix is to put updateSilently: true, not disturbing the direct update.
I've encountered a problem during development.
When the adapter is tested from within Eclipse ("Invoke Worklight procedure"), it does its job perfectly.
On the contrary, when the adapter is called from the app, it doesn't work. I receive the following error:
Error 405 HTTP method POST is not supported by this URL
I've noticed a strange thing. When the adapter is called from the test procedure the URL seems correct (/apps/services/api/...) In the other case, Worklight puts a worklight prefix (/worklight/apps/services/api/...) when it makes the call. Hence the URL cannot be reached.
Here Worklight Studio - error http 405 when connecting to mobile URL provided by Console I found a partial solution but it does not work.
Additional info
WL version is 5.0.6.
Application server is Tomcat 7.
Based on my experiments I found the problem.
Each worklight project has an application-descriptor.xml. Within it there is a tag that indicates the WL server root URL.
Since I've taken the project from another source, I've simply noticed that it was configured as
<worklightServerRootURL>http://sampleDomain/worklight</worklightServerRootURL>
where sampleDomain is only a placeholder for the real one.
Now it is configured like
<worklightServerRootURL>http://${local.IPAddress}:8080</worklightServerRootURL>
to perform internal local tests.
Hope it helps.
I have successfully gotten the module 41 sample running with eclipse and the local server. Attempting to deploy on my liberty server returns the error.
Failed to deploy application 'PushApplication-all.wlapp'. : application descriptor uses a security test:PushApplication-strong-mobile-securityTest. However, authentication config xml does not contain a security test element with that name.
I am on Worklight 5.0.5 with a successful app running on the server and now trying to add push notifications. I have checked the war file and it does contain the authentication-config.xml with the specified test.
I saw a smilier post a few momths ago but am unable to find whether it got answered
thanks in advance.
From the sound of it, you are trying to deploy your .wlapp to a server that is already running an instance of Worklight, but this instance does not have the required securityTest settings in authenticationConfig.xml
This leads me to believe that you did not replace the .war file you already had deployed in the Liberty-profile application server with the .war file from your Push Notifications project, which contains the up-to-date authenticationConfig.xml