Locked down browser

[brussell90]

Hi, we are needing to essentially lock down the browser to extremely basic functions. The user should not be able to access the system through the browser. This means no save file dialogs, no print screen, etc.

I can disable the print screen through javascript but only for the top level document and any top level iframes. I see there's already a ticket for managing iframes within iframes preventing us from injecting javascript within sub iframes. However, ontop of this I can't seem to disable the save file dialogs.

Does anyone know of anyways to accomplish what I'm looking for within webview2?

[victorthoang]

Hello @brussell90,

Thanks for your inquiry! I've assigned this to a dev that might best answer your question.

[vbryh-msft]

Hi @brussell90 could you please check if suggestions from this thread are useful for your scenario?

[brussell90]

Hi @brussell90 could you please check if suggestions from this thread are useful for your scenario?

Hi @vbryh-msft, thanks for the response.
We've implemented the download blocking and the print blocking as suggested in that thread however, like noted in the thread that doesn't stop CTRL+P printing (but we can stop this with a keyboard hook). With printing, the bigger issue we've ran into though is that we can't control IFrames within IFrames this thread so we can't inject the javascript to block the windows.print feature in those sub IFrames. So we really need a way to block the print functionality altogether.

The biggest issue we have is the file dialogs. While we can disable the downloads, the file dialog menu gives the user access to browse folder and machine information.

[vbryh-msft]

What are the triggers for file dialog menu? You should be able to overwrite context menu - doc is here

[vbryh-msft]

Hi @brussell90, could you please check also this approach if it will work.

[brussell90]

@vbryh-msft I've completely disabled the context menus at this point. Here's a snippet of javascript that would generate a save file dialog.

async function saveFile() {
            const handle = await showSaveFilePicker({
                suggestedName: 'name.txt',
                types: [{
                    description: 'Text file',
                    accept: {
                        'text/plain': ['.txt']
                    },
                }],
            });
}

The "Attach files by dragging & dropping, selecting or pasting them" on the comment box is another example of this. We can override the function like the print dialog for this one example but like with the print, we can't do that for Iframes within Iframes so we are looking more for a method to disable the dialogs altogether.

[brussell90]

Hi @brussell90, could you please check also this approach if it will work.

That actually did work, and opened up an avenue for solving my first problem as well for injecting into Iframes within Iframes.

Here's the solution that works for me.

       public void initCoreHelper()
        {
            var helper = Browser.CoreWebView2.GetDevToolsProtocolHelper();
            helper.Page.EnableAsync();
            helper.Page.SetInterceptFileChooserDialogAsync(true);
            helper.Page.FrameNavigated += Page_FrameNavigated;
        }
        private async void Page_FrameNavigated(object sender, Page.FrameNavigatedEventArgs e)
        {
            Page page = (Page)sender;
            await page.AddScriptToEvaluateOnNewDocumentAsync("window.print = function() {}");
        }

It seems that just adding the intercept file will block file dialogs, I do not have to handle when the dialog is opened.
The FrameNavigated event happens on all frame navigations regardless of how deep they are and allows me to inject javascript on each frame.