I'm trying to use PAW to connect to the WooCommerce API over http. The documentation (https://github.com/woothemes/woocommerce-rest-api-docs/blob/master/source/includes/v2/_introduction.md) mentions that you must use OAuth 1.0a "one-legged" authentication to ensure API credentials cannot be intercepted". And it also mentions that the required parameters are: oauth_consumer_key, oauth_timestamp, oauth_nonce, oauth_signature, and oauth_signature_method. oauth_version is not required and must be omitted.
PAW's oauth1 always seems to includes PAW's oauth_version -- is there a way to to prevent this?
Unfortunately, I don't think it's possible. The oauth_version param is optional according to the spec, but servers should accept it, otherwise fall back on 1.0 if not present.
oauth_version:
OPTIONAL. If present, value MUST be 1.0 . Service Providers MUST assume the protocol version to be 1.0 if this parameter is not present. Service Providers' response to non-1.0 value is left undefined.
http://oauth.net/core/1.0a/
As I think Paw should be more flexible than that, we will add an option to explicitly disable some parameters in a future version.
Related
I try to implement a one time none for HTTP digest authentication process. First of all I'm aware of the fact that the authentication is not perfectly secure. Please do not tell me to use something else. The authentication process is working as expected. When the user authenticate successfully I append a http Authentication-Info field with the next nonce. The browser in this case Firefox is not using this nonce for further requests.
Authentication-Info: nextnonce="06e8043d3fb8c26156829c4b55afd13040"
Why is the browser not using my new nonce for future requests? It still uses the old now invalid one!
RFC7616 describes the header field.
https://www.rfc-editor.org/rfc/rfc7616#section-3.5
The value of the nextnonce parameter is the nonce the server
wishes the client to use for a future authentication response.
The server MAY send the Authentication-Info header field with a
nextnonce field as a means of implementing one-time nonces or
otherwise changing nonces. If the nextnonce field is present, ...
RFC2617 describes the syntax in section 3.2.3
https://www.ietf.org/rfc/rfc2617.txt
[Edit]
Is it possible that firefox is not supporting this feature. If I search here
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate
for the header field I can't find a result.
But it is listed as standard header flag here:
https://www.iana.org/assignments/message-headers/message-headers.xhtml
nextnonce is not supported in Firefox, not even Authentication-Info header.
The bug "next nonce digest auth test fails" was opened 18 years ago and it's still not fixed yet.
I downloaded the source code of the latest Firefox version 65.0.1 and searched the project. "Authentication-Info" only appears in netwerk/protocol/http/nsHttpDigestAuth.cpp as a comment, nowhere else.
My endpoint method generates a different response for each invocation regardless of the parameter list. I often see my client call the endpoint with the same parameter list, and the front end instance returns a cached response.
In the official documentation I read that ApiMethod#cacheControl has been deprecated. On the other hand, the documentation says that the #Api-scopped annotation #ApiCacheControl has not been implemented yet so adding the following makes no difference.
cacheControl = #ApiCacheControl(
type = ApiCacheControl.Type.NO_CACHE
)
To make things easier, the documentation also says that
public #interface ApiCacheControl
Annotation for API cache control configuration. Note that the API frontend itself may act as a caching proxy.
Given the current state of the API what's considered best practice for enforcing cache control?
I don't understand how to create a custom report based on a StatisticsCollector Policy.
I want to retrieve statistic about my API being called from different clients by checking the content of the request header called "referer".
As from the doc, I created a Statistic Collector Policy, adding it to my pre-flow.
Trying to create a variable named "referer" looking at the request header "referer", I added
<Statistic name="referer" ref="request.header.referer" type="STRING">undefined</Statistic>
to the policy.
Now, as I can understand from the doc, I should found, while creating a "Custom Report", a not-better-specified "Dimension" called "referer":
"You will find that a new dimension called location is available in the UI for you to use in generating reports."
I can't find such dimension while creating a Custom Report.
I find a Custom Dimension called "name", and I have no idea where does it come from.
How am I supposed to do it? Should I try to do it by calling Apigee API?
EDIT: Apparently, the Statistic Collector does not work for free organizations on Apigee because of a "tech glitch". Srikanth from Apigee intends to open a ticket for solving this. If this is not the case, another request to update the documentation on Apigee, stating that the Collector does not work for free org, will be raised by Archendra Yadav.
Here the few things to note.
Browsers are very careful about Referer headers. They do not send it even if you set them. Even Postman client on chrome does not send the Referer header when specified. This is a valid security gate - HTTP 1.1 RFC talks about it. You can read about the same behaviour in other places on web.
So as Divya mentioned use curl request. Use the trace session to figure out what was the original request received by Edge from client. This way you figure out the existence of the referer header. You will see that its missing when sent from browser manually. Curl works fine.
Are you using a free org or paid org on Apigee. The statistic collector fails to work on the free org at times. I had a chat with an internal expert who gave me this insight.
Emas -- Thanks for the suggestion. I'll raise a request with documentation team to update the documentation accordingly.
The field referer will be added under Drilldown --> Custom Dimensions after you send some requests to the API where yyou have added the below statics collector policy.This policy needs to be executed once to add the new field to the Custom dimension
You say that you are using the following:
<Statistic name="referer" ref="request.header.referer" type="STRING">undefined</Statistic>
I believe the type is case sensitive. Try type="string" and see if that works.
The request header name is 'Referer' and not 'referer'.
So, your StatisticsCollector policy should look something like this :
StatisticsCollector-1
request.header.Referer
Try some calls and make sure the request has a header named Referer. Then it would come up as a Custom Dimension in your custom report.
For me I had to explicitly mention the Referer header in my request like this :
curl -v "https://product-support-test.apigee.net/" -H "Referer: foo"
Please send me your bundle if you still face issues(divya#apigee.com).
I am writing a client for OpenTox webservices, but several services they provide have optional support for certain MIME types with only a few obligatory, e.g. this Dataset service. So I need to discover which of those content types are supported by a particular running service dynamically...
Now, for GET services I can use the "Accepts" HTTP header and when I POST content I can use "Content-type" to set what format I am sending in. But I rather not default into trial-and-error, as these data sets can be large. Therefore, I like to know up front the best MIME type I can use.
How do I perform content negotiation with POST services? I am using the Apache HttpClient, but that is not important for the answer.
POSTed Content negotiation is not enshrined in the HTTP specification; instead what is advisable is to use the OPTIONS method. This is exactly the case in the OpenTox framework: OPTIONS has to be implemented by all web services. The service returns an RDF document (according to the Accept Header you specify) and a WADL-like content, i.e. it returns machine-readable documentation specifying the available MIME types, the possible HTTP status codes etc. Unfortunately so far there's only one implementation of OPTIONS in OpenTox, namely JAQPOT3. Check out this wiki entry.
I have a REST api that will accept a version via a custom HTTP header or a request parameter. I'm doing this because I don't want the URI to contain the version like del.icio.us .e.g http://server/api/v1/...
Now in my design, the HTTP header has a higher priority than the request param.
What happens then if the user does not supply any version at all ?
Should I default to the oldest version, or default to the latest version ?
Don't version the URI at all. Instead just version the representation. This way the client can decide which version of the API they want to use and it degrades well.
Example:
GET /contacts/3 HTTP/1.1
Accept: application/myapp-v2+xml
HTTP/1.1 200 OK
Content-Type: application/myapp-v2+xml
Why not simply make the version required and throw an error if it's not there?
If that's not an option then you have to go with the oldest version, otherwise if you upgrade and don't maintain backwards compatability you'll break existing clients.
Of course, if you don't mind breaking existing clients it might be more convenient to go with the latest version.
If your API defines specific URIs or URI naming conventions for accessing resources, your API is not RESTful. Versioning of URI construction is a non-issue for any REST API. Please see http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven for more information.