754891 - RFE: Add option to add MAC Address header to HTTP queries

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[Michal Novotny [:mig]]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.24 Safari/536.5

Steps to reproduce:

This is just a request for enhancement (I already wrote the code for both Linux and Windows) to extend the HTTP requests by custom header containing active interface the MAC Address.


Actual results:

Nothing


Expected results:

Header added:

X-MAC-Addresses: eth0=00:11:22:33:44:55; eth1=11:22:33:44:55:66

This is *not* a security feature since headers can be easily changed however it's been designed for VM instance identification by it's MAC address - security is not required here, just simple identification in the cluster/virtualization testing environment.

Comment 1

[Michal Novotny [:mig]]

Attachment: Add X-MAC-Addresses optional header when enabled

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: 
Fix Landed on Version:
Risk to taking this patch (and alternatives if risky): 
String changes made by this patch:

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

[Approval Request Comment]
Regression caused by (bug #): 
User impact if declined: 
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky):

[Approval Request Comment]
Regression caused by (bug #): 
User impact if declined: 
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky):
String changes made by this patch:

Comment 2

[Michal Novotny [:mig]]

Comment on attachment 623705 [details] [diff] [review]
Add X-MAC-Addresses optional header when enabled

I'm a little confused by the patch submitting process and never sent a patch to Firefox yet. I'd like to ask whether it's fine and how to put it on the automated testing. I did the testing myself already however it was not easy. Any help appreciated!

Thanks!
Michal

Comment 3

[Patrick McManus [:mcmanus]]

Comment on attachment 623705 [details] [diff] [review]
Add X-MAC-Addresses optional header when enabled

Michal, thanks for the patch.

I turned off the approval? flags because you almost certainly don't want them. They are used to get approval to backport code - which basically doesn't happen with features. In any event you would need it merged to nightly first, and then you ask for approval to backport.

As for the code itself - this kind of cool but extremely niche feature seems perfect for an addon. Especially given that it is off by default. Did you look at that approach?

Comment 4

[Michal Novotny [:mig]]

(In reply to Patrick McManus [:mcmanus] from comment #3)
> Add X-MAC-Addresses optional header when enabled
> 
> Michal, thanks for the patch.


You're welcome! I've love to participate in the Firefox/Thunderbird coding in my spare time :-)


> 
> I turned off the approval? flags because you almost certainly don't want
> them. They are used to get approval to backport code - which basically
> doesn't happen with features.

Ah, I didn't know that. Thanks for clarification.


> In any event you would need it merged to
> nightly first, and then you ask for approval to backport.
> 
> As for the code itself - this kind of cool but extremely niche feature seems
> perfect for an addon. Especially given that it is off by default. Did you
> look at that approach?


Yeah, I did however I'm not sure how to modify the headers from within the add-on code. Any idea/clue/link?

Also, is it possible to change both read and written body of the message, and most likely in the add-on form?

Thanks!
Michal

Comment 5

[Michal Novotny [:mig]]

(In reply to Michal Novotny [:mig] from comment #4)
> (In reply to Patrick McManus [:mcmanus] from comment #3)
> > Add X-MAC-Addresses optional header when enabled
> > 
> > Michal, thanks for the patch.
> 
> 
> You're welcome! I've love to participate in the Firefox/Thunderbird coding
> in my spare time :-)
> 
> 
> > 
> > I turned off the approval? flags because you almost certainly don't want
> > them. They are used to get approval to backport code - which basically
> > doesn't happen with features.
> 
> Ah, I didn't know that. Thanks for clarification.
> 
> 
> > In any event you would need it merged to
> > nightly first, and then you ask for approval to backport.
> > 
> > As for the code itself - this kind of cool but extremely niche feature seems
> > perfect for an addon. Especially given that it is off by default. Did you
> > look at that approach?
> 
> 
> Yeah, I did however I'm not sure how to modify the headers from within the
> add-on code. Any idea/clue/link?
> 
> Also, is it possible to change both read and written body of the message,
> and most likely in the add-on form?
> 
> Thanks!
> Michal

Any ideas and/or hints how to do extension that incorporates the multi-platform source code like my patch does?

Michal

Comment 6

[Patrick McManus [:mcmanus]]

Comment on attachment 623705 [details] [diff] [review]
Add X-MAC-Addresses optional header when enabled

Hi Michal,

So I definitely think this is something too niche to include in core necko - but I've feedback? queried Christian who is the necko module owner to make sure he feels similarly.

I'm not a big add-on expert (I'll cc mfinkle) but this seems like it should be doable with (a js-ctype wrapper plus jetpack) or binary xpcom. What's the barrier to that? The build system?

Comment 7

[Patrick McManus [:mcmanus]]

mark, I wonder if you would have any comments on how an add-on could approach this patch?

Comment 8

[Michal Novotny [:mig]]

(In reply to Patrick McManus [:mcmanus] from comment #7)
> mark, I wonder if you would have any comments on how an add-on could
> approach this patch?

Well, considering the approach of supporting both Linux and Windows systems I designed to be rather part of core system than the extension. For extension we should be having 2 versions of the extension, one with the special library in DLL form for Windows, second as shared object for Linux. Wouldn't it be nicer to have it implemented directly in Firefox without a need for extension then?

Michal

Comment 9

[Patrick McManus [:mcmanus]]

(In reply to Michal Novotny [:mig] from comment #8)

> 
> Well, considering the approach of supporting both Linux and Windows systems
> I designed to be rather part of core system than the extension. For
> extension we should be having 2 versions of the extension, one with the
> special library in DLL form for Windows, second as shared object for Linux.
> Wouldn't it be nicer to have it implemented directly in Firefox without a
> need for extension then?
> 

maybe jorge knows how the scoop on writing/packaging cross platform addons with binary components.

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

You can find information on adding headers to outbound HTTP requests here:
https://developer.mozilla.org/en/Setting_HTTP_request_headers

As for getting the MAC address, you could stick with a binary component, but js-ctypes should be able to work too. It's just harder to get js-ctypes setup to access the native data types.

Comment 11

[Michal Novotny [:mig]]

(In reply to Mark Finkle (:mfinkle) from comment #10)
> You can find information on adding headers to outbound HTTP requests here:
> https://developer.mozilla.org/en/Setting_HTTP_request_headers
> 
> As for getting the MAC address, you could stick with a binary component, but
> js-ctypes should be able to work too. It's just harder to get js-ctypes
> setup to access the native data types.


Ok, thanks for the information however I'd really welcome some working example with a proper Makefile etc. as I'm not sure how is it meant.

I did try to have a look to:

[1] https://developer.mozilla.org/en/How_to_Build_an_XPCOM_Component_in_Javascript
[2] https://developer.mozilla.org/en/XPIDL/xpidl

But I even don't have any xpidl tool and even in the sources of Firefox trunk I'm not able to find such a binary. Just the python site-package could be found however it doesn't support arguments like mentioned on [1]. I may be able to find them in some Fedora devel repositories, something like xulrunner-devel or similar. I didn't check yet, however some example with *working* Makefile and up-to-date README file would be really appreciated.

Also, having a support of both Linux and Windows environments would require having both shared objects (*.so) and dynamically linked libraries (*.dll) put to the archive with the extension so this is basically the reason of having the separate versions for extensions for Linux/Windows/MacOSX not to support all in one extension. For getting the MAC addresses the extension should be really small so it *may* be possible to have it all in one piece however I am not sure yet.

Thanks!
Michal

Comment 12

[Michal Novotny [:mig]]

I did try to make it working using following example [1] however it cannot compile and I've been having many issues downloading and getting xpidl (written in Perl CORBA:IDL and CORBA::XPIDL) working but even after this the code is not OK yet. I also tried to have a look to developer.mozilla.org for a full example, ideally in the tar.gz package. I have tried to use Makefile from [2] with several alterations to generate the header and typelib from IDL file however still no luck:

$ make
xpidl -m header -I/home/mig/Work/firefox/src/obj-x86_64-unknown-linux-gnu/dist/idl IMyComponent.idl
xpidl -m typelib -I/home/mig/Work/firefox/src/obj-x86_64-unknown-linux-gnu/dist/idl IMyComponent.idl
c++ -c -fno-rtti -fno-exceptions -fshort-wchar -fPIC   -include mozilla-config.h -DMOZILLA_STRICT_API -DXPCOM_GLUE -I/home/mig/Work/firefox/src/obj-x86_64-unknown-linux-gnu/dist -I/home/mig/Work/firefox/src/obj-x86_64-unknown-linux-gnu/dist/idl -I/home/mig/Work/firefox/src/obj-x86_64-unknown-linux-gnu/dist/include -I/home/mig/Work/firefox/src/obj-x86_64-unknown-linux-gnu/dist/xpcom/include -I/home/mig/Work/firefox/src/obj-x86_64-unknown-linux-gnu/dist/nspr/include -I/home/mig/Work/firefox/src/obj-x86_64-unknown-linux-gnu/dist/string/include -I/home/mig/Work/firefox/src/obj-x86_64-unknown-linux-gnu/dist/embedstring/include MyComponent.cpp
In file included from MyComponent.h:4:0,
                 from MyComponent.cpp:1:
IMyComponent.h:28:49: error: macro "NS_DEFINE_STATIC_IID_ACCESSOR" requires 2 arguments, but only 1 given
IMyComponent.h:28:3: error: ‘NS_DEFINE_STATIC_IID_ACCESSOR’ does not name a type
make: *** [MyComponent.o] Error 1
$

Any help appreciated!
Michal

[1] http://www.iosart.com/firefox/xpcom/
[2] https://developer.mozilla.org/en/Creating_XPCOM_Components/Setting_up_the_Gecko_SDK#A_Makefile_for_Unix

Comment 13

[Michal Novotny [:mig]]

Ok, when using this patch I've been able to move on that it's failing on message it cannot find "nsIGenericFactory.h" header file but this file doesn't exist anywhere in the trunk repository. Did the approach change? Unfortunately I got really stuck with this one and I'd need some working guide for add-on. To write a patch in C/C++ it's pretty easy for me in comparison with trying to write the XUL extensions however I have to admit that the default-disabled approach implies the extension is better (if possible).

--- a/IMyComponent.h
+++ b/IMyComponent.h
@@ -25,12 +25,14 @@
 class NS_NO_VTABLE IMyComponent : public nsISupports {
  public: 
 
-  NS_DEFINE_STATIC_IID_ACCESSOR(IMYCOMPONENT_IID)
+  NS_DECLARE_STATIC_IID_ACCESSOR(IMYCOMPONENT_IID)
 
   NS_IMETHOD Add(PRInt32 a, PRInt32 b, PRInt32 *_retval) = 0;
 
 };
 
+NS_DEFINE_STATIC_IID_ACCESSOR(IMyComponent, IMYCOMPONENT_IID)
+
 /* Use this macro when declaring classes that implement this interface. */
 #define NS_DECL_IMYCOMPONENT \
   NS_IMETHOD Add(PRInt32 a, PRInt32 b, PRInt32 *_retval);

Any pointers to a working example?
Michal

Comment 14

[Michal Novotny [:mig]]

Any news on this one?

Michal

Comment 15

[Patrick McManus [:mcmanus]]

wont take for fingerprinting reasons.. addons can manipulate request headers