[Fetch API] Headers.get("WWW-Authenticate") does not return anything, if server sends more than one such header
I encountered something strange. I am on TB60 trying to use the Fetch API.
I create a GET or POST request without authentication and get back a 401 from
the server and use
response.headers.get("WWW-Authenticate")
to eval the allowed authentication methods. This works fine, if the server
sends only one such header. If however he sends two or more,
Headers.get("WWW-Authenticate") returns null.
I only observe this for the WWW-Authenticate header, other headers - if send
multiple times - will simply be returned as a list (joined by colon).
Is this a bug? Am I doing something wrong?
This is a example set of headers, that is not accessible:
WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm="Contact and Calendar data"
Also: Why was Headers.getAll() dropped after Gecko 52? The digest auth header
includes colons himself and if it is returned joined into a list together with
some other auth method, it will be very difficult to parse that.
Thanks for your help,
John
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: [Fetch API] Headers.get("WWW-Authenticate") does not return anything, if server sends more than one such header
I created a bug https://bugzilla.mozilla.org/show_bug.cgi?id=1491010 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
What is the future of XMLHttpRequest.mozAnon ?
Is mozAnon going to stay or are you thinking about removing that in the future? https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/mozAnon Thanks for your time, John ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is the future of XMLHttpRequest.mozAnon ?
CromeOnly means, I can continue to use from (Thunderbird) AddOns, but not from a website? That would be ok. But removing it altogether would be a loss, because (with that mozAnon option) XHR has advantages in other features over fetch(). If I could vote, I would like to +1 for keeping it :-) Thanks for your time, John ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is the future of XMLHttpRequest.mozAnon ?
> Isn't this the same as supplying the crossOrigin:anonymous option to > fetch()? That is true, that is why I wrote "in other features". For example, if multiple www-authenticate headers are send, fetch will return them as a list joined by "," while XHR returns them as a list joined by "\n". Since a digest auth header includes "," itself, XHR is for me the better option here. Also I have not yet been able to eval cert errors on connections with fetch(), which I can do with XHR. For fetch() I just get a general network error. Maybe there is a way, but I have not found it yet. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is the future of XMLHttpRequest.mozAnon ?
I do not think they will change that. RFC 7230 defines that behavior and the digest auth header is actually not a valid header in that respect. The mozilla impl. actually had a "getAll" method, which returned an array instead of a list. But that was non-standard and got removed. But we are getting off-topic :-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is the future of XMLHttpRequest.mozAnon ?
N! You may fix fetch() to support multiple auth headers again, but do not change how XHR returns them :-) What have I done ... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What is the future of XMLHttpRequest.mozAnon ?
So to summarize this topic and all the things that are currently going on: - mozAnon is not to stay forever, because XHR is superseded by fetch() wich has an option for that as well - XHR.getResponseHeader() is going to be adjusted to match fetch() [= returning a comma-joined list] so using XHR because of the current behavior [= returning a \n-joined list] is not advised Since it was brought up already in this topic, how can I eval cert errors with fetch()? For XHR I can get the underlying channel and request a nsresult: xhr.channel.QueryInterface(Components.interfaces.nsIRequest).status Is there a way to do something like this with a fetch() response? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
mozilla-esr60 fails to build on windows
I was able to build mozilla-central on my Windows 10, but Mozilla-esr60 fails: John@R2D2 ~/Documents/Mozilla/source60 $ ./mach build 0:02.31 Clobber not needed. 0:02.32 Adding make options from None MOZ_OBJDIR=c:/Users/John/Documents/Mozilla/source60/obj-i686-pc-mingw32 OBJDIR=c:/Users/John/Documents/Mozilla/source60/obj-i686-pc-mingw32 0:02.37 c:\mozilla-build\bin\mozmake.EXE -f client.mk -s configure 0:02.55 cd c:/Users/John/Documents/Mozilla/source60/obj-i686-pc-mingw32 0:02.57 c:/Users/John/Documents/Mozilla/source60/configure 0:03.37 Reexecuting in the virtualenv 0:03.89 checking for vcs source checkout... hg 0:04.08 checking for a shell... C:/mozilla-build/msys/bin/sh.exe 0:05.38 checking for host system type... i686-pc-mingw32 0:05.38 checking for target system type... i686-pc-mingw32 0:05.42 checking for a shell... C:/mozilla-build/msys/bin/sh.exe 0:06.70 checking for host system type... i686-pc-mingw32 0:06.70 checking for target system type... i686-pc-mingw32 0:06.78 checking for vcs source checkout... hg 0:06.78 checking whether cross compiling... no 0:06.88 checking for the target C compiler... 'C:/PROGRA~2/MICROS~3/2017/COMMUN~1/VC/Tools/MSVC/1415~1.267/bin/HostX64/x86/cl.exe' 0:07.14 checking whether the target C compiler can be used... yes 0:07.20 checking for Python 3... c:\mozilla-build\python3\python3.EXE (3.6.5) 0:07.20 checking for hg... c:/mozilla-build/python/Scripts/hg.exe 0:07.85 checking for Mercurial version... 4.7.1 0:08.16 checking for sparse checkout... no 0:08.18 checking for pkg_config... not found 0:08.18 checking for yasm... c:/mozilla-build/bin/yasm.exe 0:08.19 checking yasm version... 1.3.0 0:08.19 checking the target C compiler version... 19.15.26729 0:08.25 checking the target C compiler works... yes 0:08.26 checking for the target C++ compiler... 'C:/PROGRA~2/MICROS~3/2017/COMMUN~1/VC/Tools/MSVC/1415~1.267/bin/HostX64/x86/cl.exe' 0:08.32 checking whether the target C++ compiler can be used... yes 0:08.32 checking the target C++ compiler version... 19.15.26729 0:08.38 checking the target C++ compiler works... yes 0:08.40 checking for the host C compiler... 'C:/PROGRA~2/MICROS~3/2017/COMMUN~1/VC/Tools/MSVC/1415~1.267/bin/HostX64/x86/cl.exe' 0:08.46 checking whether the host C compiler can be used... yes 0:08.46 checking the host C compiler version... 19.15.26729 0:08.58 checking the host C compiler works... yes 0:08.61 checking for the host C++ compiler... 'C:/PROGRA~2/MICROS~3/2017/COMMUN~1/VC/Tools/MSVC/1415~1.267/bin/HostX64/x86/cl.exe' 0:08.70 checking whether the host C++ compiler can be used... yes 0:08.71 checking the host C++ compiler version... 19.15.26729 0:08.87 checking the host C++ compiler works... yes 0:08.94 checking for 64-bit OS... no 0:08.94 checking bindgen cflags... no 0:09.03 checking for Windows SDK... 0x0a00 in 'C:\Program Files (x86)\Windows Kits\10\' 0:09.03 checking for Universal CRT SDK... 10.0.17134.0 in 'C:\Program Files (x86)\Windows Kits\10\' 0:09.05 checking for the Debug Interface Access SDK... C:/PROGRA~2/MICROS~3/2017/COMMUN~1/DIA SDK 0:09.07 checking for mt... 'C:/PROGRA~2/WI3CF2~1/10/bin/100171~1.0/x64/mt.exe' 0:09.09 checking whether MT is really Microsoft Manifest Tool... yes 0:09.10 checking for linker... 'C:/PROGRA~2/MICROS~3/2017/COMMUN~1/VC/Tools/MSVC/1415~1.267/bin/HostX64/x86/link.exe' 0:09.12 checking for makecab... c:/WINDOWS/System32/makecab.exe 0:09.15 checking for fxc... 'C:/PROGRA~2/WI3CF2~1/10/bin/100171~1.0/x64/fxc.exe' 0:09.26 checking for stdint.h... yes 0:09.38 checking for inttypes.h... yes 0:09.49 checking for malloc.h... yes 0:09.55 checking for alloca.h... no 0:09.63 checking for perf_event_open system call... no 0:09.69 checking for rustc... c:/Users/John/.cargo/bin/rustc.exe 0:09.69 checking for cargo... c:/Users/John/.cargo/bin/cargo.exe 0:09.81 checking rustc version... 1.29.0 0:09.93 checking cargo version... 1.29.0 0:10.10 Traceback (most recent call last): 0:10.11 File "c:/Users/John/Documents/Mozilla/source60/configure.py", line 127, in 0:10.11 sys.exit(main(sys.argv)) 0:10.11 File "c:/Users/John/Documents/Mozilla/source60/configure.py", line 29, in main 0:10.11 sandbox.run(os.path.join(os.path.dirname(__file__), 'moz.configure')) 0:10.11 File "c:\Users\John\Documents\Mozilla\source60\python\mozbuild\mozbuild\configure\__init__.py", line 428, in run 0:10.11 func(*args) 0:10.11 File "c:\Users\John\Documents\Mozilla\source60\python\mozbuild\mozbuild\configure\__init__.py", line 474, in _value_for 0:10.12 return self._value_for_depends(obj, need_help_dependency) 0:10.13 File "c:\Users\John\Documents\Mozilla\source60\python\mozbuild\mozbuild\util.py", line 944, in method_call 0:10.13 cache[args] = self.func(instance, *args) 0:10.13 File "c:\Users\John\Documents\Mozilla\source60\python\mozbuild\mozbuild\configure\__init__.py", line 483, in _value_for_depends 0:10.14 return o
nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method
Hi, today I wanted to authenticate a PROPFIND against https://contacts.icloud.com which returns the following WWW-Authentication header: WWW-Authenticate: X-MobileMe-AuthToken realm="Newcastle", Basic realm="Newcastle" Usually, on a fresh/new connection, nsIHttpChannel will first do an unauthenticated request, get the auth methods to pick one, call promptAuth callback to ask for password and then initiate a second request to try to actually authenticate. However, it looks like, nsIHttpChannel is not calling promptAuth and is not doing that second request. As if the there is no valid auth method returned by the server. I replicated that WWW-Authentication header on one of my own servers, reproduced the findings and than removed the X-MobileMe-AuthToken from the allowed methods (so just sending Basic) and tried again to connect and this time it went through as expected. Is this a bug? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method
FYI: I observed this with Thunderbird 60.3.1 (the current stable release)
Is this related to
https://bugzilla.mozilla.org/show_bug.cgi?id=1491010
I reported this bug because fetch()'s response.headers.get("WWW-Authenticate")
returned "null" if TWO such headers are received (as you suggested).
In the course of that bug, they discussed how to return such headers and
decided to flatten them and return them as a list separated by ", ". This is
according to the specs.
Furthermore they realized, that XHR currently is NOT flattening such multiple
WWW-Authenticate headers, but returns them as a list separated by "\n". They
decided to change that. This forces all XHR users to manually split
WWW-Authenticate headers (which is complicated, as you pointed out). But it is
according to the specs, so we have to live with that.
Now it looks like that nsIHttpChannel itself is not able to split
WWW-Authenticate headers?
Should I add a link to this thread to the existing bug?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method
@Anne van Kesteren Thanks for your feedback. As you have the much deeper knowledge about these thinks, I think it would be better if you file that bug? I think you can get the report much more to the point than I could describe it? Related Question: In my Add-On I made the transition from fetch() to nsIHttpChannel to get around the reported bug. But now I am stuck again :-) Is there a flag in the channel somewhere I can check after getting the 401, if nsIHttpChannel did not find any valid auth method, so I can try to manually parse the header in that case (until this is fixed)? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method
@Anne van Kesteren
Solved that by checking getRequestHeader("Authorization") in case of 401 and if
that is missing, I know nsIHttpChannel did not try to authenticate.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method
I have a working impl. now and just looking at 401 is not sufficient. The user could indeed have provided a wrong password. The only way to know, if the 401 was caused because nsIHttpChannel did not even try to authenticate, is by checking wether it has send a Authorization header back to the server. If not, I can manually check the WWW-Authentication header and manually check for BASIC and reinitiate the request and manually add the BASIC auth header. For me it would be interesting to understand, if you consider the header send by contacts.icloud.com to by invalid, even though it fully complies with the spec. If i remember, the same spec is the reason why you are changing XHR to return the list no longer as "\n" separated, but as "\," separated? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method
I mean ", " separated of course. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method
This should be decided once and for all. The complicated parsing of ", " separated auth headers was exactly my argumentation against changing XHR's behaviour. But it was discarded. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Inquiry: What about making fetch() auto-contained by username?
That title is a bit bulky, but it is hard to find a one line summary for this thread :-) After having understood how originAttributes and containers work with nsIHttpChannel, I was finally able to fix all sorts of connection problems. I am now able to isolate connections to the same host but with different usernames and provide them with isolated cookie caches and credential caches. At the moment however it looks like, as this great functionality is only available using nsIHttpChannel and thus is only avail for privileged code, but not to places, where only fetch() aor XHR is usable. As fetch() seems to be the future, I will only talk about fetch() in this thread, but one could think about the same for XHR. It is a general question of how to handle multiple connection to the same host for different users. 1) I do NOT want to propose to change the fetch() interface or its spec, just its internal handling. This proposal is not violating the fetch() spec (afaik). 2) I want to propose, that fetch() will use containers per default in a way, that connections to the same host but with different usernames never share the same container. The base for this proposal is, that I cannot think of any use case, where it is actually desired to share (for example) the cookie cache for such connections. It will always lead to authorization stealing and things like that. 3) I do not want to expose the container management but let fetch() take care of selecting the correct userContextId. What do you think about this? Thanks for your time, John ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Authentication strategy for servers, which do not return a 401 on unauthenticated requests
nsIHttpChannel is usually doing an unauthenticated request to a remote URL to get the WWW-Authentication header from the 401 response and then pick one of the allowed methods to authenticate. I am running into an issue, where the server is not returning a 401 but actually returns a result for anonymous access (even though the URL points to a /user/xy/ resource). What is the strategy to enforce authentication? I do not want to manually add a Basic Auth header, as I want nsIHttpChannel to do all the auth stuff. What can I do? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests
Thanks for your reply. I do not want to manually add a `Authentication` request header, as I also do not know what methods are allowed without having seen the WWW-Authentication header (and just trying basic auth is not an option for me). I was hoping there was some established mechanism to force the server to send that header, without sending wrong credentials on purpose. It looks like there is nothing I can do. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests
No, the server is not controlled by me. The admin expects clients to send a Basic Auth header without having seen the WWW-Authenticate header, if I do not want to access the resource unauthenticated. For me this looked wrong from the beginning, but just wanted to make sure I am not missing anything. I there an established header I could send, to enforce the return of WWW-Authenticate header? If so, I would forward that info to the admin for him to implement, otherwise I would call this done. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Authentication strategy for servers, which do not return a 401 on unauthenticated requests
Alternatively, the admin wants me to send a bogus authenticate header, like Authenticate: X to trigger the authentication. I really do not like that. Maybe I can get him to jump into the discussion. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Equivalent for XMLHttpRequest.overrideMimeType() in the world of nsIHttpChannel
I am working on a wrapper for nsIHttpChannel with the interface of MLHttpRequest. Mainly to be able to use the codeBbasePrincipal (or ContextPrincipal as it is called now I think) with XHR requests, but without authors having to rewrite their code. This is for Thunderbird Add-Ons, which still can access nsIHttpChannel. I am pretty far and it is working nicely. However, I was not able to find a place in the nsIHttpChannel specification, which I could map to XMLHttpRequest.overrideMimeType() Is there any option/requirement to manually overide the MimeType of responses received via a nsIStreamListener or a nsIStreamLoaderObserver. The wrapper is here, if you want to have a look: https://gitlab.com/jobisoft/CardBook/blob/Thunderbird67+/chrome/content/cardbookHttpRequest.js Thanks for any help, John ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Equivalent for XMLHttpRequest.overrideMimeType() in the world of nsIHttpChannel
Perfect! Having seen that, I also found the "contentType" attribute and its description here: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIChannel which allows me to mimic the behaviour. Thanks a lot for the pointer! John ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Cookies are no longer stored by nsIHttpChannel?
Hi,
I have run into something strange. This is how I create network connections in
my (Thunderbird-) AddOn:
let channel = Services.io.newChannelFromURI(
aConnection.uri,
null,
Services.scriptSecurityManager.createCodebasePrincipal(aConnection.uri, {
userContextId }),
null,
Ci.nsILoadInfo.SEC_ALLOW_CROSS_ORIGIN_DATA_IS_NULL,
Ci.nsIContentPolicy.TYPE_OTHER);
let httpchannel = channel.QueryInterface(Components.interfaces.nsIHttpChannel);
httpchannel.loadFlags |= Ci.nsIRequest.LOAD_BYPASS_CACHE;
After updating from ESR60 to ESR68, that connection never uses cookies anymore.
This is a fresh profile, so there are no specific cookie settings being set
(network.cookie.cookieBehavior = 0).
I can see the request from the server to set cookies on each request, but on
the next response, the cookies are not included.
This is used for standard HTTP requests (CardDAV in my case).
Can someone point me to what I am missing?
Thanks,
John
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Cookies are no longer stored by nsIHttpChannel?
It happens also with the SystemPrincipal as well, so independent of the userContextId. I changed to code as follows now and get the same behaviour: let channel = Services.io.newChannelFromURI( uri, null, Services.scriptSecurityManager.getSystemPrincipal(), null, Ci.nsILoadInfo.SEC_ALLOW_CROSS_ORIGIN_DATA_IS_NULL | Ci.nsILoadInfo.SEC_COOKIES_INCLUDE, Ci.nsIContentPolicy.TYPE_OTHER); let httpchannel = channel.QueryInterface(Ci.nsIHttpChannel); httpchannel.loadFlags |= Ci.nsIRequest.LOAD_BYPASS_CACHE; I can see Set-Cookie headers in the responses from the server, but requests send out by my channel do not include any. Hm ... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookies are no longer stored by nsIHttpChannel?
More details: The same code works in TB60 and in the cookie list of the general options I can see all sorts of cookies being stored. In TB68, none of the expected cookies show up in the cookie list. Did something change in that region? What do I need to do to allow a channel / principal to store cookies now? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookies are no longer stored by nsIHttpChannel?
Hi Andrea, I was already going thru that CookieSettings docuemnt, but are you sure that is alreadfy in the ESR68 branch? I tried to access loadInfo.cookieSettings and got back an error. Where can I find you on IRC? Which channel/nick? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cookies are no longer stored by nsIHttpChannel?
Hi Andrea, I can confirm, that network.cookieSettings.unblocked_for_testing is indeed fixing this for me. But since this pref looks like it will not stay long, I would like to fix this with the worker approach. You said you would like to move this discussione to IRC, where can I find you? Thanks for your help! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
