Using the IBM SBT, one can easily register and endpoint to connect to IBM Connections Cloud. That way it is easily possible to access the APIs provided by IBM Connections using a local URL that is then proxied to the cloud.
Usage can be done using the provided JavaScript or by just requesting a resource from the locally provided endpoint that is connected to the cloud. While this appears to be working for the vast majority of the documented APIs, it does not for the OEmbed API.
Example: If you have a local Java App Container (like IBM Websphere Liberty Profile) that is running a testapp and has a configured endpoint to your Connections Cloud Organization, you may ask that endpoint to retrieve the users profile service document by requesting: https://localhost/testapp/service/proxy/localhost/profiles/atom/profileService.do.This will retrieve the very same resource as you would receive if you request https://apps.na.collabserv.com/profiles/atom/profileService.do directly.
Other APIs work similarly. Unfortunately the OEmbed API does not. That means, if one would request https://apps.na.collabserv.com/connections/opengraph/form/anonymous/api/oembed?maxHeight=180&maxWidth=180&extended=true&url=http%3A%2F%2Fwww.ibm.com the server returns some JSON as described in the spec. In the same seting as above, a call to https://localhost/testapp/service/proxy/localhost/connections/opengraph/form/anonymous/api/oembed?url=http%3A%2F%2Fwww.ibm.com&maxHeight=180&maxWidth=180&extended=true should return the same result but isn't. Instead the server returns an Error 403: SRVE0295E: Error reported: 403 with a HTTP Status 403.
The response is by the way the same result as one would get if he was trying to use the direct URL unauthenticated against the cloud.
Is there anything that needs to be configured in order to use the OEmbed service via SBT?
Related
I have come across a challenge for that I need your opinion. We have a Front-end app in Vue that is publicly open and doesn't authenticate users through Login, the app doesn't have a backend. Currently, the app has a JSON data file that we manually update monthly. Based on my research and knowledge I have come to the conclusion, we can't put our SOAP web service endpoint with credentials since everyone will see the service user name and password in the browser. Even though the data is publicly displayed on the app but we want to secure the SOAP web service endpoint and credentials.
Currently, I only see two options:
We build the backend and authenticate(Login) the user in the app.
Build a backend (Node and Express server with Loopback) that consumes that SOAP service and converts that data in JSON format and consumes that data through Publicly open REST API endpoint with Read-Only option and only allow frontend app IP or Address to request data and reject the other IP request.
Both methods require the backend to secure the SOAP endpoint but the second option reduces the frontend work since it will convert the data from XML to JSON, my concern with this option is that it will be an open endpoint in REST API, can that jeopardize the SOAP credentials?
This is the Loopback diagram converting SOAP to REST.
I would like to know if anyone else has another idea or option to resolve this or do you see a problem with the above methods.
I am looking into developing integrations for the Acumatica Cloud ERP. I am developing a SaaS product on Azure which extracts accounting data from various sources. From the documentation provided by Acumatica, I can see that the API connects to a local instance of Acumatica. If I were to connect to a local instance I would need to use some sort of gateway which connects to a local machine. I also had to install a local instance myself to be able to create a client application and use OAuth 2.0.
I am having issues to understand how to create integration with Acumatica.
Do I need to know the instance name / URL of each of my clients? Do I need to have a local instance running to be able to use Acumatica APIs? Can client Acumatica instances be publicly accessed? If the client using authorization code flow, authorizes my application to extract data from Acumatica, what is the Acumatica ERP URL that I should be using? Mine or the client's? The documentation always uses localhost to connect to an API.
If you use any of the Apis provided by Acumatica:
Contract Based REST (Recommended)
Contract Based SOAP
Screen Based SOAP
You only need the a set of credentials and the URL of the site to communicate with it from the outside. By set of credentials I mean that the credentials that you use need to be able to access and perform the appropriate action on the Acumatica screen that you want to integrate with.
You can find more information on how to do so on the help web site at the following link:
https://help-2019r2.acumatica.com/(W(12))/Help?ScreenId=ShowWiki&pageid=ff22837c-cd3a-410e-b768-88ca6e53b165
It is the Development Integration Guide
Edit
Since you are mentioning Authorization Code Flow in the comment, here is the link that contains more information
https://help-2019r2.acumatica.com/(W(14))/Help?ScreenId=ShowWiki&pageid=ff780860-09c2-46c9-bdd7-c6c3b1fc442c
On that screen you will see the following information:
After the user is authenticated in Acumatica ERP, the client application receives an authorization code, exchanges it for an access token, and then uses the access token to work with data in Acumatica ERP.
Which means that even if your application does not handle the user credentials, the users will need a set of credentials in order to connect the application to the Acumatica site. The user used here will defined the access rights that the application has.
Cloud Connection getting error on Azure, Rest API & Callback API Configuration trying to make but not connecting on it giveing error
Welcome to Stack Overflow! There are a couple ways to call REST APIs in Azure. There is a neat video that explains how to do this via Postman here. Also ensure that the access token being used for Authentication is a valid one in the Authorization header. Refer to this doc to understand the right format.
Need some help :) I have created a simple AWS API Gateway with a lambda backend just for trying it out. The only response is { "date": "2017-01-01" }, and the only method accepted is GET. When I test the API in the AWS Console it works fine. The response is as expected. But when I try to access it externally I get an Internal error message response. It kind of blows of course. Do I have to setup a elastic IP for this to work? I shouldn't have to add any roles to the API Gateway (I assume) since the role only declares what resources the API Gateway should be allowed to access? Or is there a "external access" role of some kind? Ot do I have to provide any HTTP-header when accessing the API?
Please enable CORS if you accesing API from an external domain. Please see the screenshot below, which shows how to enable CORS
I am building a webpage to be embedded as an Iframe App within Connections Cloud. It is based on the principals from this tutorial.
The webpage will be hosted on a server outside (of course) the collabserv.com domain. The purpose of the webpage is to interact (read/write) with Connections Cloud, using the SBT SDK, on behalf of the current Connections Cloud user.
The user is already authenticated with Connections Cloud, so I would not like there to be an extra login every time the Iframe App is loaded (making calls to Connections Cloud).
Since my webpage is located outside the Connections Cloud host/domain, it's not possible to reuse the user's existing authentication with the Connections Cloud server (?).
Any suggestions for solutions or workarounds?
BTW, my webpage will be hosted on a Domino server, but ideally there will be no user accounts on this server.
I was able to establish an authenticated connection with Connections Cloud using OAuth2. I more or less followed the OAuth2-steps described by Paul Bastide in this article.
All operations from start to the point where "code" is returned, are handled with XPages, reading QueryString for parameters etc. From that point (starting with "Open a Terminal Window" in the article), I programmed a Managed JavaBean that handles the rest of the OAuth-dribbeling.
When the access_token finally is received in my JavaBean, I use that to build a "Bearer authorization header" for an Apache HttpGet object. I then use the HttpGet object to query the Connections Cloud REST APIs.