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
Related
It seems that in the Java SDK it is not implemented to delete Operations. The REST API supports it. So I'm wondering if I miss something or if this is the case.
Are there any workaround except using a REST Client to delete Operation(s) in a Java Application?
No, currently not (but feel free to send a pull request with an added method).
As background, operations should usually not be deleted by clients, but instead cycled through their process (pending -> executing -> successful/failed). If you delete an operation, it will be not available anymore and you cannot reproduce what happened on a device at a particular point in time. Deletion is usually taken care of by data retention management.
The easiest way to use an API that is not implemented in the client is calling the rest() method on your platform object.
This will return you the underlaying RestConnector for all API (fully initialised with credentials) and you can execute the calls with it (kind of manually).
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.
Is there a way to test if current user has been authenticated to BBG? I have my c# program which uses BBG API, and want to check if the user logged in the service before, either via API calls or the BBG Terminal. This check can then be used to distinguish whether the user's network is unavailable or simply he hasn't logged in yet.
Thanks!
There's a couple of ways to interpret your question, so I'll answer both... (I'm speaking from the perspective of using the Java API, but it should be pretty similar on C#.)
1. Can I tell whether the user connect to Bloomberg (i.e. are there network issues / are they are logged in)?
Yes - you can create a new Session, try to start it using .start(). If it fails or returns false, you cannot connect. If it starts, you can call .openService("//blp/apiauth"). Again, if it fails or returns false, you cannot connect.
If you cannot connect, you may or may not be able to determine why you cannot... Nevertheless, I would suggest registering a callback to the BLP API logging framework. In our code, we we-direct these to the logging framework we use throughout our code.
2. The user has created a Session (pre-cursor to a Service) - can I tell if the Session has been started?
Unfortunately - no. There is nothing in the API to allow you to determine the state of the Session. (I suppose you could try starting it, and if it starts it wasn't started, and if it fails, it was started - but that strikes me as an unhelpful or risk appraoch.)
I want to be able to notify the user if he entered the wrong username/password, or if for example the database is down. I am not sure if I need to do it in the didLoadResponse and just check that the response is not isOK or in the didFailLoadWithError.
Thanks
How you handle it depends on how you perform a login.
If you do basic authentication, by passing the username and password in the header of the request, then you'll get an error back from the service you're calling. And your delegate method, "objectLoader:didFailWithError:" method will get called. This method will most likely get called if there's a catastrophic problem on the backend, like the database being down.
If you have a separate webservice that performs a login operation, then it probably sends back a valid block, indicating whether the user-pass was valid or not. In this case, your "objectLoader:didLoadObject:" method probably got called, and you'll have to decipher the result appropriately.
Keep in mind that this behavior is totally controlled by what the back-end services do. If you can't talk directly with the people working on the services, then this may just be trial-and-error, and until you discover how those services work.