I am trying to invoke worklight adapter from external application. I also got the answer in Calling Worklight adapter from external app thread. However I dont want to send adapter name, procedure name and parameters as query params. Rather, I want to send them as payload inside request body. Pls suggest answers.
If you were using MFP v7.0+ you know that each MFP adapter is exposed as a REST API as well.
you just need to remove the security so external applications can access that REST API easily.
Not sure if its healthy to reduce security.
but you can mark the (via the adapter xml file) method as "wl_unprotected"
Related
After working with Oracle ADF for a while, I am now developing an application using Oracle Visual Builder. When calling REST services using the action chain component "Call REST", the call is visible in the browser console. (The services are added from the catalog, they are not defined by their specific endpoints)
Using Firefox's Inspection tools I can right click the request, edit it and resend it successfully despite the service using authorization.
In Oracle ADF I would simply call the service in a managed bean, the user wouldn't know I called it.
How can we not let the client/user know we called the service that in Visual Builder (or hide it from the console)?
Is there a way to call REST services other than the "Call REST" component in the Action Chain tools?
That's a key difference between the architecture of ADF that was running logic on the server, and VB that runs the logic on the client side.
Any web page that calls a REST endpoint (including from JS code) will show the REST call in the browser's log - this is not a VB specific behavior.
The security should be defined on the REST side requiring proper authentication to invoke the REST endpoint.
Maybe consider making the call from a custom JS function - and calling the JS function from the action chain?
Trying to identify worklight adapter requests from web server access logs, but all the requests look really generic. Any idea how to identify adapter requests?
The Request only contains "POST /Worklight/apps/services/api/MobileApp/android/query HTTP 1.1". I
can't see the adapter name nor procedure name.
while this query is indeed an adapter invocation , the adapter name, method and parameters are embedded into the POST HTTP message body. its not a big payload (less than 1KB).
I'm not an IHS log expert, but maybe there is a way to log also message body.
( I saw this un-answered: https://stackoverflow.com/questions/27354942)
However, if you upgrade to newer MFP version (v7.0+) then you can expose adapters as a RESTfull service. This will make the IHS logs much more clear which adapter was called (each one has different URL).
i have two small questions about the mobilefirst- Server.
I found out, that the mobilefirst (or Worklight)-Server doesn't support PHP.
(IBM Worklight 6.0 - How to include a PHP file?)
Is that still so? Or is there any plan to include PHP?
Then I want to call RPG's with an Java-Adapter.
But I doesn't find any full example for calling a RPG.
Also I want to call RPG's with a Display File. Is that possible?
In the following article it sounds like it is easily possible:
http://www.it-zoom.de/dv-dialog/e/vom-greenscreen-zum-touchscreen-10865/
IBM MobileFirst server sits on top of a WebSphere Java EE based App Server. The MobileFirst Platform Adapter pattern is a server-side layer that provides abstraction to any generalized end-point; including PHP, SQL, SAP, whatever. So as long as your final endpoint is capable of acting as a "service", accepting HTTP requests, and producing JSON/XML responses, this pattern should work fine. The basic flow is:
mobile app client calls the MFP adapter
adapter calls the final endpoint (PHP/RPG in your case)
Endpoint responds with JSON/XML data
Adapter optionally converts response to JSON
Mobile client app receives and processes (displays) a consistent response from the adapter.
Hope this helps clarify the pattern for you.
PHP is a server-side HTML rendering technology. MobileFirst is (partly) for building hybrid mobile applications, which run on the client (mobile), so PHP wouldn't be relevant.
I'm not sure what an RPG is. Please can you specify the acronym in your question?
I'm using MobileFirst 6.3. I have an adapter, which procedures should be accessed only from another adapter of my application, but not from the client. What kind of security test can I use for that purpose? I couldn't find any so far. Or maybe there is another approach?
Uhm, if you don't want your client logic to use an adapter - don't call the adapter in that client logic. Call the adapter only from another adapter...
There is no security to apply here.
I am using the client side API WL.Client.InvokeProcedure(invocationData, options, UseSendInvoke) in worklight 6. But I could not find a description for the parameter UseSendInvoke in the API. Do you guys know what it is?
This parameter is used internally by WL authentication framework. Technically there should not be a reason for developer to use it.
There are several ways to invoke adapters.
(1) First one is via client application. This is where you use WL.Client.invokeProcedure(invocationData, options) API.
(2) Second is by using adapter invocation service - http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fdevref%2Fc_adapter_invocation_service.html. Basically issuing an http request to WL server and getting a response from adapter. RPC style.
When you're doing it via (1) - you have two authentication layers - first is security test defined for application, second is security test defined for adapter procedure.
When you're doing it via (2) - there is only one security layer - security test defined for adapter procedure.
UseSendInvoke param (which is, once again, for internal usage) means that your application will go via path (2) instead of regular path (1).
There's no UseSendInvoke argument that WL.Client.invokeProcedure takes, at least not in the public API defined in the documentation. You can look at the documentation for Worklight v6.0.0, Worklight v5.0.6, Worklight v5.0.5 to learn more about that particular API.