I am calling a public adapter procedure and have assigned securityTest="wl_unprotected" to it. If I call the procedure via URL, it works fine, but when calling from device/app then it's not working...
What could be the reason?
As discussed by email, the issue is not in the way the adapter procedure is being setup in the adapter XML, but IMO in the way the client-side code is handling it.
This question is not so fit to Stackoverflow...
Related
We are using WL.Server.invokeProcedure to call procedure between two Javascript adapters. Basically we are doing adapter mashup.
How Mobilefirst calls WL.Server.invokeProcedure procedure either GET or POST.
responseData = WL.Server.invokeProcedure({
adapter: "ServiceAdapter",
procedure: "storeDocuments",
parameters: [params],
});
The above code doesn't have method parameter. We are facing issue for large payload where procedure calling fails for large JSON parameter object.
Is there any other way to pass large payload.
When adapter mashup happens, adapter1 constructs a REST url of adapter2 and fires it. This call will reach adapter2 as if originating from an external client.
You can try out the JNDI property mfp.adapter.invocation.url and set a local url here , such that REST call stays internal to the system . This way the calls should execute faster and you should be able to carry more payload.
Set the JNDI property with a locally accessible URL including the context root.
For example:
mfp.adapter.invocation.url="http://localhost:9080/mfp"
Modify the value to suit your environment.
More details here.
When working with a large-sized data response from an HTTP Adapter, the size of the response appears to cause our challenge handler to fire a handleChallenge() method.
My question is, why would the size of the response cause the mobilefirst security challenge handler to fire, when the session is still valid?
More Details:
Our application uses an ISAM security appliance with Header based authentication. When an HTTP adapter call we make comes back with a content-length greater than 20,377, the adapter call triggers the handleChallenge() method of our challenge handler. When inspecting the response, we have seen that the responseJSON is actually populated with our required data, so really the handleChallenge should never have fired.
When we ping the adapter directly through the browser with the same parameters, it works fine. We've been able to isolate that this problem is occurring in the worklight.js / mobilefirst realm.
Does anyone have any idea if, or why, the Challenge Handler in worklight.js would not function as expected with a very large response size?
The bottom line is that it should. There is no reason for it not to.
If you have not been able to resolve this otherwise, my suggestion is to open an IBM PMR (support ticket) to have the development team investigate the issue.
We ended up ( sort of ) diagnosing it. At a certain payload size, the "/*secure {" fell off the response ( of which we're still not certain why. Our loginChallengeHandler function was based off of some example we found in some IBM documentation, and would improperly mark the response as a login form if the /*secure wasn't present. Once we tightened up the challenge handler, it worked.
I am facing to a trouble with 2 adapters based authentication. My app is agenda (hybrid app). All adapter's functions must be protected by security.
my app uses adapters based authentication, like written in samples on DeveloperWorks.
My first adapter (loginAdapter) is dedicated for login (beginning of the mobile app). I developed a handler (handlerLogin, mobile side) with methods isCustomResponse, handlechallenge, etc.. This adapter works.
This adapter allows to get a userId from login and password.
As soon as connected, the user can download his agenda. The mobile calls an other adapter based auth (calendarAdapter). I have an other handler (handlerCalendar) with methods (isCustomResponse, handlechallenge).
When the mobile calls the method getCalendarData (protected method, CalendarAdapter), the server detects that the user is not registered for this adapter, that is why the server send an error (structure authrequired + errorMessage) via the function onAuthRequired.
At this step, all works fine.
Actually, the trouble comes from, that, the first handler (handlerLogin) catches this error, whereas it schould be the second handler (handlerCalendar).
Given that it is catched by the handlerLogin, isCustomResponse and handlechallenge are called, and I do not have the expected result ! I do not know why.
Why it is not catched by the handlerCalendar ?
I verified my code, variable's names, files, etc.. All things are ok.
For informations, I first declared the handlerLogin before the CalendarLogin.
Do you have any ideas, suggestions ??
Thank you in advance
It looks like you used the same realm.
The isCustomResponse function job is to find out if this challenge-handler should take care of this specific request. If you use the same realm for both adapters then the 2 challenge-handlers will react to it.
I have an issue in a new devkit Project where the following #ValidateConnection method is failing to be called (but my #processor methods are called fine when requested in the flows)
#ValidateConnection
public boolean isConnected() {
return isConnected;
}
I thought that the above should be called to check whether to call the #Connect method.
I think it is because I am using a non default category (Components) for the connector
#Category(name = "org.mule.tooling.category.core", description = "Components")
And the resulting Behavoir is different to what I am used to with DevKit in Cloud connector mode.
I guess I will need to do checks in each #processor for now to see if the initialization logic is done, as there doesn't seem to be an easy way to run a one time config.
EDIT_________________
I actually tried porting it back to a cloud connector #cat and the same behaviour, maybe its an issue with devkit -DarchetypeVersion=3.4.0, I used 3.2.x somthing before and things worked a bit better
The #ValidateConnection annotated method in the #Connector is called at the end of the makeObject() method of the generated *ConnectionFactory class. If you look for references of who is calling your isConnected() you should be able to confirm this.
So no, you should not need to perform the checks, it should be done automatically for you.
There must be something else missing... do you have a #ConnectionIdentifier annotated method?
PS. #Category annotation is purely for cosmetic purposes in Studio.
Client code attempts to invoke adapter. This triggers authentication to the appropriate realm. It is possible that the user does not have suitable credentials and eventually wants to stop trying. I can provide a "Give Up" button, and we can use the challegeHandler to tell Worklight to stop the authentication effort like this:
this.challengeHandler.submitFailure();
This works to the extent that the login attempt terminates, but it seems that code calling the adapter gets no callback and hence any Deferred objects that might be waiting for resolution are left in limbo.
The question is whether we can arrange to get the authentication failure back to the caller of the adapter procedure?
I have been informed of a workaround to this issue whereby you call:
challengeHandler.activeRequest.onUnresponsiveHost()
Before actually calling:
challengeHandler.submitFailure()
This will trigger the failure and reject the deferred as intended.
This is a workaround though so it might not work in future versions. I am going to raise a request for enhancement (link pending) and I would appreciate it if you could vote it up as well to ensure this functionality is available in the future.
First of all, submitFailure() will not call adapter. It will notify client side framework that authentication has failed completely so the framework will dispose of any stored requests that are waiting for authentication to finish.
If you want to wipe user identity on a server side you have two options
create an adapter procedure which doesn't require authentication and call WL.Server.setActiveUser("realm-name",null). This will terminate any userIdentity.
call WL.Client.logout("realm-name") in your app