Separate cookie storage for Chrome extension

[Luuk]

I am developing an extension to control downloads (like torrents) on a
remote server. The communication with the server is done using ajax
requests. The login session is stored with a cookie. Everything works
fine, but there is one problem: the extension is sharing the login
session with the rest of the browser. This means that a user is
automatically logged in to the web control panel when the extension is
active and when a user switches to a different user account, the
extension uses the different account as well.

Is there a way to seperate the cookie storage from the normal
browsers' cookie storage?

[Mike West]

As you've noted, extensions' requests share the same profile as the
user's normal requests. This, generally, is desirable, as extensions
often make requests on a user's behalf

At the moment, there's no mechanism to create a separate cookie jar
for extensions. You can fake something similar, however, by using the
WebRequest API to strip cookies from outgoing requests, or replace
them with new cookies. One suggestion would be to educate your users
about Chrome's built-in multi-profile support. That seems like a
better long-term solution to the problem you're encountering, as it
would allow users to log in with multiple accounts at the same time.
That's not something that your extension can control on it's own,
however.

Relatedly, I think it might be worthwhile to propose an extension to
the XMLHttpRequest spec that would allow developers to make cookieless
requests.

-Mike

[Mihai Parparita]

On Thu, Mar 1, 2012 at 4:16 AM, Mike West <mk...@chromium.org> wrote:

Relatedly, I think it might be worthwhile to propose an extension to
the XMLHttpRequest spec that would allow developers to make cookieless
requests.

There is the withCredentials attribute, which is meant for cross-origin requests (http://www.w3.org/TR/XMLHttpRequest/#the-withcredentials-attribute). It actually defaults to false, though that doesn't seem to be enforced for extension-initiated cross-origin requests.

On the extension API side, there is also http://crbug.com/48118.

Mihai

[Luuk]

Thank you for your help. I am trying to use the WebRequest API to get
the cookie data in the onHeadersReceived event and store it in
LocalStorage. Storing the data works, but somehow I can't remove the
cookie data from the request to prevent Chrome from saving the actual
cookie. When I add "blocking" to the extraInfoSpec parameter, the
event doesn't fire anymore for XmlHttpRequests made from the
extension.

Here is the code for the event handler:
chrome.webRequest.onHeadersReceived.addListener(
function(details) {
console.log(details.url);
// Save the cookie, remove it from the headers etc..

return { responseHeaders: details.responseHeaders };
},
{ urls: ["<all_urls>"] },
["blocking", "responseHeaders"]
);

I have added the following values to the permissions-field in my
manifest:
"<all_urls>", "http://*/", "https://*/", "webRequest",
"webRequestBlocking"

Do you know what I'm doing wrong? The event fires for all requests,
except the XmlHttpRequests from my extension. Without "blocking" the
event does fire for these requests.

I have the same issue with the onBeforeSendHeaders event (I need to
add the cookie data to the headers in that event).

- Luuk

On 1 mrt, 13:16, Mike West <mk...@chromium.org> wrote:
> As you've noted, extensions' requests share the same profile as the
> user's normal requests. This, generally, is desirable, as extensions
> often make requests on a user's behalf
>
> At the moment, there's no mechanism to create a separate cookie jar
> for extensions. You can fake something similar, however, by using the
> WebRequest API to strip cookies from outgoing requests, or replace
> them with new cookies. One suggestion would be to educate your users
> about Chrome's built-in multi-profile support. That seems like a
> better long-term solution to the problem you're encountering, as it
> would allow users to log in with multiple accounts at the same time.
> That's not something that your extension can control on it's own,
> however.
>
> Relatedly, I think it might be worthwhile to propose an extension to
> the XMLHttpRequest spec that would allow developers to make cookieless
> requests.
>
> -Mike
>

[Dominic Battre]

Hi Luuk,

On Sun, Mar 11, 2012 at 4:25 PM, Luuk <downloa...@me.com> wrote:

Thank you for your help. I am trying to use the WebRequest API to get
the cookie data in the onHeadersReceived event and store it in
LocalStorage. Storing the data works, but somehow I can't remove the
cookie data from the request to prevent Chrome from saving the actual
cookie. When I add "blocking" to the extraInfoSpec parameter, the
event doesn't fire anymore for XmlHttpRequests made from the
extension.

This is a catch-22:

XmlHttpRequests can be synchronous. If we allowed the webRequest API to catch them in a blocking handler, we would have a deadlock. The single tread of the background page is waiting for the synchronous XmlHttpRequest result and cannot process the the webRequest event handler (because the thread is busy waiting).

If you don't make your event handler blocking, you cannot modify the request.

I have started a Changelist that allows differentiating between synchronous XmlHttpRequests and asynchronous XmlHttpRequests. With this, only synchronous XmlHttpRequests from an extension would be hidden from this extension's event listener. Would that help you? If I finish this, it would however take quite some time until it shows up in the stable release.

 

Here is the code for the event handler:
chrome.webRequest.onHeadersReceived.addListener(
       function(details) {
               console.log(details.url);
               // Save the cookie, remove it from the headers etc..

               return { responseHeaders: details.responseHeaders };
       },
       { urls: ["<all_urls>"] },
       ["blocking", "responseHeaders"]
);

I have added the following values to the permissions-field in my
manifest:
"<all_urls>", "http://*/", "https://*/", "webRequest",
"webRequestBlocking"

Do you know what I'm doing wrong? The event fires for all requests,
except the XmlHttpRequests from my extension. Without "blocking" the
event does fire for these requests.

You are doing everything right, it is a limitation of the webRequest API.

 

I have the same issue with the onBeforeSendHeaders event (I need to
add the cookie data to the headers in that event).

- Luuk

Best regards,

Dominic

 

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To post to this group, send email to chromium-...@chromium.org.
To unsubscribe from this group, send email to chromium-extens...@chromium.org.
For more options, visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/?hl=en.