MIP SDK file handler prints "MIP Error: XPath returned no results" after upgrading to 1.9 - microsoft-information-protection

File handler was throwing error for some png file so I updated the SDK to 1.9.90 from 1.8.102.
Now it works fine but printing error for CreateFileHandlerAsync() method saying " MIP Error: XPath returned no results (`anonymous-namespace'::GetXmlNodesFromPath:src\protection\rest_clients\license_parser.cpp:209"

This will likely require investigation by engineering. I’d recommend opening a support case so we can get all of the required logs. Can you reproduce the error on other files, or newly protected files?

Related

MediaWiki InstantCommons file download error

My goal: I'd like to use an image from commons.mediawiki.org within a MediaWiki installation.
First I was trying to debug my InstantCommons configuration: Referring to files on commons.mediawiki.org failed for some reason. After activating various debugging options I learned that though general image download succeeded some kind of thumbnail followup request issued by the MediaWiki installation failed, which resulted into an overall error from the ForeignAPIRepo-Module.
As I can not deal with this error right now I thought I'd try something else as some kind of fallback: Download the MediaWiki image by specifiying the image URL in the upload image web page. The idea is to let MediaWiki download the image and include this image as regular wiki content. This way I would require to add license details manually and add a few comments, but this would be better than having no image.
But trying this I strangely get an error: It says "Fehler beim Senden der Anfrage" which means "Error while sending the request". But the internal request seems succeed in the logs. Here is what MediaWiki was logging:
[fileupload] Temporary file created "/tmp/URLdafce5345aa3-1"
[fileupload] Starting download from "https://upload.wikimedia.org/wikipedia/commons/c/c7/Broccoli%2C_Champignons%2C_Karotten_%2810581663524%29.jpg" <followRedirects>
[fileupload] <Error, collected 1 error(s) on the way, integer value set>
+------+---------------------------+------------------------------------------+
| 1 | http-request-error | |
+------+---------------------------+------------------------------------------+
[fileupload] Download by URL completed with HTTP status 200
Comment: All other log messages do not indicate anything that looks like an error or is related to the task of downloading the image, so I skipped them here.
The URL is correct, the image can be downloaded from the URL, MediaWiki receives a response code of 200, but instead of processing the response it indicates an error. Why? For http and https URLs I get the same result in the log.
Has anybody encountered this problem before in MediaWiki installations? Does anyone have any idea what the reason for this behaviour could be?
Comment: The wiki is of version 1.25.2 and a standard installation including SWM on an up to date standard Ubuntu Linux OS. Nothing exotic, nothing modified in any way.
Comment: Yes, I could upgrade to the latest version but, I'm not sure if this really solves the problem: I know that this featured did work in some other MediaWiki installations I have set up some time ago. Does anyone have a clue why this feature could fail here? Has anyone encountered something like this before?
Edit: I experimented with downloading from another MediaWiki instance of exactly the same version - 1.25.2 - in my local network. This did not succeed as well. But I get a different error message (translated): "The file .... could not be stored at ...". The "funny part": Though the error message indicated otherwise the file has been downloaded successfully and stored as expected. It has the correct user rights as one would expect, but log messages indicate that there are bugs in MediaWiki regarding this part: ("PHP Notice: Undefined property: UploadFromUrl::$nbytes") Maybe the uploading implementation is buggy somehow and the problems I am running into are typical?
There are multiple bugs with HTTPS support in MediaWiki, php-curl etc. See https://www.mediawiki.org/wiki/InstantCommons#HTTPS for debugging information, there is no magic bullet.

BreezeJS's 1.4.1 isolateES5Props causing Out of Stack Space error in IE 8

Using 1.4.1 of BreezeJS we found that some new code added to Isolate ES5 Properties is causing IE 8 to have the following error:
Error getting metadata: Metadata import failed for breeze/breeze/Metadata; Unable to process returned metadata:Object doesn't support property or method 'getPrototypeOf'
We tried using both Uber Proto's getPrototypeOf (https://github.com/daffl/uberproto) and es5-sham (https://github.com/kriskowal/es5-shim) but both result with the same issue.
We also tried removing the regular json.parse and using json2's version with the same results.
Metadata import failed for /breeze/breeze/Metadata; Unable to process returned metadata:Out of stack space
Chrome, Firefox, and IE 9+ work without issue, but IE 8 support is required. We can comment out the line to get it to work:
// isolateES5Props(proto);
But I'm guessing that will cause issues somewhere down the line.
This should be fixed in Breeze v 1.4.2, available now.

Breeze JSON Parse Error for Metadata

I just upgraded my Breeze nuget package from 1.1.3 to 1.2.7. I was getting error about some of my classes that had "ComplexType" items, so after upgrade I am getting the error below when reading the Metadata from my MVC4 Web API. Everything was working properly before that with the exception of ComplexType, so I know for sure everything is in place, since I was getting the Metadata, and was able to show the data on the screen.
Uncaught SyntaxError: Unexpected token o
Uncaught SyntaxError: Unexpected token o breeze.debug.js:12561
ctor.fetchMetadata.ajaxImpl.ajax.success breeze.debug.js:12561
jQuery.Callbacks.fire jquery-1.9.1.js:1037
jQuery.Callbacks.self.fireWith jquery-1.9.1.js:1148
done jquery-1.9.1.js:8074
jQuery.ajaxTransport.send.callback
I was having the exact same problem and I noticed that when you issue a GET against the metadata location (/api/Context/Metadata), it returned an xml document formatted as json. I also think there is a related question, but in a slightly different context. In this case however, the error was raised at ctor.prototype.fetchMetadata in a line containing JSON.parse(). But I'm pretty sure is the exact same underlying cause.
Just update Breeze from Nuget (both the the dll and the js files) and that would do the trick.
Notice that you might have to manually delete the breeze files from the /Scripts folders.

Ported Chrome extension to Firefox not working (indexedDB error)

I'm trying to port the Twitter Notifier extension to FF.
I'm not too familiar with JavaScript so I just used extension factory to convert it to FF.
Unfortunately it is not working; I don't get any HTML5 desktop notifications.
I've looked at the code a bit and I think the problem is with twitter.js which should be found in the path 'resources\extension-data\js'.
http://pastebin.com/C0NqU4Ur
First I've changed
twitter.messagesDB = window.webkitIndexedDB.open("messagesDB");
to
twitter.messagesDB = window.mozIndexedDB.open("messagesDB");
but it still is not working.
The error console also doesn't show any error.
When I put a console.log command to the twitter.messagesDB.onsuccess function nothing is being outputted to the error console.
Also no output when I create an onerror function.
So I though to surround the functions with a try and catch clause but no error is being thrown.
So I tried to put twitter.messagesDB = twitter.messagesDB.result; out of the function and the following error shows up in the error console:
Error: uncaught exception: [Exception... "A mutation operation was attempted on a database that did not allow mutations." code: "6" nsresult: "0x80660006 (NS_ERROR_DOM_INDEXEDDB_NOT_ALLOWED_ERR)" location: "chrome-extension://gjlehiopfilnaggndcmbhphaglkbkekf/js/twitter.js Line: 28"]
What does that mean?
How can I make it work in Firefox?
Thanks in advance!
Edit: I'm using Firefox 12 on Windows
This is due to an incompatibility between the Firefox implementation of IndexedDB, which supports the latest IndedexDB protocol published December 2011, and the Chrome implementation, which supports the version previous to that.
The breaking change is how databases are created, where the older (Chrome) implementation uses the setVersion transaction whereas the newer version (FF) uses an onupgradeneeded event and callback.
To see this change, please star this issue.

NSURLErrorDomain error -3001

I'm trying to download a file from the internet, but I get the error -3001 back. I've been searching through google but the error doesn't appear on any website, so i have no idea what it means.
Can anyone tell me what the error code "NSURLErrorDomain error -3001" means?
Thanks
There's also a full list of all NSURL error codes here. It's very handy when you get cryptic error messages from the URL loading system.
I wrote an applescript awhile back that can search the header files for error codes. You can find the applescript here.
I ran that applescript for your error code and got this from the CFNetworkError.h file.
Error Description:
kCFURLErrorCannotOpenFile
The error comes from the fact that setDestination expects a full path with a filename:
This is wrong:
[fileDl setDestination:#"/Users/ant/ebooks/" allowOverwrite:YES];
This is right:
[fileDl setDestination:#"/Users/ant/ebooks/file.epub" allowOverwrite:YES];
So the explanation is that probably you did something like I did: specify an existing folder where you intended to put the data.
PS: the dash before 3001 prevents Google from returning any results with the request: "NSURLErrorDomain error -3001", it is parsed as: "NSURLErrorDomain and error and not 3001"..

Resources