I have a rails client-server app that also needs to get some data from an external api with a authentication token. The authentication token is stored on my rails server.
Basically want I want to do is: when a user triggers a get request from my client-side to my server-side, I get some data from my database on the server and I want to get some data from the external api en send both sets of data as a response back to client.
But I'm not sure if it's a good Idea to send a get request from another get request like that.
Is that how this is typically done or is there a better way?
Create an ActiveJob job with the GET request to external API.
Have your client's GET request to trigger the job.
Collect all the data you need and send response back to client
Related
I am trying to build a Custom Connector in the Power Platform to connect to the BMC Helix (formerly Remedy) system to create work orders and such. I am using OAuth2 and was given a callback URL, auth URL, token URL, client ID and client secret.
I went to create a connector from scratch. I populated the fields, but I wasn't sure what to put for the 'Refresh URL', so I used the token URL there too.
I am trying to accomplish testing this connector and my successful test would be to get a JWT from doing a POST to the /api/jwt/login endpoint of BMC Helix. It should return a JWT which I can use to make subsequent calls.
Upon testing this, I go to create a connection, but a window opens (which I believe should be a prompt for authentication), but instead it contains an error saying 'unauthorized_client' coming back from the BMC Helix system at the /rsso/oauth2/authorize endpoint. It also contains a property within the URL of redirect_uri = https://global.consent.azure-apim.net/redirect.
Is there something on the Helix side I need to further configure? Not sure why I am getting this....
It sounds like you need TWO METHODS in your connector. A POST to call the token server, a GET (or another POST) to call the API (using the token received from Call 1).
One approach I've successfully used in the past is:
Use Postman to get your token server call working with OAUTH
Then use Postman to get your subsequent API calls working with the token appended
Save both requests to a single Postman collection
Export the Postman collection (as a V1 (deprecated) if I recall correctly)
Import this collection into PowerApps Custom Connector (create new/import from Postman Collection)
You'll have to massage it a bit after import, but it will give you a good headstart and you're starting from a known-good place (working Postman calls)
Good luck!
In my web application i am using signalR. SignalR connection is using the longpolling transport, which is making the POST request to the server and passing parameters in the query string.
Now i scanned my application using the IBM app scan tool. The test manipulated /signalr/poll request's Method from POST to GET and executed the manipulated required on the server. Server responded same in case of both GET and POST verbs for same request. So tool reported this request vulnerable because responses are identical.
So how can i restrict on the signalR HUB server to accept this request only using POST method?
Below is the requets:
Original Request
Manipulated request
I know it is a basic Question. Does a POST Json Request for update in User interface actually Post data in to database or just simulates the load for Post data without actually posting in database. But can someone please clarify
An HTTP Post request with the mandatory body (can be parameters, JSON, XML etc.), is intended to upload the data into server (upload images, Sign Up etc.), or to post data which server wants (to validate Sign in etc., not necessarily insert into the DB). So, it is basically how Server treats the data and the purpose.
If server puts the received data into the database, when performed the action using the browser, then the same operation expected when performed through JMeter also irrespective of the type of body data (JSON, XML etc). So, If you post the JSON data, it must be inserted into DB.
In DB, One thing to note is that server, either can directly dump the JSON data as JSON type itself or parse the JSON data and take the required values and store them in the Database. It depends on how the server is implemented.
So, how the server is implemented, it should behave the same way, whether you send the request from the browser or JMeter.
It depends on implementation. From JMeter's perspective API endpoint is yet another URL, JMeter sends a request to it, measures time between request and response and marks result as passed or failed depending whether HTTP Status Code is below 400 or not.
So it is up to you to check:
What does API endpoint actually do
What is correct request syntax (mandatory arguments, headers, cookies, URL parameters, whatever)
What is the expected result.
Optionally, what happens if "bad" request is being sent.
When designing a JMeter test always run it with 1-2 users and View Results Tree listener enabled to ensure that it does what it is supposed to be doing.
Coming back to your question: if HTTP response code is below 400, JMeter will mark sampler as successful, it won't check response body or database so I would recommend using the following test elements for confirmation:
JDBC PostProcessor - to check whether database was updated as a result of the request or not.
Response Assertion - to check that API response doesn't have errors, status code, variables, returned from the database, etc.
We have existed API like
/api/activiation_code
each time, the activiation_code will be different, then server will create a token for this call and return it, usually each call will have different activiation_code which return different token.
Since this API need server to create something so it is designed as POST.
Can we design this API as HTTP GET ?
What is the pro and cons ?
You could design the API to support GET requests, but I would not recommend this. If your API is accessible via a website, a user could accidentally activate an account multiple times since the URL will be stored in the browser's history. Additionally, web crawlers could potentially supply values to your API through the URL if you support GET requests.
POST requests are much better because the information is included in the body of the request, not the URL. Thus, it is much less likely that something will go wrong accidentally.
I'm starting an iOS app that consume a Restful API.
I have control over that API and I'm confusing with the caching policies.
To begin, I only need caching a concrete resoruce, but the problem is that resource can change when I insert new record in the database.
Then, how can I tell to the application "Hey! Make the request only if there have been changes and if not, you get the data from the cache!"
I'm using AFNetworking to make requests..
You'll have to make a decision on either server or client side and build your own protocol.
Example:
You could send the server JSON post request which contains the 'version' of the data you have in the app. On the server-side you will increment the version number each time the data gets refreshed. If the version number does not match at server-side, the server will respond with all new data, else the server responds JSON with 'up to date'
EDIT:
If you are looking for an HTTP response saying that the data is not modified. This is done on server side. You'll have to implement this in the server.