Question about adding a new callback to SimpleURLLoader for handling auth requests

[Deepak Mohan]

Hi all,

In Electron we expose a module that is a wrapper around SimpleURLLoader for making net requests in Nodejs style , pre network service this used to be a wrapper around net::URLRequest and the net::URLRequest::Delegate class provided all the required callbacks for various phases of a request lifecycle.

With network service, the auth handling is delegated to the network service client , in the content layer case this is done by StoragepartitionImpl which checks for a valid webcontents associated with the auth request through the network interceptors (like devtools and service workers) to create the LoginHandlerDelegate and noops in other scenarios.The idea of the above module in electron is to make requests without any associated webcontents.

Ideally this can be solved on our end by creating a custom network service client for the network context used by that module but we allow users to reuse the network context which comes from the storage partitions associated with their app so that other setting like proxy take effect automatically for this module and since there can be only one network client with a context, this path is a no-go for us.

which brings me to the question , would it make sense to add a SetOnAuthRequiredCallback to the SimpleURLLoader class for this use case ?

[John Abd-El-Malek]

On Wed, Nov 6, 2019 at 7:32 PM Deepak Mohan <hop2...@gmail.com> wrote:

Hi all,

In Electron we expose a module that is a wrapper around SimpleURLLoader for making net requests in Nodejs style , pre network service this used to be a wrapper around net::URLRequest and the net::URLRequest::Delegate class provided all the required callbacks for various phases of a request lifecycle.

With network service, the auth handling is delegated to the network service client , in the content layer case this is done by StoragepartitionImpl which checks for a valid webcontents associated with the auth request through the network interceptors (like devtools and service workers) to create the LoginHandlerDelegate and noops in other scenarios.The idea of the above module in electron is to make requests without any associated webcontents.

Ideally this can be solved on our end by creating a custom network service client for the network context used by that module but we allow users to reuse the network context which comes from the storage partitions associated with their app so that other setting like proxy take effect automatically for this module and since there can be only one network client with a context, this path is a no-go for us.

Who's setting the proxy state and other things on the storage partition's network context? If it's electron code, could it also set them on a the custom network context for this use case?

 

which brings me to the question , would it make sense to add a SetOnAuthRequiredCallback to the SimpleURLLoader class for this use case ?

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/5c25670a-2e23-480b-a7a3-198850c20549%40chromium.org.

[Deepak Mohan]

Yup its electron that does the customization with inputs from user. For example a user code can be:

// session is javascript wrapper around content::BrowserContext and its associated NetworkContext
// net is a wrapper around SimpleURLLoader

const {session, net} = require('electron')


const customSession = session.fromPartition('persist:abc') // can also create in memory version if needed
customSession.setProxy('something') // sets the proxy for this custom NetworkContext


const request = net.request({
  url: 'https://example.com',
  session: customSession
})
request.on('response', (res) => {
  // all sorts of magic
})
request.on('login', (authInfo, callback) => {
  // get auth creds
})
request.end()

But at the same time the above session can also be used for webcontents, which will affect the session of a window or webview depending what the webcontents is hosted as. So users ideally had the ability to use one single session for different purpose. But I see the problem with api design here, if we had made sure the net module always used a custom session , we could have setup our own network service client to handle the auth requests directly which would solve the issue. I will look further into this on electron side and see if we need any customization on chromium side.

// new version


const request = net.request({
  url: 'https://example.com'
})
request.session.setProxy('something') // allow customization on session
request.on('response', (res) => {
  // all sorts of magic
})
request.on('login', (authInfo, callback) => {
  // get auth creds
})
request.end()

To unsubscribe from this group and stop receiving emails from it, send an email to embedd...@chromium.org.

[Deepak Mohan]

We are trying an implementation based on `TrustedURLLoaderHeaderClient` which would essentially serve as an alternative for the webContents check https://github.com/electron/electron/pull/21096/files , what are your thoughts about us upstreaming this patch ?

Another idea we would like to try which will lead to a smaller patch is adding a flag to the creation of URLLoader that would essentially bypass the webContents and networks interceptors check on storage_partition_impl.cc. Thoughts on this one ?

- Deepak

[John Abd-El-Malek]

Can you answer the questions I asked earlier? It would be ideal to do this in a way without needing to change Chromium.

--

You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.

To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/8799d567-1376-474b-beea-b4ac43edb2fe%40chromium.org.

[Deepak Mohan]

Sorry if I didn't explain it clearly in https://groups.google.com/a/chromium.org/d/msg/embedder-dev/du2PveLOZXY/S6QkDv4uAAAJ , yes electron can customize any network context. But we want to reuse the network context from the storage partition, as we maintain a 1:1 mapping between BrowserContext -> StoragePartition -> NetworkContext.

Every session in electron has only one BrowserContext associated with it, which adheres to the above mapping. And users can reuse this session for multiple webContents as well as this net module, so not sure how bringing in a new custom network context would solve this use case ?

[John Abd-El-Malek]

On Tue, Nov 12, 2019 at 9:51 PM Deepak Mohan <hop2...@gmail.com> wrote:

Sorry if I didn't explain it clearly in https://groups.google.com/a/chromium.org/d/msg/embedder-dev/du2PveLOZXY/S6QkDv4uAAAJ , yes electron can customize any network context. But we want to reuse the network context from the storage partition, as we maintain a 1:1 mapping between BrowserContext -> StoragePartition -> NetworkContext.

Every session in electron has only one BrowserContext associated with it, which adheres to the above mapping. And users can reuse this session for multiple webContents as well as this net module, so not sure how bringing in a new custom network context would solve this use case ?

I was asking whether you can create a new NetworkContext, but have it use the same settings as the one for web contents. 

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/8871f7de-3e6b-45db-9efa-d2130015af8a%40chromium.org.

[Jeremy Apthorp]

[resending from correct account]

Is it possible to have a separate NetworkContext share the credential cache with another context? We'd like to reuse credentials entered elsewhere in the session if possible.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/CALhVsw10KAEq6AFXEP6wGw6%3D%3DB_46J_1oxnY7xYooV9cox4g7Q%40mail.gmail.com.

[John Abd-El-Malek]

NetworkContexts don't share any state with other instances (by design).

Is sharing credential cache for programmatic fetches useful in practice? e.g. doesn't the behavior depend on whether the user had authenticated to a server before, so the outcome is somewhat random?

[Jeremy Apthorp]

A lot of Electron apps are in essence single-site browsers, so it's quite likely that the user will already have authenticated to the site in question when a programmatic request is made. Additionally, I believe the authentication cache also includes proxy credentials, which would be relevant even if the request was to a different site.