I am building a Rest client with cpprest-sdk to communicate with a web service. The problem is that every once in a while, after sending multiple successful requests (around 50), I get the exception:
WinHttpSendRequest: 2148074273 insufficient cache in function
Or sometimes:
ERROR_WINHTTP_SECURE_FAILURE (12175)
I tried to look for cache options in cpprest-sdk but did not find anything. Since the exceptions happens inside cpprest-sdk when I call .wait() on my task I am not sure if I can use the WINHTTP_STATUS_CALLBACK to check for more details on this error. How can I investigate deeper to find the cause of this error?
Here is my Rest request:
void MyRestClient::PostKeys(const std::string & sKek, const std::string & sKid, const std::string & sCustomerAuthenticator) {
uri_builder oBuilder(U("/keys?customerAuthenticator=") + to_string_t(sCustomerAuthenticator));
oBuilder.append_query(KEK, to_string_t(sKek));
json::value oBody;
oBody[KID] = json::value::string(to_string_t(sKid));
web::http::http_request oRequest;
oRequest.set_method(methods::POST);
oRequest.set_request_uri(oBuilder.to_uri());
oRequest.set_body(oBody);
m_oCurrentTask = oClient.request(oRequest).then([this](http_response oResponse) {
OnPostResponse(oResponse);
});
}
According to https://msdn.microsoft.com/en-us/library/windows/desktop/aa383928(v=vs.85).aspx (4th bullet), Post requests should not be cached so I don't understand why I am getting the first exception. I also tried to disable Https caching as the 6th bullet in the link suggest, but that did not change anything.
Did anyone experienced something similar or have any insight as to what may be happening? Or is this a normal behavior and should I just retry my request when these exceptions happens?
Does your Web Service use TLS with Diffie-Hellman key exchange? If yes, you are probably seeing a bug in SChannel, which is the SSL implementation of Windows, see here for a confirmation. Unfortunately, the only available fix is an update of the Windows version on which your client is running to a recent build of Windows 10.
Related
I am using libwidevinecdm.so from chrome to handle DRM protected data. I am currently successfully setting the widevine server certificate I get from the license server. I can also create a session with the pssh box of the media im trying to decode. So far everything is successful (all promises resolve fine).
(session is created like this: _cdm->CreateSessionAndGenerateRequest(promise_id, cdm::SessionType::kTemporary, cdm::InitDataType::kCenc, pssh_box.data(), static_cast<uint32_t>(pssh_box.size()));)
I am then getting a session message of type kLicenseRequest which I am forwarding to the respective license server. The license server responds with a valid response and the same amount of data as I can see in the browser when using Chrome. I am then passing this to my session like this:
_cdm->UpdateSession(promise_id, session_id.data(), static_cast<uint32_t>(session_id.size()),
license_response.data(), static_cast<uint32_t>(license_response.size()));
The problem now is that this promise never resolves. It keeps posting the kLicenseRequest message over and over again to my session without ever returning. Does this mean my response is wrong? Or is this something else?
Br
Yanick
The issue is caused by the fact, that everything in CreateSessionAndGenerateRequest is done synchronous - that means by the time CreateSessionAndGenerateRequest returns your promise will always be resolved.
The CDM will emit the kLicenseRequest inside CreateSessionAndGenerateRequest and it doesn't do so in a "fire & forget" fashion, but the function waits there until you have returned from the cdm::Host_10::OnSessionMessage. Since my implementation of OnSessionMessage was creating a synchronous HTTP Request to the license server before - also synchronously - calling the UpdateSession the entire chain ended up to be blocking.
So ultimately I was calling UpdateSession while still being inside CreateSessionAndGenerateRequest and I assume the CDM cannot handle this and reacts by creating a new session with the given ID and generating a request again, which of course triggered another UpdateSession and so on.
Ultimately the simplest way to break the cycle was to make something asynchronous. I decided to launch a separate thread when receiving kLicenseRequest, wait for a few milliseconds to make sure that CreateSessionAndGenerateRequest has time to finish (not sure if that is really required) and then issue the request to the license server.
The only change I had to do was adding the surrounding std::thread:
void WidevineSession::forward_license_request(const std::vector<uint8_t> &data) {
std::thread{
[=]() {
std::this_thread::sleep_for(std::chrono::milliseconds{100});
net::HttpRequest request{"POST", _license_server_url};
request.add_header("Authorization", fmt::format("Bearer {}", _access_token))
.byte_body(data);
const auto response = _client.execute(request);
if (response.status_code() != 200) {
log->error("Widevine license request not accepted by license server: {} {} ({})", response.status_code(), response.status_text(), utils::bytes_to_utf8(response.body()));
throw std::runtime_error{"Error requesting widevine license"};
}
log->info("Successfully requested widevine license from license server");
_adapter->update_session(this, _session_id, response.body());
}
}.detach();
}
I have come across the https://jxbrowser.support.teamdev.com/support/solutions/articles/9000013108-network-events in the JXBrowser and wanted to add new cookies so that it could be used in the subsequent calls.
The support is available to add headers however since no direct access is available for the cookies I tried using the
public void onBeforeSendHeaders(BeforeSendHeadersParams paramBeforeSendHeadersParams)
{
List<Cookie> cookieList = browser.getCookieStorage().getAllCookies();
}
Also note that the calls of below snippet produces the same exception
browser.getURL(); //Exception is thrown here
CookieStorage storage = setCookies(paramBeforeSendHeadersParams, browser, list);
storage.save();// Exceptino is thrown here
but if i do this i get
java.lang.IllegalStateException: You are trying to execute some code that invokes synchronous message send to IPC channel. This code is executed in the scope of the handler which is bounded to synchronous message received from IPC channel. Such code execution causes a deadlock in native code with high probability and is forbidden.
What is the reasoning behind this any help is appreciated
As I understand, you want your application to share cookies between several Browser instances.
It is possible to make Two Browser instances with the same BrowserContext instances which use the same user data directory. As a result, they will share cookies and cache files. For example:
BrowserContext context = new BrowserContext(
new BrowserContextParams("C:\\my-data1"));
Browser browser1 = new Browser(context);
Browser browser2 = new Browser(context);
In this case, you should not receive the exception.
This is a follow up of this question. At first I thought the issue was resolved after checking out the example from the Qt wiki (I use the same code without a single change). However it appears that it's the URL that is the culprit. I tried using the links provided in this answer to test my http GET request. Using the Http Requester (Firefox addon for Http requests (GET, POST etc.)) and curl shows no issues with this link^:
$~: curl --request GET --url "http://httpbin.org/ip"
For some reason Qt gets stuck and the readyRead()/finished() signals are never emitted.
As a result the request gets cancelled after some time due to socket timeout...For something that is really small and opened by Firefox in less than a second.
I'm far from an expert when it comes to Http stuff. I'd like to know why this behaviour occurs in Qt while there is no sign of it when working with other tools.
EDIT: I've also tested the problematic URLs using Python and its urllib
import urllib.request
res = urllib.request.urlopen("http://httpbin.org/ip").read().decode("utf-8")
import xml.etree.ElementTree as ET
doc = ET.fromstring(res)
and it works just fine. Clearly there is something with Qt going on and/or me missing something when using it.
EDIT2: I've also tried another test service for HTTP requests - https://postman-echo.com. With curl there is no problem:
$~: curl --request GET --url "https://postman-echo.com/get?foo1=bar1&foo2=bar2"
For my surprise though there is no problem with Qt either! The only thing that I see here as a huge difference is that postman-echo.com uses HTTPS while the other URLs I've tried were HTTP. I exclude the https://www.qt.io which was the default URL in the Qt example and worked just fine (though it didn't have any parameters).
Try executing that in an event loop. Here is something similar to what I do in a non-gui application:
QUrl req_url = QUrl(href);
QNetworkRequest request(req_url);
//request.setRawHeader("Content-Type", "application/json;utf8");
//q_nam is QNetworkAccessManager created earlier
QNetworkReply *reply = q_nam->get(request);
QEventLoop event_loop;
connect(q_nam, SIGNAL(finished(QNetworkReply * ) ), &event_loop, SLOT(quit() ) );
event_loop.exec(); // blocks stack until "finished()" has been called
event_loop.processEvents(QEventLoop::ExcludeUserInputEvents, 500 );//what events to processed and for how long
event_loop.exit();
QNetworkReply::NetworkError er = reply->error();
// ....continue handling
I forgot to mention that I'm behind. Frankly I feel rather stupid for missing this and also not checking through the guest network at work (which circumvents the stupid proxy). A colleague of mine tried using HTTPS instead of HTTP (which is the original link). The HTTPS is also something that the proxy just lets go through without any issues. And it worked.
However a more neutral solution is (as my colleagues found out) to use QNetworkProxyFactory::setUseSystemConfiguration(true) which takes the proxy configuration that I have system-wide.
I'm trying to build a simple web app using Django. I'd like a minimal user model with verification using Mozilla Persona. Using Persona happens without a hitch, until the SSL certificate fails when tossing the authentication (success or failure) back to the Django app.
I know there is a lot on Stack Overflow already about SSL errors, but I haven't turned up anything that works in this case. For example, trying to use verify = False when using the requests package still produces the error.
I was able to replicate the error in a minimal example app using the default settings for a new Django project and following the boilerplate installation for django_browserid. Even if this can be hacked, it might be worth noting in either the django_browserid docs or the Persona documentation if someone knows how to remedy this annoying bug.
I've put this minimal example with instructions on GitHub.com at:
https://github.com/pedmiston/ssl_error
The actual error is, with [blob] substituted in place of the assertion.
Error while verifying assertion [blob] with audience http://localhost:8000.
[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:598)
I'm on OSX Mavericks.
Update: I was able to get the minimal example to pass using sigmavirus24's answer, by adding the following to my virtualenv's src/django_browserid/base.py
class RemoteVerifier(object):
"""
Verifies BrowserID assertions using a remote verification service.
By default, this uses the Mozilla Persona service for remote verification.
"""
verification_service_url = 'https://verifier.login.persona.org/verify'
requests_parameters = {
'timeout': 5,
'verify': False,
}
# ...
This is great, and it gets the minimal example to pass (and assures me that this isn't really a django_browserid or Persona error?).
However, it does just kind of by-pass the merits of the verification procedure. Now that the error has been localized, any suggestions for how to fix it?
I've been reading that there were some changes in OS X when Mavericks came around, in a switch from open_ssl to Apple's own Secure Transport engine. If this is the cause of the problem I'm having, then it might be worth knowing for others who run into a similar problem when using Mavericks.
Looking at your example app and it's sole dependency it seems your trouble is coming from this line in django_browserid. I'm not familiar with your app or django_browserid but if you can pass verify=False to https://github.com/mozilla/django-browserid/blob/66641335751b869562ba7a554e61ca56bc880257/django_browserid/base.py#L167 this should solve your problems. In other words, if you specify which Verifier you use, then it should do something like
verifier = RemoteVerifier()
verifier.requests_parameters['verify'] = False
# or
verifier.verify(verify=False)
Of course you didn't show any code where you were doing that so that could be what you meant when you said:
For example, trying to use verify = False when using the requests package still produces the error.
But I can't tell that from the code you have posted.
I'm running CF 9.0.1 Developer and Coldbox 3.0.0 on my local machine (64-bit Windows Vista running 32-bit CF9 on Apache). I'm working on an application that I've checked out from SVN and deployed locally. Everything seems to be working correctly, but my application log is filling up with entries like this:
Apr 18, 2011 12:41 PM Error jrpp-7
exception.log has an extremely long stack trace for each exception, maybe 150 lines or so. It starts with this:
"Error","jrpp-4","04/18/11","11:07:30",,""
java.lang.NullPointerException
at coldfusion.util.Utils.getServletPath(Utils.java:86)
at coldfusion.util.Utils.getServletPath(Utils.java:76)
at coldfusion.util.Utils.getBaseTemplatePath(Utils.java:405)
at coldfusion.runtime.TemplateProxyFactory.getTemplateFileHelper
(TemplateProxyFactory.java:1522)
at coldfusion.runtime.MetadataUtils.getComponentMetadata
(MetadataUtils.java:112)
at coldfusion.runtime.CfJspPage.GetComponentMetaData(CfJspPage.java:2667)
at coldfusion.runtime.TemplateProxy.getRuntimeComponentMetadata
(TemplateProxy.java:1756)
at coldfusion.runtime.TemplateProxy.getRuntimeMetadata
(TemplateProxy.java:1617)
at coldfusion.runtime.MetadataUtils.getMetaData(MetadataUtils.java:54)
at coldfusion.runtime.CfJspPage.GetMetaData(CfJspPage.java:2640)
at cfEventHandler2ecfc862260423$funcPOSTLOAD.runFunction
(C:\ColdFusion9\wwwroot\ybocv5\coldbox\system\orm\hibernate
\EventHandler.cfc:30)
This is a version of an app that has been running in production, and what makes me think this is just on my local version is the appearance of this in the stack trace:
at cfdump2ecfm471394032$funcRENDEROUTPUT.runFunction
(E:\cf9_updates_rc\cfusion\wwwroot\WEB-INF\cftags\dump.cfm:704)
...
at cfCollectionPanel2ecfm961210602.runPage
(C:\ColdFusion9\wwwroot\ybocv5\coldbox\system\includes
\panels\CollectionPanel.cfm:40)
We don't use cfdump in production; this looks like ColdBox is trying to display a complex object in a debugger panel and failing.
The only thing I found online so far was this thread in Google's transfer-dev group ... someone who saw a bunch of similar errors and thought maybe it was a CF9 bug. The only reply with any sort of solution was this one, suggesting a fix that seems to be Transfer-specific.
Does anyone know what might be causing these errors? It's not as important to me to fix them as it would be on a production app, but if I'm spamming my logs with these errors, it's hard to find legitimate errors when they do occur.
Update: I've been working with the CollectionPanel.cfm template to identify the root cause, and the exception is consistently thrown here:
<cfelseif isObject(varVal)>
<!--- this cfdump is the guilty party ... --->
<cfdump var="#varVal#" expand="false" top="2">
<cfelse>
I've tried wrapping the cfdump in a try-catch, but the exception is thrown anyway, always from that same line of code. This makes sense, I guess, given that these errors don't have any visible effect on the pages on which they occur.
It appears to not be caused from a <cfdump> instead from a GetMetaData() call.
Specifically when you get the meta data of a cfc, which extends another cfc which has been modified after the current has been compiled (and where GetMetaData has been run) where it needs to update the extends struct in the GetMetaData() return. Cf only generates the meta data struct once, most likely for performance reasons.
I think it might be a bug in cf...
Inside the TemplateProxyFactory.getTemplateFileHelper() it's calling runtime.resolveTemplatePath(compName + ".cfc") where compName is name.replace('.', '/')
All good and well until you use a mapping. If you straight out replace dots with slashes, you'll need to add a leading slash, just like they do in TemplateProxy.getMetaData()
Without the leading slash, resolveTemplatePath() returns null, which triggers the VFSFileFactory.getFileObject() call which tries to get a File object from the parent cfc name.
Before it even gets to the VFSFileFactory, it calls Util.getBaseTemplatePath() with the pageContext. Inside it gets the ServletContext from the pageContext and tries to call getServletPath() so that it can get its real path. Utils.getServletPath() tries to get the attribute "javax.servlet.include.servlet_path" which on my machine (and probably yours) doesn't exist and returns null.
You can check by calling this: isNull(getPageContext().getRequest().getRequest().getAttribute("javax.servlet.include.servlet_path")); - yes, there is supposed to be two .getRequest() calls in there.
So it seems Cf is trying to refresh it's extends struct in a cfc getMetaData() call when the extended file is modified and does it a different way then when it first generated the struct.
In you cf admin, what are you settings under Server Settings > Caching?
Trusted cache? Cache template in request? Component cache? Save class files? Cache web server paths?