I'm creating Firefox addon that registers new protocol which should provide HTML to Firefox from file stored on disk (generated by binary exe).
I have problem with images in tags and (probably) css styles that refer to local file. They aren't load properly and I'm getting a message in the errorconsole like this :
Security Error: Content at moz-nullprincipal:{afde522e-6b29-4359-9959-c46c749687f6} may not load or link to file:///E:/xowa_app/user/anonymous/app/img/file/magnify-clip.png.
My protocol flags : nsIProtocolHandler.URI_IS_LOCAL_FILE | nsIProtocolHandler.URI_IS_LOCAL_RESOURCE | nsIProtocolHandler.URI_STD | nsIProtocolHandler.URI_INHERITS_SECURITY_CONTEXT. (I don't know whether I understand properly MDN reference)
nsIProtocolHandler interface specs need to me that I implement function to creating new channel (MDN) when it is opening URI by the protocol. I create a channel from URI located on disk (html generated by program). The channel has owner property that "grant or deny privileges" and I setted even the owner to system principal who "passes all security checks" (MDN) but the errors are the same.
It seems to that just removing URI_INHERITS_SECURITY_CONTEXT flag (and leaving change owner to system principal) resolves my problem although I don't know when there is need to use this flag.
Related
We are developing an application to open and edit protected PDF files using the MIP SDK (we're currently using version 1.6.103).
So far, we were able to open files protected with different versions of Microsoft protection, including MicrosoftIRMServices version 1.
We are now hitting a problem with one of our customers. They keep their files on a SharePoint 2016 directory, which is configured to automatically add protection to all files uploaded. All their environment is on-premise and AD RMS Service is used for protection. They do not have Azure IP on server side.
When we download the resulting file and try to open, we create a mipns::FileEngine and then invoke CreateFileHandlerAsync() to create a mipns::FileHandler. This call fails with the following mipns::NetworkError:
NetworkError : Content protected by on prem servers is unsupported., NetworkError.Category=FailureResponseCode, HttpRequest.SanitizedUrl=https://api.aadrm.com/my/v2/enduserlicenses,
As the error suggests, I suspect the issue is with the usage of an on-premise protection.
I thought it might be resolved following the instructions at
https://learn.microsoft.com/en-us/information-protection/develop/quick-app-adrms#configuring-protection-api-in-c-to-use-ad-rms
so, following those instructions, I created the FileEngine with
ProtectionEngine::Settings engineSettings("", authDelegate, "");
engineSettings.SetProtectionCloudEndpointBaseUrl("http://<my server>/_wmcs/licensing");
but so far no success, although the error has changed and is now
NetworkError : The protection service is unavailable., NetworkError.Category=FailureResponseCode, HttpRequest.SanitizedUrl=https://<my server>/my/v1/enduserlicenses,
(where of course <my server> is replaced with a local service)
Am I going in the wrong direction? If not, perhaps I am using the wrong endpoint? How can I find the endpoint URL to be passed to SetProtectionCloudEndpointBaseUrl as suggested in the linked page?
Thanks
This is likely caused by a missing MDE install or MDE SRV record. You'll need to validate that mobile device extensions for AD RMS has been deployed and configured. If it has, you'll also need to validate that the SRV record is in place for any mail suffixes your customer is using. For example, if the RMS service is at RMS.FABRIKAM.COM, but your customer email addresses are #Contoso.com, you'd need an SRV record that looks like _rmsdisco._http._tcp.contoso.com which would then point to the server at RMS.FABRIKAM.COM.
The base URL isn't used in consumption scenarios. It's only for publishing. That said, looks like you've set the _wmcs endpoint, but we expect only the base for AD RMS:
ProtectionCloudEndpointBaseUrl = "https://rms.contoso.com"
That's only required when you don't provide a mip::Identity object when creating the file engine. If you do provide the identity, we'll use the domain suffix to look up the DNS record and chase that referral.
Does anyone know if there is a way to load any external executable javascript from a firefox add-on extension? I looked into scriptloader.loadSubScript, but it appears that it can only load from a local resource.
Any help would be appreciated.
You can always xhr for a file, save the contents to disk, then use scriptloader.loadSubScript with an add-on
this would violate the AMO policies though, so you wouldn't be able to upload the add-on to http://addons.mozilla.org
As #erikvold already pointed out, doing so would be a security hazard AND it also violates AMO rules (because it is a security hazard).
Consider your server gets compromised, or there is a way to MITM the connection retrieving the remote script (TLS bugs anyone :p), or you sell your domain and the new owner decides to ship a script to collect credit card information straight from a user's hard disk...
However, it is possible to run a remote script in an unprivileged environment, much like it would run in a website.
Create a Sandbox. The Sandbox should be unprivileged, e.g. pass an URL in your domain into the constructor.
Retrieve your script, e.g. with XHR.
Evaluate your script in the Sandbox and pull out any data it might have generated for you.
This is essentially what tools like Greasemonkey (executing user scripts) do.
Creating and working with Sandboxes in a secure fashion is hard, and the Sandbox being unprivileged prohibits a lot of use cases, but maybe it will work for your stuff.
Try using Components.utils.import .
Example :
const {Cc,Ci,Cu} = require("chrome");
Cu.import("url/path of the file");
Note :
js file which uses DOM objects like window, navigator, etc. will return error saying "window/navigator is undefined". This is simply because the main.js code does not have access to DOM.
Refer this thread for more information.
I've been given a task to create a protocol similar to callto:, that - upon clicking on a link with it - would automatically launch an installed aplication.
I followed the microsoft guide on how a scheme should look like.
My scheme looks like this:
HKEY_CLASSES_ROOT
slican
URL Protocol = ""
DefaultIcon (Default) = "C:\Users\Okabe\Desktop\slican\SlicanP.exe,1"
shell
open
command (Default) = "C:\Users\Okabe\Desktop\slican\SlicanP.exe" "%1""
I thought that was all and tested it with
test link
test telephone link
There was no reaction whatsoever. Internet Explorer asked me if I want to search for a program that can open the content and Chrome responded with nothing, as if I clicked javascript:void(0).
How to get that worked?
Thank you for your help!
The registration you show works perfectly fine for me when I try it on Windows 7. The local app I registered in place of SlicanP.exe ran fine when I invoked a slican: URL from the Start | Run menu, and from within the address bar of Windows Explorer. So the registration works.
Do be aware that Internet Explorer runs in a lower integrity security context, so it may not have rights to run local programs. When I tried to click on an HTML link to a slican: URL, or type a slican: URL in the address bar, IE had trouble executing the local app (even after prompting for permission). I had to run IE as an administrator, then the local app ran just fine.
Also, you really should not be creating a HKEY_CLASSES_ROOT\slican key directly. Create a HKEY_CURRENT_USER\Software\Classes\slican (current user only) or HKEY_LOCAL_MACHINE\Software\Classes\slican (all users) instead. Refer to MSDN for more details:
HKEY_CLASSES_ROOT Key
Merged View of HKEY_CLASSES_ROOT
Update: Since it works in Windows 7, Microsoft probably changed how URL schemes are registered in Windows 8. For instance, phone/store apps use URI activation:
URI activation (XAML).
URI activation (HTML)
The documentation says there are two ways to register a custom URI scheme:
Internet Explorer uses two mechanisms for registering new pluggable protocol handlers. The first method is to register a URI scheme name and its associated application so that all attempts to navigate to a URI using that scheme launch the application (for example, registering applications to handle mailto: or news: URIs). The second method uses the Asynchronous Pluggable Protocols API, which allows you to define new protocols by mapping the URI scheme to a class.
You are doing the first. Try using the second instead.
However, I just noticed that "Asynchronous Pluggable Protocols" is listed on MSDN in the "Legacy APIs" section, and it has the following note:
Third-party protocol implementations won't load in Windows Store apps using JavaScript, or in the Internet Explorer in the new Windows UI.
So it may or may not work in Windows 8.
Update: I just found this:
Guidelines for file types and URIs
In Windows 8, the relationship between apps and the file types they support differs from previous versions of Windows.
Walkthrough: using Windows 8 Custom Protocol Activation
The file type and protocol association model has changed in Windows 8. Apps are no longer able to programmatically set themselves as the default handler for a file type or protocol. Instead, now the user always controls what the default handler is for a file type or protocol.
Your app can use existing protocols for communication, such as mailto, or create a custom protocol. The protocol activation extension enables you to define a custom protocol or register to handle an existing protocol.
Also have a look at this:
Setting mailto: protocol handler programmatically in Windows 8
And this:
Default Programs
if you go to C:\Users\\AppData\Local\Google\Chrome\User Data
You can edit the Local State file
Search for protocol_handler
The syntax here is a key value pair. I usually copy two mailto: and make sure that you set your protocols to false. This will mean that chrome will treat your new protocols as URI_Handler events
If you have troubles with configuring custom URI scheme, you can compare your own configuration with existing one. For example, "HKEY_CLASSES_ROOT/mailto" - most likely you have it already in your system.
I am wondering if what I'm doing is a good practice. Please advise. Thanks.
My web application server caches generated chart images for users to enhance performance.
The images are stored in session-based folders, where the folder name is generated.
Let's say user1 plotted a chart and is cached on the server here:
webapp\sessionFolder\aklfq13d10jd10\image.jpg
I disabled IIS7 directory browsing.
But I find that other users of the system, can access the image too, if they input the full url. But they're not supposed to see it as it is cached for user1.
How can I avoid such illegal accesses? Or is there a better practice to implement such web caching?
Thank you!
Kyeo
A better approach would be to cache images in a directory that is not accessible to the client (for example, a subdirectory of App_Data), then have a handler that streams the contents of files from this directory to authorized users.
If the files are specific to a user, you could for example store the images in folder names derived from the username:
App_Data\TempImages\User1
App_Data\TempImages\User2
Then the handler that streams the content will only stream files for the current logged on user, something like (modulo a bit of error handling):
string path = Path.Combine(
AppDomain.CurrentDomain.BaseDirectory,
"App_Data\TempImages",
HttpContext.Current.User.Identity.Name,
Request.QueryString["imageFileName"]);
... stream image at path if it exists ...
You could use the sessionId as an identifier instead of the username, but in this case the cached data will become inaccessible whenever the session times out.
I'm having some real issues in getting local files to open up via a browser using a custom protocol. Now before you shoot me for the custom protocol, this web app will be working in a closed intranet environment, so I have full control to add these protocols for all users. The app works fine at the moment, but I've been requested to bypass the Open / Save dialog for files as it's 'annoying' and 'time consuming' (yeah, I know...I tried to tell them), so here I am in uncharted territory!
Here's an example then of what's not working (I'm using Notepad in this example to test it in Server 2008 R2 with IIS7):
Using the info on Registering an Application to a URL Protocol I've added the following to the registry:
HKEY_CLASSES_ROOT
opentxt
(Default) = "URL:opentxt Protocol"
URL Protocol = ""
DefaultIcon
(Default) = "C:\Windows\System32\notepad.exe,1"
shell
open
command
(Default) = "C:\Windows\System32\notepad.exe" "%1"
So now, in theory, it should be as easy as having the following link in my html
Open File
And it does almost work - click on the link and it opens up Notepad instantly, however I'm presented with this error in notepad.
The filename, directory name, or volume label syntax is incorrect
The file definitely exists in that location (I can read it using http: //localhost/openme.txt), and I've tried to represent the link in as many different formats, such as described here but just can't get it to work.
Any ideas where I'm going wrong?
Quite simply, you're confusing your two different protocols.
Your protocol - and the Url that you pass to notepad - is opentxt://localhost/openme.txt. The working location of the file is http: //localhost/openme.txt. These two are not the same!
HTTP is a protocol that is natively understood by the operating system and, as such, Notepad can pass the HTTP Url to the operating system, which will in turn connect to localhost using port 80 and send a request for that resource. The file is returned, and Notepad has its data. This is all handled within operating system libraries that define the behaviour of HTTP.
Your opentxt protocol doesn't have this support unless you code it. Notepad doesn't know what to do with it - so you see your error message.
A way to handle this easily is to create your own application that handles the protocol. If you had an opentxtHandler.exe wired up through the registry, it would be passed the opentxt:// url, and can then process it appropriately. This might simply mean changing the protocol from opentxt to http and then passing it to Notepad - or it could be something more complex.