I am working on a project I intended as an academic exercise for myself. What I am basically doing is trying to add a custom compression type between an IIS server and a web browser, but getting mired in the browser aspects of it. What is basically needed is to be able to alter the byte stream on the server before it is sent to the client, and on the client browser side, be able to alter received response byte stream before other normal DOM parsing and such take place. On the server side this turned out to be pretty trivial, but I am at a loss in how to do this in chrome or firefox. If anyone has insight for chrome, please share, but I'll focus on Firefox for now. My understanding is that previously Firefox had rather low level access available to extensions but that they are tightening the restrictions a bit going forward with their Firefox add-on sdk. I don't want to bother learning the old methods if they are slated to be removed so does anyone definitively know if the add-on sdk allows you to alter the byte stream directly in this manner? If so, do you have an example of such usage?
(I am aware that I need to have the compression negotiated with the Accept-Encoding header)
I don't want to bother learning the old methods if they are slated to be removed
There are no plans now, or in the future, to remove legacy add-on support. At least that's what add-on SDK folks and extension manager folks told me repeatedly.
Back to your question: The add-on sdk does not provide an explicit API for stuff like this, but you can always go even more low-level, even in the SDK (via the chrome module and/or window/utils).
To implement additional compression methods, you'd need to implement the nsIStreamConverter interface and properly register your component under the #mozilla.org/streamconv;1#?from=<yourcompression>&to=uncompressed contract. Then Firefox should be able to decode yourcompression.
See https://developer.mozilla.org/ for more information on how to implement and register XPCOM components in either javascript or C++.
Using the SDK or implementing your add-on restartless will require you register the component yourself instead of relying on chrome.manifest. There are a couple of add-on doing so already, e.g. Adblock Plus.
Binary (C++) components should be avoided because you'll obviously need to compile your component for each supported platform and you'll need to re-compile it for each Gecko version. If you have to go binary, a javascript component stub + js-ctypes might be better.
See the mozilla source code on how to implement nsIStreamConverter in the first place.
You may also need to modify the network.http.accept-encoding preference so that the compression may be actually negotiated with the server.
Related
I'm researching reliable ways to programmatically control instances of Chrome/Chromium to leverage its capabilities of rendering web pages in Node.js/C#/Java application. In short, things I want to do are as follows:
Open/close a browser window.
Minimize, maximize browser window.
Navigate to a certain URL.
Set cookies.
To make it more clear: I need a headful browser to display web pages to the end users. It can be either embedded to my app or can be a standalone browser (separately shipped instance of Chromium for example).
I was not able to find information about any public APIs in Chrome/Chromium that I can use from the Node.js/C#/Java environment. The ones available for Chrome Extensions are not applicable to my project, as I want to control the browser from the outside, like Selenium WebDriver does for example. So far I found the following ways to control the browser the way I need:
To use Puppeteer/WebDriver APIs.
Use chrome-remote-interface NodeJS library.
Rely on Chrome Embedded Framework capabilities.
Rely on Electron.js capabilities.
Build my own library that somehow includes the Chromium modules as dependencies (similar to what Electron team implemented for example).
First two options are similar from the perspective of all the mentioned libraries eventually leveraging Chrome Devtools Protocol. The risk of CDP being retired/deprecated is quite substantial for our project. The other concern is that the intention of CDP is debugging and test automation and not application development. Moreover, having an open debugging port in Chrome open on user's machine seems vulnerable.
CEF and Electron paths concern me due to dependency on the embedded Chromium updates cadence. Although Electron team is targeting to update with every other release of Chromium it still can be a security concern due to inability to update the Chromium version right after a new version released with a security patch, for example. Moreover, in case when I need the real browser experience (and that's the case) I won't have it out of the box and I'll have to implement browser features like buttons, tabs address bar etc. myself.
Option #5 seems to be extremely complex in implementation as it seems to require team's competency on Chromium internals, C++ development and C++ build tooling.
Anything I missed in the options list? Anything I missed in my assumptions? Any tips, thoughts, suggestions will be greatly appreciated!
Some of your options are about controlling a browser (#1, #2) while others are about embedding a browser (#3, #4). These are two different use cases and what you need depends on what your goal is.
Controlling a browser
If you want to control a browser to execute tasks, maybe even in the background without the end user noticing, you should go for option 1 (puppeteer) or 2 (chrome-remote-interface).
I recommend to use puppeteer as this is the library developed by the Google Chrome developers and it comes with many functions for your use case (opening browser windows, navigating, setting cookies).
I do not see any reason to worry about the Chrome DevTools Protocol being abandoned anytime soon. The Chrome DevTools fully rely on this protocol. In addition, Firefox (Mozilla bug tracker: #1316741,#1523097) and Edge are already partly supporting the protocol making it even more unlikely to be abandoned in the future. (more information)
Embedding a browser
If you need to embed a browser, meaning you are trying to show a browser inside your application, you should focus on the options 3 (Chrome Embedded Framework) or 4 (Electron).
The Chrome Embedded Framework is a more low-level approach putting a separate browser into your application. But I cannot go into detail here, as I have never used this one myself.
Electron on the other hand is a browser, meaning the whole application is developed as web application. You can embed another browser window (webview) into your browser, which you can essentially control (similar to what puppeteer can do).
Directly using the Chromium code (option 5)
Although the Chromium project is split into multiple components, it sounds like you need a full browser. I once compiled the Chromium source code myself and it takes literally hours. Keep in mind, that he code consists of roughly 35 million lines of code (source). Even if you figure out what parts of the code to use, it is more realistic that some low-level parts of the code change and break your implementation than the DevTools Protocol being abandoned. So, I definitely recommend to not follow this idea.
Alternatives
Depending on your use case, you could also take a look at DOM simulation libraries like jsdom or cheerio. These libraries are very limited in terms of their functionality and you might have to implement parts of the browser yourself, e.g. downloading the document, reading and setting headers to deal with cookies, etc.
All in all, I recommend to go for puppeteer if you want to control a browser to execute tasks primarily in the background. If you need a browser window as part of your application go for Electron.
I want to write a web app that can process a users presentation which when submitted, gets sent to their local system printers - one part of the order will go to B&W laser printer and another part goes to another printer for another process.
Ideally, this will be able to run on any of the major systems - Linux, OSX or Windows.
It could be a packaged Chrome or Firefox app or extension, but I can't tell if there is sufficient access to the system printers. (I can see all the printers available to my current chrome installation - but are they available to an extension?). I can't see the code in any demos or libraries.
I've seen reference to NPAPI, but I can't tell if that's what I need either - if so would I need to write an app for each of the major platforms or each kind of printer?
In Firefox it is possible to print from an extension. Using only javascript, that is (you're free to mess about with C++ if you like).
Extensions are essentially the browser: Everything the browser can do, an extension can, too.
There is however not much documentation about using the printer. To be precise, there is none that I'm aware of. However, the browser is open source, and the UI is mostly Javascript, so you can just read the code.
printUtils.js would be a good starting point to check out how this might work. Also there is a component implementing nsIPrinterEnumerator. See the firefox-addon info section for a collection of "Getting started" and documentation resources about add-on development in general.
I don't think the Chrome extension API provides ways to control printing the way you'd need.
The NPAPI plugin API does not provide enough control over printing. You just basically get a buffer to draw into, but no way to control printing setting or initiate printing yourself. You could cheat of course, and have your plugin directly print something via OS bypassing the browser, like e.g. those PDF readers do. However, it should be noted that NPAPI plugins are the past... Don't develop new ones, if possible.
I need to make an if statement using Ruby that checks to see if the client's browser support HTML5 or not.
Short version: you won't be able to, nor should you.
Long version: It may be possible, if you do some user-agent sniffing, to identify whether or not the user's browser supports HTML5 or not. But this would take a fair amount of effort to get right. The better solution is to use something like Modernizr (http://www.modernizr.com/) to do your feature detection on the client-side.
It's possible to read the browser info based on the HTTP_USER_AGENT string, but, as mentioned above and many other places, it's also really easy to spoof that info. On the server-side we only cared because it gave us an overall view of the client browsers being used to access our sites.
Trying to react to a browser on the backend and present different content was tried by sites for a while, but it fails because of how browsers spoof other browsers, but don't have the same bugs.
As #Stephen Orr said, CSS is a better way of dealing with it. Sure it's hell and still error-prone, but it's better than sniffing the browser's signature. We used to cuss every release of IE because it broke the previous fixes. Luckily things seem to be getting better as the vendors creep toward toeing standards.
Most features can be detected (with JavaScript), but some kinds like the form-date-feature field is a problem: http://united-coders.com/matthias-reuter/user-agent-sniffing-is-back
It is possible to do Feature detection on HTML5, to detect single features from HTML5 as you need them. There is, however, no way to detect if a browser supports HTML5 as one big chunk - as there is no "official" way to tell if a browser supports all of HTML5 or just parts of it.
< [html5 element] id="somethingtobedazzledby">
Upgrade your browser
</ [html5 element] >
I need loging all HTTP request (from any application).
I have Delphi 7.0.
Anybody know how do that?
I looked into whether the Indy components could do this but found an old newsgroup response from Remy Lebeau that said:
If...you want to look at the traffic
that other applications are
generating, then no, you cannot use
Indy for that. That is outside the
scope of what Indy is designed for.
You would have to write your own NDIS
driver for that kind of capturing. Or
use a third-party sniffer API, such as
WinPCap.
What about WireShark?
There is also a product called Fiddler. I have found this extremely useful to track down exactly what the Indy components are sending/receiving. The one drawback is you have to utilize a proxy. This isn't a problem with Indy components and browsers such as Firefox. But if you need to capture for all applications you would need to be able to set a proxy for those apps.
if you want to go deeper and want pure delphi thing, there is winsock logger program floating around, google might help you ( it hooks winsock apis though).
Do you have to write a Delphi app to do it? Could you use an application like ethereal?
Does anyone have experience integrating SmartCard authentication in their Win32 apps? If so, are there any preferred libraries?
Try SecureBlackbox, A component that works fine for me, a second choice can be
Delphi PC/SC SmartCard Component 0.91.
try
Well I guess that you have an SmartCard reader ... if so (and if you don't have one I don't know how you are going to manage this) then it must have some interface, RS232, USB, TCP/IP ... any one will do.
Communication protocol usually is available at SmartCard reader manufacturer. Few lines, and you will have it working in Delphi.
You need to read the developer manual that comes with reader you're going to use. It might only use PC-SC (by MS) to communicate, if so you can use the component specified by RRUZ, however it doesn't work with D2009. Otherwise you'll need to use API provided by SDK.