I installed dredd - API Blueprint Testing Tool and trying to test our APIary API against the implementation.
In the blueprint I have just one resource which is correctly implemented on somehost... but test fails :(
test command:
dredd apiary.apib http://somehost.de:8443/imp-endpoint
output:
Info: Beginning Dredd testing...
undefined
I tried also with more options to get more information what is undefined.. like -l verbose and some other options. But I did not get more information about the failure :(
Does anyone have experience with it? Thank you!!! :)
Answered on Github but I'll reproduce the main points here for reference:
I wasn't able to to reproduce your "undefined" problem, but there are a few issues that, when corrected, make everything work.
At the moment, the base url can't have a path in it (see #43). This is solved in #45 but hasn't yet been merged. So your command should be 'dredd apiary.apib http://somehost.de:8443/' and then '/imp-endpoint' should be a prefix on the urls.
The URI template is incorrect in your apib file. Instead of /api/V0/Resources/CarSharing/Cars?{lat}&{lng}&{radius}, it should be /imp-endpoint/api/V0/Resources/CarSharing/Cars{?lat,lng,radius}. See RFC6750 for reference.
The line-endings should be Unix style, not Windows (\n, not \n\r). When I first ran the apib you provided, I got the error: the use of carriage return(s) '\r' in source data isn't currently supported, please contact makers (this is actually enforced by the blueprint parser, see snowcrash)
Hope that helps! I get a 401 when running the test, so you'll need to provide HTTP Basic authentication information (this can be done in the header section of the blueprint or with the -u flag on dredd, as in -u username:password)
Related
I'm integrating SagePay Server and am stuck at step 4 here: https://developer-eu.elavon.com/docs/opayo-server/taking-payments
I get this error: Server error 5006: Unable to redirect to Vendor's web site. The Vendor failed to provide a RedirectionURL.
I know there are quite a lot of suggestions for this error out there. That it basically means there is something wrong with your code on the Notification URL.
I know it is completing the previous steps fine (I get the correct response parameters), I have made sure Opayo's IPs are allowed, the MD5 signatures match.
I think the problem is how I am "Responding to the Notification Post".
I am doing a standard WebRequest to send our RedirectUrl to SagePay - but the link here - SagePay RedirectURL failure - suggests it doesn't need that. Rather I should just "write to the simple Response object." The trouble is, I don't know what they mean by that.
Any help / experience with this, much appreciated.
Jon
I hope this answer isn't too late to be useful to you.
You're suffering from the main issue I've always had with Opayo (formerly SagePay) - namely that their integration guides for developers are terrible.
As the Opayo Server integration method is identical to the old SagePay version, I found it helpful to follow the much more in-depth instructions from before they rebranded. You can find those instructions here:
https://www.opayo.co.uk/file/12246/download-document/SERVER_Integration_and_Protocol_Guidelines_010814.pdf
In answer to your specific question, you can refer to page 68 of the above PDF guide. RE: You acknowledge receipt of the Notification POST, quote, "This is the plain text response part of the POST originated by the Server in the step above. Encoding must be as Name=Value fields separated by carriage-return linefeeds (CRLF)."
Literally, your script just has to print or echo something along the lines of:
Status=OK\r\n
StatusDetail=Hashes match - proceeding\r\n
RedirectURL=https://www.yoursite.com/endpointpage/
Or the equivalent for errors, aborts, etc.
Bear in mind that any output not formatted like the above will break the foldback process, so you must supress any errors or warnings your script might generate (ideally capturing them in a log or some other way).
Opayo give you basically no help in bugfixing, so if you continue to encounter errors you pretty much have to work in the dark.
Is there a way to parameter the SonarQube web service to get the line of the code causing a specific error?
For instance, if I parameter the webservice to get all the blocking issues like this:
http://localhost:9000/api/issues/search?severities=BLOCKER
the Json returned gives the line's number of the issues but not the line's code. How to have the code of those lines?
Otherwise, is there a possibility to get a link to the line causing the error?
Thank you in advance
Check out the WebAPI documentation embedded in your SonarQube server (linked at the footer). For your specific use-case you'll see that this is a good match: api/sources .
Anybody know if it's possible?
I'm trying to get the data by using the following code
url = 'https://cgwb.nci.nih.gov/cgi-bin/hgTracks';
params = {'org','Human','db','hg18','position','EGFR'};
urltxt = urlread(url,'get',params);
but get the error
??? Error using ==> urlread at 111
Error downloading URL. Your network connection may be down or your proxy settings improperly configured.
If I substitute https to http, it works, but I get "301 Moved Permanently" page with the above https-link.
The link in browser works properly in both cases (redirecting http request). The site does not require any authentication.
May be there are other ways than urlread?
Sorry, I found the answer on SO:
Handling an invalid security certificate using MATLAB's urlread command
Will test and remove if needed.
UPDATE:
It really works. DO you think I should delete the question?
An alternative solution that worked for me:
(ps.: I'm using Fedora Linux, Matlab 2017a. Not sure if it will work in a simply way for windows users).
The following command line in Matlab that I used to get the data as:
AllDataURL=urlread('https://bittrex.com/api/v1.1/public/getmarketsummaries');
was successfully replaced by the following command line:
[status,AllDataURL]=dos('curl https://bittrex.com/api/v1.1/public/getmarketsummaries');
Although the result value for the variable 'status' is zero, the data into variable AllDataURL is exactly the same as the previous one when using urlread.
Hope it helps.
I can't access most of the Sonar API, for example
localhost:9000/api/tests/show?key=htmlparser:/src/test/java/HtmlParserTest.java
or see api/sources/scm. api/server/system and some other general stuff works but nothing where I actually see the code.
I always get a
{"errors":[{"msg":"Insufficient privileges"}]}
I set the project permissions to let anyone see source code & browse the porject, I tried it with Postman, a Java HttpRequest, the command line ...
curl -u admin:admin localhost:9000/api/tests/show?key=htmlparser:/src/test/java/HtmlParserTest.java
I checked with SonarQube 5.1 and 4.5.1. I've found a posts with the same issue but have yet to find a fix. Does anyone have a solution idea?
Thanks for your help
SOLUTION
It was a syntax error (even though the message said Insufficient privileges). The correct call would be:
localhost:9000/api/tests/show?key=htmlparser:htmlparser:src/test/java/HtmlParserTest.java
If you are not sure what goes before the "src/..." don't worry. You can get it by calling api/projects/index and looking at the attribute named "k".
I'm trying to get Sensu twitter-handler working on my environment. The issue is that I'm not getting any errors on screen or logs when I cat a .json event into the twitter-handler and, the tweets are not being shown on the linked account.
Here're are my config files:
https://gist.github.com/Mariano-gon/8648427
https://gist.github.com/Mariano-gon/8648455
https://gist.github.com/Mariano-gon/8648489
This is the output I get:
https://gist.github.com/Mariano-gon/8648480
One important note is that in sensu-api.log the request are being recieved:
https://gist.github.com/Mariano-gon/8673758
So, my question is: is there a way to troubleshoot this issue? Any way to debug the handler.rb?
Thanks!
Finally got it working! Thing was the new 'twitter' gem (in my case v5.6) won't work with the code as it was written. I needed to follow this great answer and this thread too. Was just a matter of sintaxis (as usual).
Thanks!