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).
Related
We are getting below logs in analytics console (client logs). Does any one has idea root cause behind this debug log.
Date Thursday, Mar 10, 2016, 12:35 AM
Application Name XYZAPP
Application Version 1.9.1
Operating System ios
Device ID BD39F272-D57F-45AC-AACE-3C0277BA796B
Device Model iPhone8,1
OS Version 9.2.1
Package WL_AFHTTPRequestOperationManagerWrapper_PACKAGE
Level Debug
Message Response Error : Request failed: forbidden (403)
A 403 means that no user is allowed to access that resource strictly FORBIDDEN. Not to be confused with a 401 which is UNAUTHORIZED (you just do not have the right credentials).
Unfortunately that is all we can determine from the error.
WLResourceReqeust uses WL_AFHTTPRequestOperationManagerWrapper_PACKAGE and all request made by the client is a ResourceRequest.
Putting a few things together my guess is that this comes from when a user is trying to authenticate with the server. Occasionally we (the mobilefirst server) returns a 403 which is will be logged in the analytics console if you are sending debug logs.
in previously correctly working dev. environment with WL 6.1.0.01.20140311-2356 after upgrade to Chrome 37.0.2062.120 there is now the following error when calling submitSuccess during authentication.
CHROME BROWSER LOG:
Uncaught SyntaxError: Failed to execute 'setRequestHeader' on
'XMLHttpRequest':
'{"wl_deviceNoProvisioningRealm":{"ID":{"token":"pg8cd4gnjh1kb0sjko6h1chqr4","app":{"id":"Moje
ČZU","version":"1.0"},"device":{"id":"previewDummyId","os":"previewDummyOS","model":"previewDummyModel","environment":"preview"},"custom":{}}}}'
is not a valid HTTP header field value.
WL SERVER LOG:
SRVE0777E: Exception thrown by application class
'com.worklight.core.auth.impl.AuthenticationContext.pushCurrentResource:398'
com.worklight.server.auth.api.WorkLightAuthenticationException at
com.worklight.core.auth.impl.AuthenticationContext.pushCurrentResource(AuthenticationContext.java:398)
at
com.worklight.core.auth.impl.AuthenticationServiceBean.accessResource(AuthenticationServiceBean.java:75)
at
com.worklight.integration.services.impl.DataAccessServiceImpl.invokeProcedureInternal(DataAccessServiceImpl.java:389)
at
com.worklight.integration.services.impl.DataAccessServiceImpl.invokeProcedure(DataAccessServiceImpl.java:112)
at
com.worklight.gadgets.serving.handler.BackendQueryHandler.getContent(BackendQueryHandler.java:182)
at
com.worklight.gadgets.serving.handler.BackendQueryHandler.doPost(BackendQueryHandler.java:73)
at
com.worklight.gadgets.serving.GadgetAPIServlet.doGetOrPost(GadgetAPIServlet.java:141)
at
com.worklight.gadgets.serving.GadgetAPIServlet.doPost(GadgetAPIServlet.java:103)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:668) at
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1240)
at [internal classes] at
com.worklight.core.auth.impl.AuthenticationFilter$1.execute(AuthenticationFilter.java:191)
at
com.worklight.core.auth.impl.AuthenticationServiceBean.accessResource(AuthenticationServiceBean.java:76)
at
com.worklight.core.auth.impl.AuthenticationFilter.doFilter(AuthenticationFilter.java:195)
at
com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:194)
at [internal classes]
not sure if "Moje ĆZU" latin2 character here not causing the issue?
Previous steps in authentication process looks working fine.
Firefox and Opera are also stuck but with different behavior.
However, when the app is deployed to Android device App still works fine.
This looks like an encoding issue.
When generating an application for the first time, the application id value in application-descriptor.xml is generated from the chosen app name; you can then alter it to anything else you'd like.
Note, though, that when adding a mobile environment the same value is used there as well, so if you are altering the value after already creating a mobile environment (which will have the "native" folder), you need to remove that native folder to have all artifacts re-generated correctly. Or, do a find all/replace and verify everything is working.
Worklight will not auto-replace this value after changing it in application-descriptor.xml.
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 have implement Encrypted Cache in my application. When testing is in the Mobile Web environment using the mobile browser in my device, I get the following exception:
[ERROR ] FWLSE0048E: Unhandled exception caught: SRVE0190E: File not
found: /apps/services/BMA_app/apps/services/random
java.io.FileNotFoundException: SRVE0190E: File not found:
/apps/services/BMA_app/apps/services/random at
com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.handleRequest(DefaultExtensionProcessor.java:496)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:127)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:88)
at
com.worklight.core.auth.impl.AuthenticationFilter$1.execute(AuthenticationFilter.java:191)
at
com.worklight.core.auth.impl.AuthenticationServiceBean.accessResource(AuthenticationServiceBean.java:76)
at
com.worklight.core.auth.impl.AuthenticationFilter.doFilter(AuthenticationFilter.java:195)
at
com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:194)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:85)
at
com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:949)
at
com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1029)
at
com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:4499)
at
com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.handleRequest(DynamicVirtualHost.java:282)
at
com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:954)
at
com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.run(DynamicVirtualHost.java:252)
at
com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink$TaskWrapper.run(HttpDispatcherLink.java:584)
at com.ibm.ws.threading.internal.Worker.executeWork(Worker.java:439)
at com.ibm.ws.threading.internal.Worker.run(Worker.java:421) at
java.lang.Thread.run(Thread.java:701) [project BMA_app] SRVE0190E:
File not found: /apps/services/BMA_app/apps/services/random
When testing in other environments, the error does not occur.
EDIT: I just saw that, this service allows to get a key for encrypted cache. It allows to open it. Given that, the service is 404, I got a failure for opening cache.
Moreover, the Worklight Console gives me this URL for mobile web app:
http:/my-server:port/BMA_app/apps/services/www/BMA_app/mobilewebapp/
the app tries to get a key for encrypted cache and send to http:/my-server:port/BMA_app/apps/services/BMA_app/apps/services/random
^ 404 error
If we cut this previous url to http://my-server:port/BMA_app/apps/services/random, it works.
It seems that in the URL "BMA_app/apps/services" is repeated twice instead of once.
Why and how to resolve it ?
Looks like you may have encountered a defect.
Testing in 6.1.0.1 with the Encrypted Cache sample project and adding to it the Mobile Web environment, if you use the link provided by the "Get App URL" button - then when you try to "open cache" from the app, it will fail with status code 10. This status code means that the app was unable to connect to the Worklight Server's Random generator service.
Indeed, when inspecting the console log, the app tries to connect to the following URL, where "EncryptedCache/apps/services" is repeated twice...:
http://192.168.1.101:10080/EncryptedCache/apps/services/EncryptedCache/apps/services/random?isAjaxRequest=true&x=0.18816258828155696
There is no workaround for this defect as it is the framework that generates the URL.
I have opened a defect.
If you are an IBM customer or business partner and require a fix, you can open a PMR and mention this Stackoverflow question.
Moving forward, the fix will be available in an iFix and any future fixpack released.
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)