info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Creating Sandboxed HTTP connections with specific session information.
39 views
Skip to first unread message
passfree
Jun 11, 2012, 9:53:34 AM6/11/12
to
The page https://developer.mozilla.org/en/Creating_Sandboxed_HTTP_Connections
is quite good for explaining how to create sandboxed HTTP connections
but in my humble opinion it does a poor job at explaining how to
really sandbox the request so that it doesn't use already stored
session information.
The only explanation is to use an observer which removes the cookies
when they are received but then I find this as not a very complete
solution because it will potentially break other extensions. For
example, if a user is using LiveHttpHeaders or Firebug, or any other
request debugging functionality he/she will see responses which has
been tampered with which in turn will make debugging very difficult.
What I am trying to figure out is how to make a request without
supplying cookie information and without affecting the session storage
of the browser ... but also without affecting perfectly working
extensions which may depend on having the un-tampered requests/
responses.
is quite good for explaining how to create sandboxed HTTP connections
but in my humble opinion it does a poor job at explaining how to
really sandbox the request so that it doesn't use already stored
session information.
The only explanation is to use an observer which removes the cookies
when they are received but then I find this as not a very complete
solution because it will potentially break other extensions. For
example, if a user is using LiveHttpHeaders or Firebug, or any other
request debugging functionality he/she will see responses which has
been tampered with which in turn will make debugging very difficult.
What I am trying to figure out is how to make a request without
supplying cookie information and without affecting the session storage
of the browser ... but also without affecting perfectly working
extensions which may depend on having the un-tampered requests/
responses.
Marcio Galli
Jun 11, 2012, 12:50:01 PM6/11/12
to passfree, dev-pl...@lists.mozilla.org
It looks like this is a case that adds a bit to what I call "Gecko in
managed mode" so far, for lack of better term. What I mean is that I feel
there is a number of feature areas that Gecko could deliver based in new
use case scenarios ( or old ones repurposed to nowadays growing needs )
that I think we need to start documenting.
Documentation on cookies/network on how Gecko apps uses them, is key; and
maybe we need to do a check against how B2G apps are to use network and/or
if these isolation needs are there too.
M
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
--
www.telasocial.com
managed mode" so far, for lack of better term. What I mean is that I feel
there is a number of feature areas that Gecko could deliver based in new
use case scenarios ( or old ones repurposed to nowadays growing needs )
that I think we need to start documenting.
Documentation on cookies/network on how Gecko apps uses them, is key; and
maybe we need to do a check against how B2G apps are to use network and/or
if these isolation needs are there too.
M
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
--
www.telasocial.com
Andrew Sutherland
Jun 11, 2012, 1:18:54 PM6/11/12
to dev-pl...@lists.mozilla.org
https://bugzilla.mozilla.org/show_bug.cgi?id=692677 recently introduced
an "anon" flag to the XHR constructor which should not send any cookies
(chrome privileges or presence in white-list required). Check the bug
for more info, especially to make sure it actually does what you want.
(Due to its recency, it is still dev-doc-needed)
Andrew
an "anon" flag to the XHR constructor which should not send any cookies
(chrome privileges or presence in white-list required). Check the bug
for more info, especially to make sure it actually does what you want.
(Due to its recency, it is still dev-doc-needed)
Andrew
passfree
Jun 11, 2012, 5:10:24 PM6/11/12
to dev-pl...@lists.mozilla.org
What we really need is a flag on nsIHttpChannel called .background or .sandboxed which when set should instruct any of the underlaying observers, event sinks, load groups etc not to send or store cookies by the request. I think this should be relatively straightforward given that nsIHttpChannel is propagated down.
Neil
Jun 12, 2012, 4:29:44 AM6/12/12
to
passfree wrote:
>Andrew Sutherland wrote:
>
>
>>https://bugzilla.mozilla.org/show_bug.cgi?id=692677 recently introduced an "anon" flag to the XHR constructor which should not send any cookies (chrome privileges or presence in white-list required).
>>
>Ok, this is great but first of all it wont work for nsIChannels
>
The "anon" flag works by setting the REQUEST_ANONYMOUS flag on the
nsIChannel...
--
Warning: May contain traces of nuts.
>Andrew Sutherland wrote:
>
>
>>https://bugzilla.mozilla.org/show_bug.cgi?id=692677 recently introduced an "anon" flag to the XHR constructor which should not send any cookies (chrome privileges or presence in white-list required).
>>
>
The "anon" flag works by setting the REQUEST_ANONYMOUS flag on the
nsIChannel...
--
Warning: May contain traces of nuts.
passfree
Jun 11, 2012, 5:10:24 PM6/11/12
to mozilla.de...@googlegroups.com, dev-pl...@lists.mozilla.org
0 new messages