I need to implement GraphQL access for a third party (Zoho subscription) that has a certain webhook implementation I can not change.
The call-authentication mechanism consists of arranging parts of a request (query string and body) into a certain string, calculate a hash value using a certain algorithm, and verifying that against the value provided in a call header.
When implementing it in GQL
I know how to access header values.
I don't know how to access request properties like URL query string or body in a string form. Web search didn't come up with anything useful.
Anyone know whether accessing the request object properties in GQL is possible? Any links?
Related
I want to retrieve data from a data warehouse that has a web-based API, I need to use an API key for authentication and use the GET / Customers command to retrieve the list of customers data, but when I am using that same thing in postman, it's returning the same documentation page of the data warehouse?
I am new to this any help will be really appreciated.
The URL doesn't look valid:
You need a base URL, endpoint, http method, authentication scheme, and credential or a token etc.
I don't know details about your system and API, so let's see an example:
base url is https://stackoverflow.com; your current base url is localhost:4444, is your server running on your machine? If so, it might be correct, but I assumer you're talking about a server running somewhere else, not on your computer
endpoint (path parameter) is /questions/69883697, in your case /customers
http method is GET and you find it here in Postman; it also means it will not go into query parameters where you put it:
authentication scheme - your docs mentions an api key that goes into a header called Authorization, so you have to set it in Headers, not as a query parameter:
Read carefully what's on your screen, Postman uses the same language as your API documentation, so if your doc speaks about headers, you need to go into Headers tab in Postman.
I have an application backed by RESTFul API. The application have user management section through which an admin user can manage other users. One sample URI for one of the API operation endpoint is below.
Update User : POST https://example.com/api/users/user1
Here user1 is the Username of the user being edited by the admin.
Suggestion from the security side is to remove the username from the URI since it is sensitive info and since it is part of url it will be recorded in network logs. Solution suggested is to pass the username data in POST Request Body .
Moving the data to request body is fine. But if I remove the username from URI ,the URI will be like "**POST https://example.com/api/users**" . This clearly doesn't look like a valid REST URI. And my USER entity doesn't have any other unique property which can be used in the URI.
Is there any recommended way to form a proper REST URI in such a scenario ?
POST /api/users
This clearly doesn't look like a valid REST URI.
Sure it does.
REST doesn't care what spelling you use for your resource identifiers, so long as the spelling is consistent with the production rules in RFC 3986.
That said, there's no particular reason that the identifier for a document needs to include sensitive information.
There are a couple of possible solutions - if the client and the server both know the sensitive data, then you can use a hashed value, rather than a raw value, as part of your identifier.
That's not ideal: we have mechanical ways of communicating URI that accept parameters, but no standard that I know of for communicating that some value should be hashed first.
If code-on-demand is an option, you might be able to manage to instruct the general purpose client to hash the data before sending it.
Otherwise, I think you are reduced to communicating the hashing out of band -- imagine a web form that instructs the human being to type in the hashed value of the sensitive information.
REST is optimized for the use cases that it was optimized for, and that means that some other use cases are more clumsy than we might like. Hooray for trade offs.
One way is to use an "id" instead of "username":
https://example.com/api/users/{id}
where "id" is usually a UUID https://en.wikipedia.org/wiki/Universally_unique_identifier
I've built a small api.
I Would like to implement header authentication for my api.
When user want to access my api he will send his apikey along with the api url. If the apikey was in my database then he will be given access, if not he can't access the api.
if you want to authenticate a single method
then you can look for the header directly in the method itself. something like
#GET
public Response processRequest(
#HeaderParam("X-APIKEY")
#DefaultValue("INVALID_OR_GUEST_KEY") String apikey , ...)
if you want to establish this for -all- (or most) of your methods, then you are better off with a filter. Take a look at http://www.dropwizard.io/0.9.2/docs/manual/core.html#jersey-filters and http://www.dropwizard.io/0.9.2/docs/manual/core.html#servlet-filters .
You can implement your key lookup logic in there
(PS you may want also to consider caching them, but that's another story).
Imagine we have a REST service that has a resource, that contains a password (or some other sensitive information). Once the password is set, we never want to return it through API (after it is set, only some external system will use it, we may be storing only hash of the password, etc).
So we have a PUT/POST request that sends in a resource with a password. What should GET request return? I could think of few possible solutions:
GET could return same resource, but without password field (Feels
strange, since password is a valid field for PUT/POST, so why not
GET)
GET could return resource, but with the password field empty or
set to some arbitrary value.
Have password removed from resource, and have a child resource.
e.g. resource/password, to which we can PUT password, but on which there is not GET request allowed.
This seems like a fairly common problem, but I cannot seem to find a good, standard way to solve it. Most of the search results point to actual passwords for users accessing the API, and resetting those, which is not the case here. Is there common, well-established way to handle this case?
You can POST/PUT data and not return it in the response or in a GET.
My choice would be #1 Return the resource without the field.
Also ok to use #2 and obfuscate the field.
I'm trying to search Netflix through their API, but without logging anyone in (because I want to do this on the back-end, not necessarily related to any user action). I'm just starting off with their API so please forgive me if I'm doing something completely stupid. Here's the URL I'm trying to access:
http://api.netflix.com/catalog/titles/?oauth_consumer_key=MY_CONSUMER_KEY&oauth_token_secret=MY_SECRET&term=fight+club
However, that gives me a 400 Bad Request error. Is there no way to browse/search the Netflix catalog without having a user first sign in to my application? Or am I doing something wrong?
Note: I'm accessing said URL through my browser, since I only want to perform a GET request, which is what a browser does by default.
When using OAuth you need to compute a signature for the request, even if you're using 2-legged authentication which just uses your shared-secret and no user token (this means that your application is logged in, but no user is logged in).
If it's an HTTP (as in non-SSL) URL then you need to be using the HMAC-SHA1* signature method rather than PLAINTEXT because you don't want your consumer secret being passed across the wire in plain text.
If they allow an HTTPS URL then you can use the PLAINTEXT method, but you'll still need to calculate it as per https://datatracker.ietf.org/doc/html/draft-hammer-oauth-10#page-27 and pass that as the oauth_signature query string parameter instead of passing oauth_token_secret. Note that you'll also need to pass oauth_signature_method=PLAINTEXT as a parameter too.
Also, it might be worth looking at the response that comes back. If they implement the OAuth Problem Reporting extension then that could give you some help with what's wrong.
*or another method that encryptes your shared secret