Assume I am a client accessing the REST API exposed by a website xyz.com.
Now when I make a call to their REST API I need to find out what are all the internal APIs they are accessing.
For example, xyz.com/users/id may be internally accessing xyz.com/users/id/info.
To explain this better, consider the Chrome -> Network tab(XHR). You can inspect all the Rest APIs that are invoked. Is there any such tool or API that is available?
Understand that I don't have access to xyz.com related code, server, logs and deployment.
Thanks
Related
Can the namespace preferences and program preferences be set via REST API calls? If yes, what is the syntax for it?
Generally in Cloud Data Fusion, when we intend to perform the action on GCP side, like create/delete/restart etc. instance, it's feasible to use domestic Google Cloud API, giving the opportunity to interact with a service endpoint via JSON/HTTP calls interface as described in Google Cloud API design document.
Dedicated to Data Fusion you can follow the Cloud Data Fusion REST API reference document, nicely explaining the methods for composing REST API HTTP calls to manage Data Fusion instances, moreover every method description from the documentation contains Google API Explorer sub-panel, to get handy experience building JSON request on a live data.
Said above, I assume your initial question is related more to CDAP REST API, as it includes the methods for pure CDAP instance metadata/namespaces/application configuration.
From the user perspective your workflow might be the following:
Identify the CDAP API endpoint as explained in this guideline;
Compose an HTTP PUT/GET request relevant to Data Fusion
Namespace/Metadata/Preferences/Configuration
object via CDAP RESTful API.
Yes of course! You have two methods.
The first method is creating it from the platform. Follow the steps below:
Open your data fusion instance
Go to System Admin => Configuration => Make HTTP calls
To create a namespace, submit an HTTP PUT request:
PUT /v3/namespaces/<namespace-id>
Link of CDAP: CDAP
The second method is using terraform.
I'm building a React.js application that will interact with my REST API built in Go.
React will use Javascript Fetch API to send requests to my API.
The problem is I would like to secure my API from being requested from elsewhere. No one should directly be able to access my API either through the URL or through any other client like Postman.
I know what JWT is but this does not solve my problem because anyone can access the token through the browser and then continue to request the API outside the React client using the token.
I have researched extensively but nothing has really fit my description.
Thanks a lot for you help, in advance.
This is an inherently unsolvable problem. React runs on the client. The client controls the code that it executes. Hence, any mechanism you use to restrict the API usage to just your React client will be discoverable and reusable in other client contexts. You cannot control the client, and attempts to do so will be broken if the payoff is valuable enough.
You can attempt to harden it somewhat by using short-term authorization tokens, but there is nothing preventing that token from being grabbed and reused in another context.
If you have to restrict access to an API, you should have a public API which is less dangerous or privileged, and the public API should make use of your private API, effectively proxying the calls to hide the private API, as well as to ensure that only validated queries are executed against the more privileged API.
If you could describe the problem you're trying to mitigate, though, there may be other solutions available.
I am developing a web application with Spring Boot and a React.js SPA, but my question is not specific to those libraries/frameworks, as i assume reporting client-side JS errors to the server (for logging and analyzing) must be a common operation for many modern web applications.
So, suppose we have a JS client application that catches an error and a REST endpoint /errors that takes a JSON object holding the relevant information about what happened. The client app sends the data to the server, it gets stored in a database (or whatever) and everyone's happy, right?
Now I am not, really. Because now I have an open (as in allowing unauthenticated create/write operations) API endpoint everyone with just a little knowledge could easily spam.
I might validate the structure of JSON data the endpoint accepts, but that doesn't really solve the problem.
In questions like "Open REST API attached to a database- what stops a bad actor spamming my db?" or "Secure Rest-Service before user authentification", there are suggestions such as:
access quotas (but I don't want to save IPs or anything to identify clients)
Captchas (useless for error reporting, obviously)
e-mail verification (same, just imagine that)
So my questions are:
Is there an elegant, commonly used strategy to secure such an endpoint?
Would a lightweight solution like validating the structure of the data be enough in practice?
Is all this even necessary? After all I won't advertise my error handling API endpoint with a banner in the app...
I’ve seen it done three different ways…
Assuming you are using OAuth 2 to secure your API. Stand up two
error endpoints.
For a logged in user, if an errors occurs you would
hit the /error endpoint, and would authenticate using the existing
user auth token.
For a visitor, you can expose a /clientError (or
named in a way that makes sense to you) endpoint that takes the
client_credentials token for the client app.
Secure the /error endpoint using an api key that would be scope for
access to the error endpoint only.
This key would be specific to the
client and would be pass in the header.
Use a 3rd party tool such as Raygun.io, or any APM tool, such as New Relic.
Our organization has a data collection on their servers. A soap API has been implemented and the data can be accessed using the WSDL on SOAP UI. I am a front-end developer and when I make a POST request using XMLHttpRequest to get the query result, it throws CORS error: "Response to the preflight request doesn't pass access control". It is NOT possible to enable CORS on the data collection servers. I am using Liferay for the website front end and the back end.
Any suggestions how I can get the query results from the front end without enabling CORS on database servers(this is different than the Liferay backend server)? Or I can use a website backend to interact with the database? Or use third-party services like Kinvey?
I have had similar issues in the past. Like you, I wanted to create a basic webpage on my machine and that contained some Javascript to call an API. With this approach, I got the CORS issue you are seeing.
I then hosted my page on a web-server and I still got the CORS issue.
To resolve, I had to create a web app, which I wrote in Java. This back-end contained its own API. One of the resources in 'my' API was a simple wrapper to call the API of interest. I then modified the webpage I wrote (now all hosted in the same web app), to call my API, which in turn calls the API of interest.
I know how to implement token based security via OAUTH to protect the access of an api. I also know ho to use HTTPClient to call an api.
But when I search/google how to use OAUTH calling a web api from a web api all it shows me is how to implement token based security for an web api (which I already have).
In my scenario I have an UI calling web api 1. After that I have to do some server to server communication: web api 1 calls web api 2 and web api 2 calls web api 3. Web Api 3 does something & returns to web api 2 which then does something based on success or failure, then returns to web api 1 (which does something) returning back to the UI.
(The reason for that intended implementation is storing (different) data in 3 different databases where I currently do not want (and later maybe not be allowed to) grant web api 1 direct access to them.
I am just unclear how I would manage the tokens (I don't want to request them every time, so I guess I will need some kind of service handling that and keeping them).
Any hint I could get the authorization (token handling) done?