I configured an Api using API management service in Azure, all the endpoints are working fine, I defined some rules into the inbound policies, the last one is a set backend service rule. the objective of this rule is redirect the request to a diferent endpoint based on certain conditions. The problem is as follow: If i test the api endpoint inside the Azure,using the the Test option provided by API managemen service all the proceess works fine, i can see into the trace and check how the Api Management service recieve the request, check the conditions definen into the inbound policy and finally change the backend url to the right endpoint. If test outside the Azure, for example using postman, the API management service response an 500 error, the description of the error is: Expression value is invalid. Value is not a valid absolute URL. () Section : (inbound) Source : (set-backend-service)
I found the issue and the solution. The problem was generated in the policies configuration. For some reason the base tag in the backend policy was deleted. Putting back the base tag all the endpoints works fine.
Related
I have an xAPI content made by storyline I want for the statement to be sent to a webapp instead of the LRS.
this webapp is developped using laravel, and user should be authenticated with email and password to use it.
what I did to send the statement to this app:
1.in the webapp I created an API endpoint route that use POST method.
2.in the xAPI wrapper I changed the endpoint in the configuration to the route I made in the webapp.
const conf = {
"endpoint":"here I added my api endpoint route of the webapp",
"auth":"Basic " + toBase64(""),
}
now whith any interaction with the content where a statement should be sent the request making cors error like in the picture down, I think this is authentication error, how can I add my authentication credentials to the xAPI wrapper?
Your non-LRS LRS is probably not handling preflight requests which are necessary for CORS handling. Most common LRSs will handle those requests appropriately since they expect to be accessed from additional origins. See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests
Also note that you'll likely run into issues unless you also handle state requests.
Additionally unless you are requesting the credentials from the user during runtime then hard coding the credentials into the package isn't a great idea from a security perspective.
Salutations!
I have just completed my first REST API, deployed on heroku, and I decided it would be cool to make $0 a month through rapidAPI.
The rapidAPI testing dashboard passes the tests successfully - with one of their keys being a requirement for an API call.
However when I access the site on a browser or on Postman, there is no need for an API key and therefore no restrictions in get requests.
I have noticed that the test code makes a fetch request to the rapidAPI url for the project but how can I make the heroku url accessible only from rapidAPI?
I know it's extremely unlikely someone will find my heroku app url but it is technically possible.
I appreciate your time and insights.
RapidAPI provides 2 security features to support this:
set X-RapidAPI-Proxy-Secretin the API Dashboard: this token is added in the X-RapidAPI-Proxy-Secret HTTP header for each request. You should validate this for every API call. This is the default measure in place.
the list of IP addresses used by RapidAPI is provided: you can check/validate for every API call.
There might be Heroku Addon to help with the IP filtering, but those are typically enterprise-plugin (with associated cost).
RapidAPI allows you to add secret headers and/or query string parameters to API requests. The RapidAPI proxy adds these secrets to every request, but are hidden from the API consumers.
Find more details in this page: https://docs.rapidapi.com/docs/secret-headers-parameters
I have an API instance in AZURE where the configurations are as below.
API endpoint : corol.abpparking.domain.com
API suffix : myaboutpage
Backend Webservice URL : http://10.20.10.2:8080/api/v1/
What works
If i call the webservice URL directly as below for the operation GET to /about, i get response code 200
http://10.20.10.2:8080/api/v1/about
Response: 200
What does not work
If i perform the same operation via APIM, i get a 404 resource not found.
http://corol.abpparking.domain.com/myaboutpage/about
Response: 404 Resource not found
I could not figure our what could be the reason. Note that i do not have any basepath in the Swagger definition.
Make sure to check that your API in Azure APIM is configured to accept HTTP in addition to HTTPS. You can set this in API settings, on the same page where you set API backend URL
Whenever I try to add the following endpoint, "http://ws.cdyne.com/phoneverify/phoneverify.asmx", during the Managed API setup process and press the Test button I get an error on the server. ERROR - APIProviderHostObject Error occurred while connecting to backend : "stackOverflow preventing me from showing this link", reason: Connect to ws.cdyne.com:80 timed out
When I try this exact same process on a machine outside of our proxy it works fine. I have gone into the axis2.xml file and added proxy information and even went as far as installing cntlm and setting the proxy to localhost - same error.
I can browse to the above link just fine on this machine.
My environment is Windows 10.
I assume you talk about clicking the Test button when providing Backend Endpoint in API publisher.
The way that Test button works at the moment (as far as I understand) is that it invokes HTTP HEAD method on the endpoint provided (because according to RFC 2616, "This method is often used for testing hypertext links for validity, accessibility, and recent modification.")
Then it checks response. If response is valid or 405 (method not allowed), then the URL is marked as Valid.
Thus sometimes, if backend is not properly following RFC, you might get otherwise working URLs declared as Invalid during the test because of that improper HEAD response evaluation. Obviously, this is just a check for your convenience and you can ignore the check if you know the endpoint works for the methods and resources you need it to work.
So my advice would be to try ignoring the Test and just finishing setting up and publishing the API.
P.S. I am checking it on WSO2 API Cloud but behavior is identical to downloadable API Manager.
Is there standard way to change runtime permissions for a user to be able to call certain odata resources of a SAP gateway service, other than manually writing code in every service implementation method to check if the request is allowed?
For example, based on some setting in customizing, the odata paths below /foo and /bar for user x should be forbidden, i.e. HTTP GET/POST/DELETE <host>:<port>/foo/test and HTTP GET/POST/DELETE <host>:<port>/bar/test should yield HTTP 403 for user x, but HTTP GET/POST/DELETE <host>:<port>/something should be OK.
Is there a way where this can be controlled at a single place rather than being required to implement a check in every method implementing the odata requests?
The proper place for the authorization check is in the backend method. Any authorization error should populate back to the service and yield a 403 for example.
If you for some reason don't want that, you could write your own HTTP handler and insert it in SICF to be called on all paths.
The standard role setup only allows access or no access to a service, the "pattern" access you are referring to is missing. But I can't really understand why you would want it? It will make your Odata services kind of un-predictable for the consumer, wouldn't it?