I use a firefox addon which makes hidden requests to a website. I already examined the code in all .js .xul and .xpi files. there is only 1 .xpt file (1kb) left where the request must be coded. now i want to open that to examine the code too.
.xpt is afaik a compiled .idl file
Can this be done?
How?
Thanks for your wisdom ;)
An XPT file is a compiled IDL file but it doesn't contain any code - it is merely an interface definition. It defines which properties and methods a component exposes but it doesn't define them - the actual definition of the component has to be in a JavaScript or DLL file. As you aren't mentioning any binary components, the component must be defined in the JavaScript files you already looked at.
In other words: the answer to "Can it be done" is: yes, with sufficient effort. Just looking at the strings contained in the file will already tell you the interfaces defined as well as the property and method names. If you need the parameters/parameter types then you will have to dig deeper. But for your purpose that would be pointless.
Related
I'm looking for something similar conceptually to a Windows DLL. As a concrete example, suppose I have a function encrypt that I would like to share across several unrelated projects. If I want to change the implementation ideally I can do so once and every project has access to the new implementation. Is there a mechanism for doing this in Node.js?
Have a look at this document especially the section "Writing a Library"
If you are writing a program that is intended to be used by others,
then the most important thing to specify in your package.json file is
the main module. This is the module that is the entry point to your
program.
and
If you have a lot of JavaScript code, then the custom is to put it in
the ./lib folder in your project.
Specify a main module in your package.json file. This is the module
that your users will load when they do require('your-library'). This
module should ideally expose all of the functionality in your library.
If you want your users to be able to load sub-modules from the "guts"
of your library, then they'll need to specify the full path to them.
That is a lot of work to document! It's better and more future-proof
to simply specify a main module, and then, if necessary, have ways to
dynamically load what they need.
For example, you might have a flip library that is a collection of
widget objects, defined by files in the flip/lib/widgets/*.js files.
Rather than having your users do require('flip/lib/widgets/blerg.js')
to get the blerg widget, it's better to have something like:
require('flip').loadWidget('blerg').
So I'm new to XUL.
As a language it seems easy enough and I'm already pretty handy at javascript, but the thing I can't wrap my mind around is the way you access resources from manifest files or from xul files. So I did the 'Getting started with XULRunner' tutorial... https://developer.mozilla.org/en/getting_started_with_xulrunner
and I'm more confused than ever... so I'm hoping someone can set me straight.
Here is why... (you may want to open the tutorial for this).
The manifest file, the prefs.js and the xul file all refer to a package called 'myapp', that if everything I've read thus far on MDN can be trusted means that inside the chrome directory there must be either a jar file or directory called myapp, but there is neither. The root directory of the whole app is called myapp, but I called mine something completely different and it still worked.
When I placed the content folder, inside another folder called 'foo', and changed all references to 'myapp' to 'foo', thus I thought creating a 'foo' package, a popup informed me that it couldn't find 'chrome://foo/content/main.xul', though that's exactly where it was.
Also in the xul file it links to a stylesheet inside 'chrome://global/skin/' which doesn't exist. Yet something is overriding any inline styling I try to do to the button. And when I create a css file and point the url to it, the program doesn't even run.
Can someone please explain what strange magic is going on here... I'm very confused.
When you register a content folder in a chrome.manifest you must use the following format:
content packagename uri/to/files/ [flags]
The uri/to/files/ may be absolute or relative to the location of the manifest. That is, it doesn't matter what the name of the containing folder is relative to your package name; the point is to tell chrome how to resolve URIs of the following form:
chrome://packagename/content/...
The packagename simply creates a mapping to the location of the files on disk (wherever that may be).
The chrome protocol defines a logical package structure, it simply maps one URL to another. The structure on disk might be entirely different and the files might not even be located on disk. When the protocol handler encounters an address like chrome://foo/content/main.xul it checks: "Do we have a manifest entry somewhere that defines the content mapping for package foo?" And if it then finds content foobar file:///something/ - it doesn't care whether that URL refers to a file, it simply resolves main.xul relatively to file:///something/ which results in file:///something/main.xul. So file:///something/browser.xul will be the URL from which the data will be read in the end - but you could also map a chrome package to another chrome URL, a jar URL or something else (theoretically you could even use http but that is forbidden for security reasons).
If you look into the Firefox/XULRunner directory you will see another chrome.manifest there (in Firefox 4/5 it is located inside omni.jar file). That's where the mappings for global package are defined for example.
After installing my files using WIX 3.5 I would like to changes some values in one of my xml files.
Currently there are multiple entries like this:
<endpoint address="net.tcp://localhost/XYZ" .../>
I would like to change the localhost to the real servername wich is available due to a property. How can I perform this replacement on each entry inside this xml file? Is there a way to do this without writing an own CA?
Thanks in advance!
XmlConfig and/or XmlFile elements are your friends here.
UPDATE: Well, according to the comments below, it turns out that only part of the attribute (or element) value should be changed. This seems not to be supported by either of two referenced elements.
I would take one of the two approaches then:
Use third-party "read XML" actions, like this one
It's better than creating your own because you can rely on deeper testing in this case
Teach your build script to control the string pattern
Let's say you put `net.tcp://localhost/XYZ` to build file and your code is pointed out to take this value as a string pattern to use at install time. For instance, keep the string pattern as a Property in your MSI package. When it changes, e.g. to `net.tcp://localhost/ABC` you'll have to change nothing in your action. In this case from a XMLFile perspective you always know your FROM and TO attribute values.
If your XML configuration file is not large, you can load the file into memory and perform replace using JScript.
var s = "<endpoint address=\"net.tcp://localhost/XYZ\" .../>";
var re = /"net.tcp:\/\/localhost\//g;
var r = s.replace(re, "\"http://newhost.com/");
Here s is your complete XML file, re is the regular expression, and r would contain the result or replace.
You can read and write to public properties of Windows Installer using JScript. Yet there's still one problem: you have to read your XML file and to write it back to disk. To do it, you can use Win32_ReadFile and Win32_WriteFile custom actions from the AppSecInc. MSI Extensions library referenced by Yan in his answer.
However, it could be easier to write a complete Custom Action which will load your XML configuration file, do the replace, and write the file back to disk. To do it you can use XSLT and JScript (see an example code).
InstallShield has a built-in data driven custom action called Text Search. It basically allows for RegEx style replacements like what you are describing.
WiX doesn't have this functionality but you could write a custom action ( say using C#/DTF ) to do it for you.
There nothing in Wix, you can do to change something in a file without using a custom action. If you don't want to use CA, you can consider saving the settings in some other place e.g. User's registry and always read that setting from there
Or at least describe about.aspx
For .aspx I assumed it stands for:
Active Server Page eXtended format
Though another opinion is that:
these files typically contain static (X)HTML markup, as well as markup defining server-side Web Controls and User Controls
Apparently it was the cool thing to do at time (the quote actually talks about the original name XSP, but doesn't rule it out as an option):
The initial prototype was called "XSP"; Guthrie explained in a 2007 interview that, "People would always ask what the X stood for. At the time it really didn't stand for anything. XML started with that; XSLT started with that. Everything cool seemed to start with an X, so that's what we originally named it."
For the office documents, since they are in XML format, it stands for XML.
I guess it stands for XML.
Since XML was used heavily in .NET Framework and later on in Open XML formats for Excel, Word.
If I was correctly informed, it stands for 'XML' - these files are renamed, zipped XML documents. That goes for .docx, .xlsx etc.; don't know about .aspx since that's web stuff.
They usually contain static XHTML
This is to indicate that it is a page contains (X)HTML and the rest of the code is in the code behind (e.g. about.aspx.cs or about.aspx.vb)
I'm attempting to use svcutil.exe to generate -only- the service contracts (interfaces) from a set of .wsdl files. When I do this (from an http-hosted wsdl), it picks up the included schemas and generates all the code for them.
Great.
What I would REALLY like to do, however, is to use a set of classes already generated from the schema files using the xsd.exe tool (the reasons for this are not important, suffice it to say that I need to have the types in one assembly, and the service contracts in another). I was successful in generating an assembly containing all the types.
The problem occurs when I attempt to get svcutil.exe to use the types in that assembly. My command line looks something like this:
svcutil /target:code /noconfig /reference:my_types.dll http://path/to/wsdl
This works fine, but the generated code contains duplicates of all the types in the my_types.dll file. It is my understanding from the documentation for svcutil.exe that this is the exact problem that the /reference: parameter is meant to overcome. In my case, however, it is not working.
Why?
Apparently it only works for DataContract types and not XmlSerializer types.
Link
I had this problem. Something in a binary that I was referencing with /r was still being built again in the generated code. One of the objects being returned from one of the service functions was returning a datatable or some other horrid thing like that. I added a /r to the whole path to System.Data and that fixed it.
/r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.2\System.Data.dll"