I'm trying to pass digest auth on my ip camera
I do it on Flutter but actually it doesn't matter.
I got http response from camera with status code 401 Not Authorized
and Headers:
{content-type: text/html, pragma: no-cache, cache-control: no-cache, www-authenticate: Digest
realm="goAhead", domain=":13237",qop="auth", nonce="a98326cc6022c2a2b7cc7e57a5956f77",
opaque="5ccc069c403ebaf9f0171e9517f40e41",algorithm="MD5", stale="FALSE", date: Thu Dec 26 16:31:43
2019, server: GoAhead-Webs}
from this source here I've found the needed Response constructor view like this:
var mResponse = "Digest username=\"$username\", realm=\"$realm\", nonce=\"$nonce\", uri=\"$uri\",
response=\"$_response\", cnonce=\"$cnonce\", nc=$nc, qop=\"$qop\"";
I create this:
Digest username="admin", realm="goAhead", nonce="a98326cc6022c2a2b7cc7e57a5956f77",
uri="/onvif/device_service", response="5313fe5265efcd3da37cec322d92ebd7", cnonce="1234567890",
nc=00000001, qop="auth"
and send http request to camera:
Future<http.Response> new_response = http.post(snapshotUrl, headers: {"Content-Type":"text/xml; charset=utf-8", "Authorization": mResponse }, body: mGetSnapshotUriAuth);
new_response.then((resp){
print(resp.statusCode);
});
and getting this error:
[ERROR:flutter/lib/ui/ui_dart_state.cc(157)] Unhandled Exception: Invalid header field name
When I remove "Authorization" field of headers, camera response with 401 code.
I'm trying to get snapshot from ip camera works on Onvif protocol. I am not sure in Uri parameter.
The same error when I try send this http request via http Client on desktop machine screenshot
Question 2:
When I try to change uri param to something else e.g:
String uri = http://www.onvif.org/ver10/media/wsdl/GetSnapshotUri";
My camera stops reply to me. The same behaviour I can see when I start use Http sniffer or change Digest's response's field name. Sometimes reset camera helps(or even hard reset) and it start working(return 401 error) again, sometimes it's start working by itself. But by the way the camera continues working via others Camera Viewer Apps.
My screenshot from http sniffer
PS After many tests to solve this problem I think my param values are correct, because If change something e.g username, password and etc (except cnonce. When I change сnonce the result the same), I got other error: 401.
screenshot of Android studio with error
Writing SOAP requests by hand is BAD PRACTICE. I know nothing about dart, but I invite you to look for a tool like gsoap for generating the functions from thw WSDL files you can find here.
Don't write requests by hand, you'll end up in a mess when parsing the responses.
Related
There is an api for authorization, I send a request using thunder client, everything seems to be ok, I get a token in response, but when I try to knock on the same link in the application itself using the dio library, I get an Http status error [301] in response, what could be the problem, I didn't really find an answer anywhere?
how do I send a request
final response = await _dio.post(
'http://someaddress.com/api/auth/login',
data: {"login": phone, "password": event.password},
);
Error:
Http 301 status code means that the link is not anymore available and new one is defined in Location header. The response looks like something like this.
HTTP/1.1 301 Moved Permanently
Location: https://foo.bar/foobar
Response headers in dio can be accessed by headers property.
I was trying to setup Jmeter for Salesforce API testing. However getting the below error during Salesforce authorization:
"error":"unsupported_grant_type","error_description":"grant type not
supported"
I am passing the parameters as in the screenshots attached. The same parameters when passed in Postman works fine, however I am getting this error in Jmeter. Please let me know if I am making some error in passing the parameters in Jmeter.
Jmeter_HTTP Header Manager
Jmeter_HTTP Request
Jmeter_Sampler Result
According to HTTP Status Code 400 documentation
The HyperText Transfer Protocol (HTTP) 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
Looking into your request, you're sending Content-Type header as application/json therefore your server expects JSON and you're providing something different.
My expectation is that you should switch to Body Data tab of the HTTP Request sampler and set the request body to look like:
Check out REST API Testing - How to Do it Right article for more information on REST APIs testing using JMeter.
I struggle with the same issue but it finally worked for me by doing the following:
Use Content-Type application/x-www-form-urlencoded in an HTTP Header Manager
Make sure is a POST Method and that you're using https
Not sure if it is necessary but in the Parameters tab make sure all (grant_type, password, client_secret_ client_id and username) are Content-Type application/x-www-form-urlencoded and check the URL Encode option for all
Only check "Follow Redirects" and "Use KeepAlive" options in the HTTP Request
hope it works for you too
I am wondering how server should respond for CORS request that asks for unsupported method.
I have server endpoint, lets say server.com/endpoint which supports only GET. But client is sending CORS OPTIONS request with headers:
Origin: another.com
Access-Control-Request-Method: POST
How proper response should look? Should it return some error message about unsupported POST method, or just return 200 OK with typical CORS response headers like:
Access-Control-Allow-Methods: GET
Access-Control-Allow-Origin: another.com
Or maybe I should treat it as request without CORS headers?
Also what should be returned in case of some random origin in request? Should i reveal which origins are allowed or keep it hidden and return no "Allow" headers?
I am wondering how server should respond for CORS request that asks for unsupported method.
I have server endpoint, lets say server.com/endpoint which supports only GET. But client is sending CORS OPTIONS request with headers:
Origin: another.com
Access-Control-Request-Method: POST
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests explains what’s happening: That OPTIONS is an expected request that browsers on their own automatically send as part of the CORS protocol.
How proper response should look? Should it return some error message about unsupported POST method
No, supporting the CORS protocol as expected on your server side doesn’t require you to send any special error response for this case. The browser just interprets the lack of "Allow" headers in the normal response as meaning that the server doesn’t allow the type of request it’s received.
or just return 200 OK with typical CORS response headers like:
Access-Control-Allow-Methods: GET
Access-Control-Allow-Origin: another.com
That would be the right way to respond to it as far as supporting CORS as expected for the case where you get a request from the allowed origin another.com but for an unsupported method (e.g., POST, if you don’t support that). That enables the browser to log a specific CORS error on the client side to let the developer know the non-allowed method is the problem, not the origin.
Also what should be returned in case of some random origin in request? Should I reveal which origins are allowed or keep it hidden and return no "Allow" headers?
You can just return no "Allow" headers in the case of a non-allowed origin. There’s never any need to reveal what origins are allowed, except to allowed origins. (Anyway, the Access-Control-Allow-Origin value is always just going to contain either a single origin, or else the * wildcard, so no random origin making a request is going to be able to sniff out all the allowed origins.)
And to be clear, the CORS protocol in no way requires servers to respond to random non-allowed origins with any CORS headers at all. The semantics of the protocol are such that to a browser, a response with no "Allow" headers at all means, “This server does not allow cross-origin requests from your origin”. A random non-allowed origin doesn’t need any more information than just that.
i am trying to implement caching for dynamic API calls where data is near-static. The approach i have taken is using the ETag and returning an ETag header for a Web API response headers. However, Browser doesn't seems to return the "if-None-Match" header at all for me to validate the subsequent calls.
Please note that i am using https and i have a valid SSL installed. Anyone had this issue and potential clues?
Found the root cause of the issue, It was due to the wrong cache-headers being sent by the server particularly Cache-Control: no-store
After changing the response headers, Browser is now able to send the If-None-Match request header.
My current response header is as below which is good enough to request the browser to re-validate it.
I'm trying to call getAllSiteAccounts using the following URL:
https://rest.developer.yodlee.com/services/srest/restserver/v1.0/jsonsdk/SiteAccountManagement/getAllSiteAccounts
When I make the call, I get back:
oauth_error_problem=invalid_url_access&oauth_error_code=418
A 418 error code is:
STATUS_HTTP_DNS_ERROR_EXCEPTION
Problem Updating Account(418): We could not update your account because the site is experiencing technical difficulties. Please try later.
Am I using the correct URL? I know they really don't want us to use this call in evaluation mode as it could time out, but I would think I'd get back a different error if that was the case.
Thanks,
Chris
This URL is working. I tried this REST API using an external REST client and successfully got the response.
Below is the request which is being sent.
POST /services/srest/restserver/v1.0/jsonsdk/SiteAccountManagement/getAllSiteAccounts HTTP/1.1
Host: rest.developer.yodlee.com
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
cobSessionToken=xxxxxxxxxxxxx&userSessionToken=xxxxxxxxxxxxxxxxxx
Can you test this again.