[Feature] allow client certificate selection and settings from Javascript

[frzme]

Similarly to puppeteer/puppeteer#540

Currently when navigating to a page that requires client certificates and client certificates are available a popup is shown in Firefox and Chrome which asks to select which certificate to use. It would be beneficial to provide an API to select the correct certificate to use (or use none).

[yyvess]

You can apply same workaround as for puppeteer.
First client certificate popup should only open if you have more than one client certificate installed.
You can remove client certificate to avoid the popup be open.

Secondly you can inject dynamically an certificate as is =>

const fs = require('fs');
const request = require('request');
const browser = await chromium.launch();
const ctx = await browser.newContext();
await ctx.route('**/*', (route, req) => {
    const options = {
      uri: req.url(),
      method: req.method(),
      headers: req.headers(),
      body: req.postDataBuffer(),
      timeout: 10000,
      followRedirect: false,
      agentOptions: {
        ca: fs.readFileSync('./certs/ca.pem'),
        pfx: fs.readFileSync('./certs/user_cert.p12'),
        passphrase: fs.readFileSync('./certs/user_cert.p12.pwd'),
      },
    };
    let firstTry = true;
    const handler = function handler(err, resp, data) {
      if (err) {
        /* Strange random connection error on first request, do one re-try */
        if (firstTry) {
          firstTry = false;
          return request(options, handler);
        }
        console.error(`Unable to call ${options.uri}`, err.code, err);
        return route.abort();
      } else {
        return route.fulfill({
          status: resp.statusCode,
          headers: resp.headers,
          body: data,
        });
      }
    };
    return request(options, handler);
  });

[gepd]

You can apply same workaround as for puppeteer.
First client certificate popup should only open if you have more than one client certificate installed.
You can remove client certificate to avoid the popup be open.

Hey @yyvess do you have an example of how remove client certificate programmatically?

[yyvess]

Hi @gepd, as I know you cannot remove it programmatically. But if you have only one certificate installed, the browser should not ask you to select one. Note that the popup is not present when you run your test in background.

[mxschmitt]

Hey folks!

We are currently evaluating and digging into this feature and have a few questions so it will fit your needs:

• Is selecting a certificate out of the given ones from the operating system programatically enough? (like e.g. a clientCertificate event where you can select out of the loaded ones or a mapping from hosts to client certificates)
• Do you want to load a custom certificate manually or is it already in your operating system certificate storage?
• If you add them manually, are you using PEM or PFX certificate file format?
• Is it enough if its on browser.launch level? (context level with multiple certificates on each context would be the alternative)
• Do you want to validate against a CA?
• (your use-case would also help a lot)

Thank you! ❤️ And sorry for the ping.

cc @osmenia, @SMN947, @delsoft, @dcr007, @inikulin, @BredSt, @matthias-ccri, @nlack, @sdeprez, @bramvanhoutte, @yyvess, @gepd

[sdeprez]

👋   great news!
So to talk about our own usecase:

• programmatical selection is enough yes
• on the fly loading would be very nice, because for us the certificate is ultimately provided by our customers and as such is dynamic, so we would like to avoid tooling to constantly add and remove certificates from the OS storage
• only PEM
• browser.launch is enough, we have one browser per session (and only one certificate per session)
• no need to validate, probably some certificates will be self-signed I can imagine

[yyvess]

Hi,

Thanks for your interest on this features !

On my case applications use client certificate to do the authentication of users.

Today as work around we inject certificate as I described before on this thread.
Only small issue that still is that when we run test in no headless, the browser requests a certificate selection on a popup.
We can select manually any certificate proposed by the browser as after an other is inject by the proxy .
But it's force to add a wait to gave time to select manually one other tests faild.

• Is selecting a certificate out of the given ones from the operating system programatically enough?

Will more easy to pass a list (or map<key,file>) of certificate files to Playwright during the initialization.
On CI our test are executed on a dedicated docker image.
But when a developer run test manually, it's run directly on his Os.

• If you add them manually, are you using PEM or PFX certificate file format?

Converting certificate is not an issue.

• Is it enough if its on browser.launch level?

We have some test that require different users with different privilege.
Then we should be able to select or switch certificate between two different tests.

• Do you want to validate against a CA?

Not really needed

[gepd]

Hey!

Thanks for considerate this!

in my use case:

• programmatical selection is enough
• like @yyvess on the fly loading would be very nice
• We use PFX
• we have one browser and certificate per session
• If we can validate would be cool, but not mandatory

Our use case; we need to download a file from a gov website, this website only works creating a session with a PFX certificate. Each user doesn't need to download that file very often, but we have many users, that is why on the fly loading is good for our use case

Thanks again!

[callmemagnus]

The solution @yyvess proposed works for most use cases.

I have an issue with multipart POST request, like file uploads.
The new request does not contain the multipart file content.
We need the formData content available, if we would like this solution to be sustainable.

[arekzelechowski]

I'd like to add my thoughts to this discussion:

Is selecting a certificate out of the given ones from the operating system programatically enough? (like e.g. a clientCertificate event where you can select out of the loaded ones or a mapping from hosts to client certificates)
For our use case OS certs are not enough. The event idea seems awesome.

Do you want to load a custom certificate manually or is it already in your operating system certificate storage?
We'd like to do that manually.

If you add them manually, are you using PEM or PFX certificate file format?
Actually it does not matter. Converting between PEMs and PFX/P12 is quite easy. However, take a look at https.Agent and tls.connect() implementations. Using the same interface could be beneficial - ca, cert and key fields in PEM format

Is it enough if its on browser.launch level? (context level with multiple certificates on each context would be the alternative)
For our use case it is enough

Do you want to validate against a CA?
Yes, we do. We have our own CA that issues both client and server certificates.

(your use-case would also help a lot)

We use Playwright in two ways: E2E tests and automated scripts. Current solution for E2E is ok, but automated scripts runtime is somewhat problematic. Our intention is to write scripts with APIs as much as possible, however, some of our legacy apps do not have these. In that case, we use playwright as an workaround. All of these legacy apps are behind HTTPS (sometimes with certs issued by local CA) and client certs auth.

One more important factor is Docker. We run E2E tests with Gitlab CI runner that uses docker containers. We would also like to run these scripts in docker containers as you do not need to install node, playwright, no updates required. This is why asking OS for cert is not sufficient.

PS. Using custom TLS certs for APIs is not a problem at all.

[Xen0byte]

Hi @mxschmitt, I've raised on the dotnet repo the issue of not being able to import certificates or to use already-existing certificates in headless mode (microsoft/playwright-dotnet#1601). That issue got merged into this one, which is when I started having some concerns that this somewhat unrelated issue would be bundled with the actual problem that I've raised on the dotnet repo. For my organisation, certificate selection is a nice-to-have, and this can be easily worked around via the registry in Windows and via config on UNIX-based systems, in lieu of programmatic means, however not being able to import certificates in dotnet or to use already-existing certificates in headless mode is currently a blocker on one of our products. Hope this information helps towards development on this; for me and my organisation, this would be the most important feature since the first release on the stable channel. Cheers.

[fargraph]

This is also our use case, including docker:

Is selecting a certificate out of the given ones from the operating system programatically enough? (like e.g. a clientCertificate event where you can select out of the loaded ones or a mapping from hosts to client certificates) For our use case OS certs are not enough. The event idea seems awesome.

Do you want to load a custom certificate manually or is it already in your operating system certificate storage? We'd like to do that manually.

If you add them manually, are you using PEM or PFX certificate file format? Actually it does not matter. Converting between PEMs and PFX/P12 is quite easy. However, take a look at https.Agent and tls.connect() implementations. Using the same interface could be beneficial - ca, cert and key fields in PEM format

Is it enough if its on browser.launch level? (context level with multiple certificates on each context would be the alternative) For our use case it is enough

Do you want to validate against a CA? Yes, we do. We have our own CA that issues both client and server certificates.

(your use-case would also help a lot)

We use Playwright in two ways: E2E tests and automated scripts. Current solution for E2E is ok, but automated scripts runtime is somewhat problematic. Our intention is to write scripts with APIs as much as possible, however, some of our legacy apps do not have these. In that case, we use playwright as an workaround. All of these legacy apps are behind HTTPS (sometimes with certs issued by local CA) and client certs auth.

One more important factor is Docker. We run E2E tests with Gitlab CI runner that uses docker containers. We would also like to run these scripts in docker containers as you do not need to install node, playwright, no updates required. This is why asking OS for cert is not sufficient.

PS. Using custom TLS certs for APIs is not a problem at all.

[fargraph]

If you came here looking for a solution and you saw the solution from @yyvess, you may also be looking for where to implement that solution. It took me a while trying to integrate it in the global config, or even a setup/teardown file, but I just couldn't find the correct apis that would let me do that. So I finally landed on creating a custom fixture that provides a context and then also re-exports all of @playwright/test. The pattern is similar to testing-library in which they recommend creating fixtures as needed to reduce code.

I have a global config that I'll include for completeness, but it really doesn't do anything special. The real magic is in the fixture which is used by the test for all of the Playwright imports.

Note, if you need to do MFA Authentication and want to use the documented persistent context, but can't figure out how to tell playwright to launch a persistent context, you can use this same solution, instead of using the provided context in the fixture, you would just create one in the fixture and it will be provided to any tests that use the fixture.

// playwright.config.ts

import { PlaywrightTestConfig } from '@playwright/test'

const config: PlaywrightTestConfig = {
    testDir: 'tests',
    use: {
        channel: 'chrome',
        ignoreHTTPSErrors: true,
    },
}
export default config

// caAuthenticationFixture.ts

import { test as base, chromium, BrowserContext } from '@playwright/test'
import fs from 'fs'
import request, { CoreOptions } from 'request'

export const test = base.extend({
    context: async ({ context }, use) => {

       // I use the context that is created using my base config here, just adding the route, but you could also create
       // a context first if you needed even more customizability.

        await context.route('**/*', (route, req) => {
            const options = {
                uri: req.url(),
                method: req.method(),
                headers: req.headers(),
                body: req.postDataBuffer(),
                timeout: 10000,
                followRedirect: false,
                agentOptions: {
                    ca: fs.readFileSync('./certs/ca.pem'),
                    pfx: fs.readFileSync('./certs/user.p12'),
                    passphrase: fs.readFileSync('./certs/user.p12.passwd', 'utf8'),
                },
            }
            let firstTry = true
            const handler = function handler(err: any, resp: any, data: any) {
                if (err) {
                    /* Strange random connection error on first request, do one re-try */
                    if (firstTry) {
                        firstTry = false
                        return request(options, handler)
                    }
                    console.error(`Unable to call ${options.uri}`, err.code, err)
                    return route.abort()
                } else {
                    return route.fulfill({
                        status: resp.statusCode,
                        headers: resp.headers,
                        body: data,
                    })
                }
            }
            return request(options, handler)
        })
        use(context)
    },
})

export * from '@playwright/test'

// login.spec.ts

import { test, expect } from './certAuthenticationFixture'  // <-- note the import of everything from our fixture.

test('login test', async ({ page, context }) => {
  
    await page.goto('https://my.page.net')

    const title = page.locator('title')

    await expect(title).toHaveText('My Title')
})

[philga7]

Hi, @fargraph:

In using Node v14.18.0, were you (or anyone else) able to get beyond the Node-level (but not Node error) message SELF_SIGNED_CERT_IN_CHAIN Error: self signed certificate in certificate chain?

In other automation frameworks that I've used, they typically had cert auth baked in, so having to rely upon Node wasn't necessarily an issue.

Thanks!

[fargraph]

I believe that error is bypassed by this line in the playwright config:

// playwright.config.ts

import { PlaywrightTestConfig } from '@playwright/test'

const config: PlaywrightTestConfig = {
    testDir: 'tests',
    use: {
        channel: 'chrome',
        ignoreHTTPSErrors: true, // <-- bypass the SELF_SIGNED_CERT_IN_CHAIN Error
    },
}
export default config

See this issue for reference: #2814

[philga7]

@fargraph: Unfortunately, no, ignoreHTTPSErrors: true does not deal with the SELF_SIGNED_CERT_IN_CHAIN error.

This is something likely very simple that I'm simply overlooking.

Appreciate the help.

[randomactions]

While the request is being implemented, is there a way to simply click "Cancel" in the "Select a certificate" dialog?

[radu-nicoara-bayer]

We would also need just a way to cancel the popup. I am currently implementing a login tests, and it always gets stuck when the browser is asking for a certificate, that we are trying to cancel ether way. Just that playwright does not offer the possibility when using page.on('dialog', dialog => dialog.dismiss());. Nothing happens.

[enrialonso]

Hi guys, few days ago I involved on the same problem and want to share here my workaround for this.

Important, this workaround is really weak and need improve to attach the real goal: select the certificate programmatically

• Only work on headless=false
• Only tested on chromium browser

In this repository explain better the workaround >> playwright-auto-select-certificates-for-url

Basically manage the policies of the chromium browser in the path /etc/chromium/policies/managed and filter the certificated used for a URL inside of the json policy.

{
  "AutoSelectCertificateForUrls": ["{\"pattern\":\"*\",\"filter\":{}}"]
}

The browser launch read this policy and automatic select the cert for the url.

Any mistake pls sorry and sorry for my english.

[Az8th]

I got some news from @mxschmitt during today's Playwright Happy Hour : There is no update about the feature being added, but it is still on the scope !
Thanks for not letting us apart, and if we can help you in any way to get this feature, please tell ;)

The community is eagerly waiting for this feature. It would really be nice to see this feature. I have discussed this blocker with @mxschmitt when I was working on an internal MSFT project. As you may be aware a lot of teams at even at Microsoft are moving to playwright, this will be a blocker for many teams. This feature should be considered a priority. I understand this is a niche feature and probaby unique to playwright. I can't remember any tool having this feature. I have always seen ugly workarounds for this. And I am sure others will agree...

Ugly may be too harsh, but they are definitely not usable in CI, as they only concern headed mode, and not every browser.

Plus it would permit easier multiple authentication.
Storage states are great, but setup multiple accounts for each worker is not very flexible when you have the need to reuse the same tests with different accounts types/permissions, while just swapping certs could be done on the fly and even remove the need for setup steps.

[Fazali-Illahi]

@Az8th. I agree it's straight forward to make this for a single browser in headed mode, it becomes tedious in cross browser tests on CI. And someone also mentioned this feature is already in cypress. I will definitely give that a try.

[ilorwork]

I'm really sorry to inform you that after a whole month of searching for a workaround, I'm moving to Cypress...
We have about 15 Automation projects that I wanted to migrate from Selenium/Cypress to Playwright.
My own project which is the one that should lead the whole migration failed to workaround this auth-related obstacle.
I'm very disappointed because I really wanted to lead this thing, and this is a rare opportunity in such a big company, not to mention that the whole company stack is based on Microsoft.

[h3tz]

Cypress is not the better option. Please have a look into nightwatch much more software developer like. Ilor ***@***.***> schrieb am So., 19. Nov. 2023, 15:31:

…

I'm really sorry to inform you that after a whole month of searching for a workaround, I'm moving to Cypress... We have about 15 Automation projects that I wanted to migrate from Selenium/Cypress to Playwright. My own project which is the one that should lead the whole migration failed to workaround this auth-related obstacle. I'm very disappointed because I really wanted to lead this thing, and this is a rare opportunity in such a big company, not to mention that the whole company stack is based on Microsoft. — Reply to this email directly, view it on GitHub <#1799 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQ7XGS233K4JRWSMR6FRX3YFIJ3BAVCNFSM4MIV2WZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBRG44DOMRTGEYQ> . You are receiving this because you commented.Message ID: ***@***.***>

[janostgren]

I have done a workaround based on the Node https agent and Axios. sön 19 nov. 2023 kl. 15:44 skrev Andreas Hetz ***@***.***>:

…

Cypress is not the better option. Please have a look into nightwatch much more software developer like. Ilor ***@***.***> schrieb am So., 19. Nov. 2023, 15:31: > I'm really sorry to inform you that after a whole month of searching for a > workaround, I'm moving to Cypress... > We have about 15 Automation projects that I wanted to migrate from > Selenium/Cypress to Playwright. > My own project which is the one that should lead the whole migration > failed to workaround this auth-related obstacle. > I'm very disappointed because I really wanted to lead this thing, and this > is a rare opportunity in such a big company, not to mention that the whole > company stack is based on Microsoft. > > — > Reply to this email directly, view it on GitHub > < #1799 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/ABQ7XGS233K4JRWSMR6FRX3YFIJ3BAVCNFSM4MIV2WZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBRG44DOMRTGEYQ> > . > You are receiving this because you commented.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#1799 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG7INMCAVYSYUD6R24I3DQTYFILLJAVCNFSM4MIV2WZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBRG44DONJUGM4Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Xen0byte]

I have done a workaround based on the Node https agent and Axios.

Yeah, great, except that all the language-specific issues have been aggregated into this issue, so this workaround may only be valid for TypeScript users but not for anyone else. For instance, I raised this problem for C# and it's been closed and merged into this issue, and none of these workarounds apply to me, and on top of that all the workarounds here seem to be for TypeScript because the issue title has not been updated to reflect the aggregation.

[janostgren]

Ok mån 20 nov. 2023 kl. 08:06 skrev Vlad Tănăsescu ***@***.***>:

…

I have done a workaround based on the Node https agent and Axios. Yeah, great, except that all the language-specific issues have been aggregated into this issue, so this workaround may only be valid for TypeScript users but not for anyone else. For instance, I raised this problem for C# and it's been closed and merged into this issue, and none of these workarounds apply to me, and on top of that all the workarounds here seem to be for TypeScript because the issue title has not been updated to reflect the aggregation. — Reply to this email directly, view it on GitHub <#1799 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG7INMCMT5TMIZKLGJPHAWDYFL6Q5AVCNFSM4MIV2WZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBRHAZTIOJUG4ZQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ilorwork]

@janostgren
Plz, can you share it with me?
I'm using TS too, and if I'll find a full solution that would be great!
Share it here or anywhere you want, thanks for the help

[kelvinsleonardo]

The same happens to me; I have some automations using Java, but I don't have a solution for Playwright with certificate selection. Is there any workaround?

[pschroeder89]

My workaround for Chrome / FF above is at the OS level. That same method can be used on Windows via registry changes.

…

Sent from my iPhone

On Mon, Nov 20, 2023 at 12:06 AM Vlad Tănăsescu ***@***.***> wrote: I have done a workaround based on the Node https agent and Axios. Yeah, great, except that all the language-specific issues have been aggregated into this issue, so this workaround may only be valid for TypeScript users but not for anyone else. For instance, I raised this problem for C# and it's been closed and merged into this issue, and none of these workarounds apply to me, and on top of that all the workarounds here seem to be for TypeScript because the issue title has not been updated to reflect the aggregation. — Reply to this email directly, view it on GitHub <#1799 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACSDKRB3XPSXQ2NWY37MFHLYFL6QXAVCNFSM4MIV2WZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBRHAZTIOJUG4ZQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[janostgren]

It is for a customer but we can have chat and discuss the topic. mån 20 nov. 2023 kl. 14:36 skrev Ilor ***@***.***>:

…

@janostgren <https://github.com/janostgren> Plz, can you share it with me? I'm using TS too, and if I'll find a full solution that would be great! Share it here or anywhere you want, thanks for the help — Reply to this email directly, view it on GitHub <#1799 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG7INMGVEM65P4MZCQJIGV3YFNMEJAVCNFSM4MIV2WZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBRHEYDONZTGU4Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ilorwork]

@janostgren
Ok, lets chat.
What is your preferred chatting platform?
I'm available on telegram username: @letsolve_it

[alexyablonskyi]

Hey community. Any news regarding this feature? It is really block me to use Playwright

[ilorwork]

Workaround (UI)

Hey guys, I've posted a question about this issue on StackOverFlow,
and added a few workarounds I found:

1. For Windows & Chromium users that uses the AutoSelectCertificateForUrls Registry Chromium policy - link
2. Using keyboard key pressing via node-key-sender library (Java runtime required) - link

Quick note - I'm using TypeScript, but I'm sure there are similar ways/libraries for other languages

[ilorwork]

@alexyablonskyi Check my previous commend, hope you'll find something useful

[IgorZn]

I've had similar issue and as a workaround using axios and fixture of playwright

httpClient.js

import https from 'node:https';
import * as fs from 'node:fs';
import axios from 'axios;

export const httpInstance = axios.create({
        baseURL: "<some baseURL>",
        httpsAgent : new https.Agent({
                cert: fs.readFileSync('<your>.pem'),
                key: fs.readFileSync('<your>.key'),
                rejectUnauthorized: false
            })
})

subscription.js

expost class Subscription {
        constructor(httpClient) {
                this.req = httpClient
        }

        async createSubscription(){
                return this.req.post('/api/v4/<somthing>', <body>)
        }

test-extend.js

import { test as customTest } from "@playwright/test"
import { Subscription } from "./POM/subscription";
import { httpInstance} from "./POM/httpClient";

export const test = customTest.extend({
    subscriptionHelper: async ({ request }, use) => {
        const subscription = new Subscription(httpInstance)
        await use(subscription)
    },
})

api-test.spec.js

import { expect } from "@playwright/test";
import { test } from "../fixtures/test-extend"

test('My Test', async ({ subscriptionHelper}) => {
    await subscriptionHelper.createSubscription()
        .catch(e => console.log(e.response.data))
})

Done

[Az8th]

Thanks for this workaround @IgorZn
Does it works for all browsers, including headless mode ?

[IgorZn]

Thanks for this workaround @IgorZn Does it works for all browsers, including headless mode ?

No, it doesn't work for UI

[standbyoneself]

I also need this feature. I don't want it in the cypress way, I wanna select certificate programmatically e.g. by name in each test 😤.

[h3tz]

since nothing happened. We proceed with Robotframework.

[callmekohei]

Hello(｡･ω･｡)ﾉ

I've managed to implement and find a solution using F# (.NET) instead of JavaScript.
It works properly.
For your reference:

  let private httpRequestAsync (clientCert: X509Certificate2) (request: IRequest) =
    Http.AsyncRequest(
        url = request.Url
      , httpMethod = request.Method
      , headers = (request.Headers |> Seq.map(fun x -> x.Key,x.Value))
      , customizeHttpRequest =
          fun req ->
            req.ClientCertificates.Add(clientCert) |> ignore
            req
    )

  let private routeResponseWithCertificateAsync (clientCert: X509Certificate2) (route:IRoute) =
    task {
      try
        let! httpResponse = httpRequestAsync clientCert (route.Request)
        let opt = new RouteFulfillOptions()
        opt.Headers <- httpResponse.Headers |> Map.toSeq |> Seq.map(fun (k,v) -> KeyValuePair(k,v))
        opt.BodyBytes <-
          match httpResponse.Body with
          | Text text    -> System.Text.Encoding.UTF8.GetBytes(text)
          | Binary bytes -> bytes
        opt.ContentType <- httpResponse.Headers.Item("Content-Type")
        opt.Status <- httpResponse.StatusCode |> Nullable
        do! route.FulfillAsync(opt)
      with _ ->
        do! route.AbortAsync()
    }
    :> Task

  [<EntryPointAttribute>]
  let main _ =
    task {

      let url = "https://foo..."
      let urlPattern = "**/bar/"
      let clientCert =
        let cn = "baz"
        Certfs.GetCertificateByCommonName cn Certfs.myStoreName.My

      let! browser = Playwright.CreateAsync()
      let! edge = browser.Chromium.LaunchAsync(BrowserTypeLaunchOptions(Channel="msedge",Headless=false))
      let! context = edge.NewContextAsync()
      do! context.RouteAsync(urlPattern,(routeResponseWithCertificateAsync clientCert))
      let! page = context.NewPageAsync()
      do! sample url page
    }
    |> Task.WaitAll
    0

[standbyoneself]

Hello(｡･ω･｡)ﾉ

I've managed to implement and find a solution using F# (.NET) instead of JavaScript. It works properly. For your reference:

  let private httpRequestAsync (clientCert: X509Certificate2) (request: IRequest) =
    Http.AsyncRequest(
        url = request.Url
      , httpMethod = request.Method
      , headers = (request.Headers |> Seq.map(fun x -> x.Key,x.Value))
      , customizeHttpRequest =
          fun req ->
            req.ClientCertificates.Add(clientCert) |> ignore
            req
    )

  let private routeResponseWithCertificateAsync (clientCert: X509Certificate2) (route:IRoute) =
    task {
      try
        let! httpResponse = httpRequestAsync clientCert (route.Request)
        let opt = new RouteFulfillOptions()
        opt.Headers <- httpResponse.Headers |> Map.toSeq |> Seq.map(fun (k,v) -> KeyValuePair(k,v))
        opt.BodyBytes <-
          match httpResponse.Body with
          | Text text    -> System.Text.Encoding.UTF8.GetBytes(text)
          | Binary bytes -> bytes
        opt.ContentType <- httpResponse.Headers.Item("Content-Type")
        opt.Status <- httpResponse.StatusCode |> Nullable
        do! route.FulfillAsync(opt)
      with _ ->
        do! route.AbortAsync()
    }
    :> Task

  [<EntryPointAttribute>]
  let main _ =
    task {

      let url = "https://foo..."
      let urlPattern = "**/bar/"
      let clientCert =
        let cn = "baz"
        Certfs.GetCertificateByCommonName cn Certfs.myStoreName.My

      let! browser = Playwright.CreateAsync()
      let! edge = browser.Chromium.LaunchAsync(BrowserTypeLaunchOptions(Channel="msedge",Headless=false))
      let! context = edge.NewContextAsync()
      do! context.RouteAsync(urlPattern,(routeResponseWithCertificateAsync clientCert))
      let! page = context.NewPageAsync()
      do! sample url page
    }
    |> Task.WaitAll
    0

Does it work when there are multiple certificates in pop-up?

I have tried something similar but the main problem that my route doesn't intercepted because my website has OIDC authentication so many redirects occure. Any workarounds?

[callmekohei]

@standbyoneself

Does it work when there are multiple certificates in pop-up?
-> yes

I have tried something similar but the main problem that my route doesn't intercepted because my website has OIDC authentication so many redirects occure. Any workarounds?
-> I'm not quite sure about OIDC, sorry. However, could it be possible by capturing cookies for each connection? If that's the case, it seems doable.

[standbyoneself]

@standbyoneself

Does it work when there are multiple certificates in pop-up? -> yes

I have tried something similar but the main problem that my route doesn't intercepted because my website has OIDC authentication so many redirects occure. Any workarounds? -> I'm not quite sure about OIDC, sorry. However, could it be possible by capturing cookies for each connection? If that's the case, it seems doable.

Thanks for your reply, I'll take a look.

I'll publish my Java solution if I'll make it work.

[ilorwork]

I'll add my solution again since it works perfectly and even better than Cypress built-in solution:

A great workaround for Windows & Chromium users - using Windows Registry AutoSelectCertificateForUrls Chromium Policy

I’m demonstrating on Chromium/Chrome, but it’s the same for every other Chromium-based browser. (you just need to figure the exact key path)

For the Playwright Chromium browser you need to create this registry key:
HKEY_CURRENT_USER\\SOFTWARE\\Policies\\Chromium\\AutoSelectCertificateForUrls

Note: According to google-docs If you use the PC Chrome (i.e.
channel: "chrome")
you should use this path instead:
HKEY_CURRENT_USER\\SOFTWARE\\Policies\\Google\\Chrome\\AutoSelectCertificateForUrls

with this value pattern:

"1"="{\"pattern\":\"<https://www.example.com\>",\"filter\":{\"ISSUER\":{\"CN\":\"certificate issuer name\", \"L\": \"certificate issuer location\", \"O\": \"certificate issuer org\", \"OU\": \"certificate issuer org unit\"}, \"SUBJECT\":{\"CN\":\"certificate subject name\", \"L\": \"certificate subject location\", \"O\": \"certificate subject org\", \"OU\": \"certificate subject org unit\"}}}"

In this example I'm executing the CMD reg add command using node-js exec function:

const key = "HKEY_CURRENT_USER\\SOFTWARE\\Policies\\Chromium\\AutoSelectCertificateForUrls";
const value = "1";
const data = `{\\"pattern\\":\\"${url}\\",\\"filter\\":{\\"SUBJECT\\":{\\"CN\\":\\"${certName}\\"}}}`;

exec(`reg add "${key}" /v "${value}" /d "${data}"`);

Now, navigate to your site and the certificate pop-up shouldn't pop-up.

[standbyoneself]

I'll add my solution again since it works perfectly and even better than Cypress built-in solution:

A great workaround for Windows & Chromium users - using Windows Registry AutoSelectCertificateForUrls Chromium Policy

I’m demonstrating on Chromium/Chrome, but it’s the same for every other Chromium-based browser. (you just need to figure the exact key path)

For the Playwright Chromium browser you need to create this registry key: HKEY_CURRENT_USER\\SOFTWARE\\Policies\\Chromium\\AutoSelectCertificateForUrls

Note: According to google-docs If you use the PC Chrome (i.e.
channel: "chrome")
you should use this path instead:
HKEY_CURRENT_USER\\SOFTWARE\\Policies\\Google\\Chrome\\AutoSelectCertificateForUrls

with this value pattern:

"1"="{\"pattern\":\"<https://www.example.com\>",\"filter\":{\"ISSUER\":{\"CN\":\"certificate issuer name\", \"L\": \"certificate issuer location\", \"O\": \"certificate issuer org\", \"OU\": \"certificate issuer org unit\"}, \"SUBJECT\":{\"CN\":\"certificate subject name\", \"L\": \"certificate subject location\", \"O\": \"certificate subject org\", \"OU\": \"certificate subject org unit\"}}}"

In this example I'm executing the CMD reg add command using node-js exec function:

const key = "HKEY_CURRENT_USER\\SOFTWARE\\Policies\\Chromium\\AutoSelectCertificateForUrls";
const value = "1";
const data = `{\\"pattern\\":\\"${url}\\",\\"filter\\":{\\"SUBJECT\\":{\\"CN\\":\\"${certName}\\"}}}`;

exec(`reg add "${key}" /v "${value}" /d "${data}"`);

Now, navigate to your site and the certificate pop-up shouldn't pop-up.

Thanks. It works not for Windows only, but it is a not flexy solution.

I build a platform with RBAC and I have about 10-20 certificates for QA stand (multiple roles).

Suppose, if I use Java, I wanna create the annotation @Cert(acc-1, acc-2, acc-3). It would run this test with 3 certificates, may be in parallel.

So it's about selecting certificates programmatically, wonder that it is not properly implemented by any framework.

P.S. Also this policy requires browser to be run headed which is also more expensive and more difficult especially in CI.

[callmekohei]

I think the solution using the registry is also very valuable. In fact, I was doing that too.However, not everyone can manipulate the registry.The method using F# prevents the pop-up from appearing in the first place, so I believe it has its own value.

[callmekohei]

I'm Sorry...

I mentioned in my previous post that I managed to get certificate authentication working with F# without touching the registry settings. Turns out, it was actually working because of some pre-existing registry settings I hadn't noticed. Sorry for the mix-up! Here's the code I was talking about:

  let private httpRequestAsync (clientCert: X509Certificate2) (request: IRequest) =
    Http.AsyncRequest(
        url = request.Url
      , httpMethod = request.Method
      , headers = (request.Headers |> Seq.map(fun x -> x.Key,x.Value))
      , customizeHttpRequest =
          fun req ->
            req.ClientCertificates.Add(clientCert) |> ignore
            req
    )

  let private routeResponseWithCertificateAsync (clientCert: X509Certificate2) (route:IRoute) =
    task {
      try
        let! httpResponse = httpRequestAsync clientCert (route.Request)
        let opt = new RouteFulfillOptions()
        opt.Headers <- httpResponse.Headers |> Map.toSeq |> Seq.map(fun (k,v) -> KeyValuePair(k,v))
        opt.BodyBytes <-
          match httpResponse.Body with
          | Text text    -> System.Text.Encoding.UTF8.GetBytes(text)
          | Binary bytes -> bytes
        opt.ContentType <- httpResponse.Headers.Item("Content-Type")
        opt.Status <- httpResponse.StatusCode |> Nullable
        do! route.FulfillAsync(opt)
      with _ ->
        do! route.AbortAsync()
    }
    :> Task

  [<EntryPointAttribute>]
  let main _ =
    task {

      let url = "https://foo..."
      let urlPattern = "**/bar/"
      let clientCert =
        let cn = "baz"
        Certfs.GetCertificateByCommonName cn Certfs.myStoreName.My

      let! browser = Playwright.CreateAsync()
      let! edge = browser.Chromium.LaunchAsync(BrowserTypeLaunchOptions(Channel="msedge",Headless=false))
      let! context = edge.NewContextAsync()
      do! context.RouteAsync(urlPattern,(routeResponseWithCertificateAsync clientCert))
      let! page = context.NewPageAsync()
      do! sample url page
    }
    |> Task.WaitAll
    0

Really sorry for sharing incorrect information earlier. This has been a good reminder of how important it is to fully understand all the elements behind a solution. Looking forward to learning more and contributing to the community. Thanks for your understanding!

@standbyoneself
@ilorwork

[ilorwork]

Thanks for your hard work and honesty. any kind of solution being found its a great progress.
I have to say that this registry solution I've posted saved my life...
After months of searching and kinda wasting my and team's time, I've almost quit Playwright and already started migrating to Cypress, I was very disappointed! and in my few last desperate attempts - I found this solution.