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.
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?
To get started quickly with API Connect, I just want to import a Swagger spec of an existing service and make this service a managed API in API Connect.
API Connect provides an import function for YAML files, but the API can not be tested.
I've seen this scenario several times, so I though it might be useful to have some documentation on this.
When importing a swagger specification, you need to modify a few settings to transform this service definition into an API definition (even though they are quite similar). You need to modify the following parameters:
Schemes https - The Gateway enforces HTTPS
Host: $(catalog.host) - This variable links to the current host (in a certain catalog)
Then, you need to build an assembly. The proxy policy is well suited for building facades, as all content from Headers, Body, etc. is re-routed. For the URL, enter the URL of the endpoint + a context variable that refers to the incoming path, like:
http://example.com$(request.path)
I have created a small video on Youtube to demonstrate the neccessary steps.
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"
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 am using Cometd 3.0.1 with jetty 9.2.3 using JSR 356 based websocket implementation (and not jetty's own websocket implementation).
I have added some auth filters which basically ask for authentication headers from request. But as websocket upgrade happen as a part of websocketupgrade filter, is there a way to make authentication work here?
Authenticating via a Filter is the wrong way to accomplish authentication.
Correct Solution:
The servlet spec expects you to setup and configure the the authentication and authorization layers of your application using the servlet techniques of both the container and the application metadata (WEB-INF/web.xml)
This means you setup a the container side security, either using the Jetty container specific LoginService, or using a JAAS spec configuration. Then you reference your security realms in your WEB-INF/web.xml and use them. If you have something custom, then you can hook into the LoginService of your choice (even a custom one) and manage it accordingly.
JAAS and LoginService Authentication and Authorization is applied before all filters and servlets.
In this scenario, you'll have access to the authentication information during the upgrade process, in particular during the ServerEndpointConfig.Configurator.modifyHandshake()
Ugly Hack Solution:
Add the org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter to your WEB-INF/web.xml manually.
This then leaves it up to you to attempt to get your authentication filter to exist before this WebSocketUpgradeFilter in 100% of use cases.
Caution: filter execution ordering is not part of the servlet spec. Be careful with this, as it might seem to be working on your dev machine and then suddenly not work in QA or production. Simply because the Set of filters in the metadata will have a different order in it.
Notes:
Path Spec must be /*
Async Supported must be true
Dispatcher Types must be REQUEST only.
Do not set the contextAttributeKey for that filter
All other WebSocketUpgradeFilter init-params are invalid for JSR-356 use (they are overridden by the various JSR-356 endpoint configurations)