Cooperating on container usage (nsIHttpChannel)
Hi,
I would like to discuss the usage of containers to isolate connection
pools of nsIHttpChannel. After tackling this issue for almost 1 year, I
was finally able to get it working today and have it implemented in
TbSync. As no one from the Thunderbird community was able to help me
with it, I thought it would be interesting for others as well.
Furthermore, I would like to prevent conflicts between different authors
by using the same containers and would like to define/discuss some
common method to pick container ids.
Without containers, connections are only separated by hosts+realm, which
means it is not possible to create two or more independent connections
to the same server but with different user names, because
nsIHttpChannel::asyncOpen() will use the same username for all
connections to that host and all connections share the same cookie store.
This is one of the reasons, why Lightning is not able to subscribe to
two different calendars of different users (without read permission to
the other users resources) on the same host. Philipp has some mitigation
in place using a multirealm hack, but I think that does not work with
digest auth and I remember him saying, he wants to get rid of that
option. Containers will fix that for good.
Containers
I have some example code in the original bug report:
https://bugzilla.mozilla.org/show_bug.cgi?id=1494955#c17
The important change is to not use the systemPrincipal, but create a new
one and attach an originAttribute (OA):
|Services.scriptSecurityManager.createCodebasePrincipal(aUri, {
userContextId })|
The key must be called userContextId and it must be an integer. All
connections with the same OA share the same connection pool, segregated
by host+real again.
To fix the issue outlined above, it is obvious that one needs a stable
mapping "username -> userContextId", like a hash function.
- Do we need to care, that other consumers/authors/AddOns use the same
id by accident? I think we should propose a common method so that we get
common connection pools per username. - Do we want to reserve some ids for some private connection pools?
MailExtension API
I learned a few days ago, that nsIHttpChannel is currently not
accessible from MailExtension. I worked a lot with XHR and fetch() and
none of them will provide all the features I need for TbSync. Both lack
container support (afaik). So I think we will need to come up with a
wrapper API for nsIHttpChannel and that API should allow to specify a
username per connection and take care of the connection pools and the
container id.
Lightning
@Philipp: Ping me if you have some spare time, I would love to help you
impl. containers in lightning and discuss with you, how this can be
achieved.
Thanks for your time (I hope it was not wasted)
John
On 13-03-2019 21:17, John Bieling wrote:
I learned a few days ago, that nsIHttpChannel is currently not
accessible from MailExtension. I worked a lot with XHR and fetch() and
none of them will provide all the features I need for TbSync. Both
lack container support (afaik). So I think we will need to come up
with a wrapper API for nsIHttpChannel and that API should allow to
specify a username per connection and take care of the connection
pools and the container id.
Another possibility would be to work on getting that situation sorted
out for fetch(). It looks to me potentially passing fetch.init a
credentials a PasswordCredential would be the future way. (Likely bug
1156047).
-Magnus
Are we (C-C) able to contribute to fetch API? From what I remember, they
(M-C) only accept things that are part of the fetch spec (and they don't
even do that, I have a bug open for months which is not fixed, which
makes fetch unusable at the moment - bug 1491010).
Furthermore it is more than just the wrong username/password, containers
also fix the cookie problem! Without containers there is also just one
cookie store per host, which makes it again impossible to connect with
two different users to the same host, if that host is using session cookies.
But I agree, getting access to containers (setting the originAttribute)
via fetch would be nice, shall I open a bug?
Regarding the common method to get the container id for Thunderbird usage:
- is there a network related JS module part of C-C?
- since all caches get cleared on app restart, we could just provide a
function "getContainerIdForUser(username)" and that is checking an
internal array for that username and returns its index (plus some offset
if we want to reserve the lowest ids for something else) and if the
username is not yet part of that array, add it and then return its index.
Plausible? I would like to see that in C-C and not in M-C, because the
use cases are different.
John
On 14.03.2019 11:32, Magnus Melin wrote:
On 13-03-2019 21:17, John Bieling wrote:
I learned a few days ago, that nsIHttpChannel is currently not
accessible from MailExtension. I worked a lot with XHR and fetch()
and none of them will provide all the features I need for TbSync.
Both lack container support (afaik). So I think we will need to come
up with a wrapper API for nsIHttpChannel and that API should allow to
specify a username per connection and take care of the connection
pools and the container id.
Another possibility would be to work on getting that situation sorted
out for fetch(). It looks to me potentially passing fetch.init a
credentials a PasswordCredential would be the future way. (Likely bug
1156047).
-Magnus
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
That depends on what you mean by contribute. Contributing can just as
well mean arguing a use case and push for whatever steps are needed to
get that feature supported (or bug fixed). I think this is the main way
to contribute to a limitation of fetch. I'm not saying that is
necessarily easy, just that it's preferable in the wider sense. If
you're proposing changes to a web standard feature it's of course
essential that the feature is something wanted outside of extension usage.
Re filing a bug for fetch() and containers, sure. It needs to be framed
correctly to get through though. See my earlier earlier mail though.
Perhaps that could be the way to eventually have it implemented.
I don't think comm-central has a network module.
-Magnus
On 14-03-2019 13:12, John Bieling wrote:
Are we (C-C) able to contribute to fetch API? From what I remember,
they (M-C) only accept things that are part of the fetch spec (and
they don't even do that, I have a bug open for months which is not
fixed, which makes fetch unusable at the moment - bug 1491010).
Furthermore it is more than just the wrong username/password,
containers also fix the cookie problem! Without containers there is
also just one cookie store per host, which makes it again impossible
to connect with two different users to the same host, if that host is
using session cookies.
But I agree, getting access to containers (setting the
originAttribute) via fetch would be nice, shall I open a bug?
Regarding the common method to get the container id for Thunderbird
usage:
- is there a network related JS module part of C-C?
- since all caches get cleared on app restart, we could just provide
a function "getContainerIdForUser(username)" and that is checking an
internal array for that username and returns its index (plus some
offset if we want to reserve the lowest ids for something else) and if
the username is not yet part of that array, add it and then return its
index.
Plausible? I would like to see that in C-C and not in M-C, because the
use cases are different.
John
On 14.03.2019 11:32, Magnus Melin wrote:
On 13-03-2019 21:17, John Bieling wrote:
I learned a few days ago, that nsIHttpChannel is currently not
accessible from MailExtension. I worked a lot with XHR and fetch()
and none of them will provide all the features I need for TbSync.
Both lack container support (afaik). So I think we will need to come
up with a wrapper API for nsIHttpChannel and that API should allow
to specify a username per connection and take care of the connection
pools and the container id.
Another possibility would be to work on getting that situation sorted
out for fetch(). It looks to me potentially passing fetch.init a
credentials a PasswordCredential would be the future way. (Likely bug
1156047).
-Magnus
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
On 14.03.2019 12:55, Magnus Melin wrote:
That depends on what you mean by contribute. Contributing can just as
well mean arguing a use case and push for whatever steps are needed to
get that feature supported (or bug fixed). I think this is the main
way to contribute to a limitation of fetch. I'm not saying that is
necessarily easy, just that it's preferable in the wider sense. If
you're proposing changes to a web standard feature it's of course
essential that the feature is something wanted outside of extension
usage.
Re filing a bug for fetch() and containers, sure. It needs to be
framed correctly to get through though. See my earlier earlier mail
though. Perhaps that could be the way to eventually have it implemented.
Ok, I will try. First via google group to get a feeling for the resonance.
I don't think comm-central has a network module.
Do you have any other idea, where such a method could be added to in
C-C? Are you actually in favor of such a common method?
John
On 14-03-2019 14:01, John Bieling wrote:
On 14.03.2019 12:55, Magnus Melin wrote:
That depends on what you mean by contribute. Contributing can just as
well mean arguing a use case and push for whatever steps are needed
to get that feature supported (or bug fixed). I think this is the
main way to contribute to a limitation of fetch. I'm not saying that
is necessarily easy, just that it's preferable in the wider sense. If
you're proposing changes to a web standard feature it's of course
essential that the feature is something wanted outside of extension
usage.
Re filing a bug for fetch() and containers, sure. It needs to be
framed correctly to get through though. See my earlier earlier mail
though. Perhaps that could be the way to eventually have it implemented.
Ok, I will try. First via google group to get a feeling for the
resonance.
I don't think comm-central has a network module.
Do you have any other idea, where such a method could be added to in
C-C? Are you actually in favor of such a common method?
Maybe in a module under mailnews/base/util/, or possibly under common/
If the functionality is of general interest, I'm open to including it.
-Magnus
On 3/14/19 1:37 PM, Magnus Melin wrote:
Do you have any other idea, where such a method could be added to in
C-C? Are you actually in favor of such a common method?
Maybe in a module under mailnews/base/util/, or possibly under common/
If the functionality is of general interest, I'm open to including it.
I'm concerned this is another wrapper for functionality we'd need to
maintain. This doesn't exactly help us be independent from XPCOM.
Generally, fetch() is implemented in m-c, and we can't just arbitrarily
extend it in c-c aside from providing a js-wrapper that behaves the same
way.
Philipp
On 14.03.2019 13:56, Philipp Kewisch wrote:
On 3/14/19 1:37 PM, Magnus Melin wrote:
Do you have any other idea, where such a method could be added to in
C-C? Are you actually in favor of such a common method?
Maybe in a module under mailnews/base/util/, or possibly under common/
If the functionality is of general interest, I'm open to including it.
I'm concerned this is another wrapper for functionality we'd need to
maintain. This doesn't exactly help us be independent from XPCOM.
Generally, fetch() is implemented in m-c, and we can't just arbitrarily
extend it in c-c aside from providing a js-wrapper that behaves the same
way.
Philipp
Hi Philip,
I will try to propose to m-c, that fetch() becomes auto-contained by
username.
This is not a violation of the spec and does not req to change the
fetch() interface.
The important question is, is there a use case where you DO want to
share the
caches (cookie and what not) for connections of different users to the
same host.
I personally cannot think of any. I think that is the only entry point
without having
to go the long way and actually get containers into the fetch() spec.
But I really prefer
the auto-containment, as m-c is in full control of the containers and
does not expose
that to user land.
Regarding my getContainerIdFromUser() proposal for c-c, that is
completely independent
of fetch() or any other m-c implementation. It is a simple array of
usernames which gets
reset on app start (as it is in memory only) and fills itself by being
requested.
It basically maps usernames to unique (but not persistent) ids.
Nevertheless, if the proposal for auto-contained fetch() will be
rejected, I would like
to propose a MailExtensions wrapper for nsIHttpChannel, which does that.
John