In API Blueprint, how do I avoid using the same request Authorization header block over and over for every endpoint?
+ Request (application/json)
+ Headers
Authorization: Bearer jsonWebToken
Is there a way to template this in a data structure perhaps?
Unfortunately API Blueprint has not such feature (yet)
On the other hand, I can tell you that authentication\authorisation framework is being worked - so it's possible that in a not so far future this issue will be solved for you.
Cheers!
Vincenzo answer is correct. The issue planned to address this is Authentication and MSON Parameters and Headers.
In the mean time. One work-around would be to use Hercule to split your blueprint into multiple parts and transclude the auth headers.
Related
I am trying to run jmeter to load test vaadin13 application following the article here How to perform an Load Test/Performance Test with Vaadin 10 (is it possible with Jmeter?) which is absolutely very helpful. However, i encounter being return for(;;);[{"meta":{"sessionExpired":true}}] for every request which i am clueless.
I check that Vaadin-Security-Key is extracted correctly. Check the request data csrfToken, node is replaced with the value correctly. I am clueless on what i am missing here. Would like to seek advice what else i am missing. Thanks in advance.
Request payload (data) you are sending is JSON. I guess you have not set Content-Type header in your request and Vaadin cannot read payload you have sent, thus cannot read csrfToken which is needed to validate session.
You can set headers using HTTP Header Manager component. If all requests are sending json data, you can add this component on Thread Group level, and if only certain requests needs it you can add it to specific HTTP Sampler...
For json-type requests, content-type header should have value application/json; charset=UTF-8.
I hope this will resolve issue you are facing...
There are a lot of ids that need to be correlated when writing a test plan for VAADIN.
If the answer you're pointing at did not work for you, it will be easier to try to use this autocorrelator for Vaadin.
Disclaimer: We are providers of this solution
As you can see in your request POST data, you have CSRF Token. You need to correlate the CSRF Token and that error should resolve.
In order to satisfy Dredd, I have to write this for every response in my API Blueprint document:
+ Response 201 (application/json; charset=utf-8)
Is there a way to specify the media type ((application/json; charset=utf-8)) once, globally, for every response? This would have cleaned the document a bit.
As far as I know, this is not a supported scenario. I suggest you to file an issue on API Blueprint repository on GitHub to eventually get this feature request evaluated!
I am trying to figure out what the best way is to pass an oauth bearer token to a websocket endpoint.
This SO answer suggests to send the token in the URL,
however this approach has all the drawbacks of authenticating via the URL. Security implications discussed here
Thus i was wondering what would be the drawbacks to use the subprotocols to pass the token to the server ? i.e. instead of treating the requested subprotocols as a list of constants. Send at least one subprotocol that follows a syntax like for example: authorization-bearer-<token>
The token would end up in a request header.
The server while processing the subprotocols would be able to find and treat the token easily with a bit of custom code.
Since passing subprotocols should be supported by a lot of websocket implementations, this should work for a lot of clients.
This worked for me, I used this WebSocket client library.
You need to send OAUTH token via the Websocket Header, Below is the code, hope this is helpful.
ws = factory.createSocket("wss://yourcompleteendpointURL/");
ws.addHeader("Authorization", "Bearer <yourOAUTHtoken>");
ws.addHeader("Upgrade", "websocket");
ws.addHeader("Connection", "Upgrade");
ws.addHeader("Host", "<YourhostURLasabovegiveupto.com>");
ws.addHeader("Sec-WebSocket-Key", "<Somerandomkey>");
ws.addHeader("Sec-WebSocket-Version", "13");
ws.connect();
If I understand correctly, there's no need for a CSRF token if you're only allowing JSON as application/json from an "AJAX" (really AJAJ for JSON) form, right?
If someone tries to post to the form from another page using some nifty POST-to-iFrame hack it will be application/x-www-form-urlencoded, you can throw it out immediately.
If someone tries to post to the form using AJAJ, it will only succeed if OPTIONS has the CORS headers that allow it.
Conclusion: unless you're using CORS you're safe from CSRF as when you're using application/json instead of application/x-www-form-urlencoded.
Any contradictions I'm not considering?
Have a look at this Sec.SE question and answer. In short: you are correct (presently), but it's probably not a good idea to rely on this behavior, so use tokens anyway.
2022 Update
So much has changed - such as fetch giving more control to requests.
Yes, it's still dangerous
It is possible to do a cross-site JSON POST that includes cookies.
(the attacker can't see the response, but they can POST successfully)
CSRF is necessary by default.
Yes, it's easy to mitigate
Same-Site Cookies
There's now a same-site cookie option. Using this correctly makes it completely unnecessary to use CSRF tokens at all.
API Tokens
Completely abandoning Cookies in favor of per-request API tokens, such as the well-standardized JWT, will make CSRF attacks impossible.
This is best done by separating token routes from cookie routes, such as:
/api/account/xxxx for authenticated JSON API
/api/assets/xxxx for <img src="xxxx" /> and other assets that should not have a token in the URL and must therefore rely on cookies
According to this article it is enough to validate X-Requested-With header for AJAX requests sent by jQuery. So in this case it is not necessary to implement tokens?
And if yes, where is defined that cross-browser requests are not allowed?
Thanks in advance.
The article itself says that this method is insufficient:
Warning
The method of preventing CSRF attacks described in this post
is now considered to be insufficient. A comment on this post links to
more details about an attack that circumvents it.