Workaround for ChromeDriver version 80 and later when used insecure domains

[netaskd]

Due to nearest changes in ChromeDriver using url like https://jitsi.meet/room is impossible, because the cert is not valid.

79.0.3945.16

• Removed --ignore-certificate-errors from Chrome launch command

80.0.3987.16

• ChromeDriver will add --ignore-certificate-errors flag when acceptInsecureCerts capability is true

The fix adds option setAcceptInsecureCerts = true to chromeOptions

[jitsi-jenkins]

Hi, thanks for your contribution!
If you haven't already done so, could you please make sure you sign our CLA (https://jitsi.org/icla for individuals and https://jitsi.org/ccla for corporations)? We would unfortunately be unable to merge your patch unless we have that piece :(.

[saghul]

👍 Maybe thheere should be a ssetting for it? At any rate, @bbaldino can you PTAL?

[maltokyo]

This is great. Can anyone confirm it fixes the issues?

[macoronado]

Its not working for my setup.
I got the same error with this pull:

jitsi/docker-jitsi-meet#420

org.jitsi.jibri.selenium.pageobjects.CallPage.visit()Visiting url https://meet.jitsi/pimpollo#config.iAmRecorder=true&config.externalConnectUrl=null&config.startWithAudioMuted=true&config.startWithVideoMuted=true&interfaceConfig.APP_NAME="Jibri"&config.analytics.disabled=true&config.p2p.enabled=false
org.jitsi.jibri.selenium.pageobjects.CallPage.visit() Timed out waiting for call page to load

The only thing I have diferent from default configuration is authentication via JWT.

[netaskd]

@macoronado your setup had been working on chrome/driver 78 ?

[teutat3s]

This is great. Can anyone confirm it fixes the issues?

Fixed the issue for our docker-jitsi-meet setup with internal auth.

I was wondering though if setting this is insecure in a non docker environment?

[netaskd]

This is great. Can anyone confirm it fixes the issues?

Fixed the issue for our docker-jitsi-meet setup with internal auth.

I was wondering though if setting this is insecure in a non docker environment?

If you use external connect from jibri to web jitsi-meet and have a hack like echo "144.144.144.144 jitsi.meet" >> /etc/hosts, I guess it is insecure.

For now logic takes xmpp domain that was sent from xmpp server

jibri/src/main/kotlin/org/jitsi/jibri/util/XmppUtils.kt

Line 30 in 78258b6

// The call url is constructed from the xmpp domain, an optional subdomain, and a callname like so:

and connect link to web jitsi-meet looks like https://XMPP_DOMAIN/room

Some time ago we've been discussed with @saghul this behavior and decided that we need to have an option for get on jibri url like https://FQDN/roomname (you can try to find the discuss in docker-jitsi-meet jibri PR). But it still here ;)

[bbaldino]

Hm, we're running chromedriver 80.0.3987.106 in prod and not seeing any issue? Maybe I'm misunderstanding what requires this.

[netaskd]

It needs for ignore certificate errors for dummy domains, in our case (docker-jitsi-meet) the dummy xmpp domain is "jitsi.meet". In your prod, I guess, you use real FQDN and trusted certificates, so it doesn't rise any issues.

[bbaldino]

Ok, just not sure accepting insecure certs is something we'd want to always turn on. Maybe it needs to be configurable.

[netaskd]

Oh, if it can be configurable, that's resolve the issue at all.
And if we could configure sending FQDN instead xmppDomain in request to recording string https://FQDN/roomname it'll make our life easier :)

[macoronado]

@macoronado your setup had been working on chrome/driver 78 ?

Its a new setup. I have been testing a bit and I found that if I change the val $baseUrl with my public URL in:

https://github.com/jitsi/jibri/blob/master/src/main/kotlin/org/jitsi/jibri/CallUrlInfo.kt

I dont know how that val is calculated initially. Now I get an ffmpeg error:

2020-04-23 18:31:50.882 INFO: [52] ffmpeg.call() [x11grab @ 0x56424ee19480] Stream #0: not enough frames to estimate rate; consider increasing probesize
2020-04-23 18:31:50.882 INFO: [52] ffmpeg.call() Input #0, x11grab, from ':0.0+0,0':
2020-04-23 18:31:50.882 INFO: [52] ffmpeg.call()   Duration: N/A, start: 1587666710.827857, bitrate: N/A
2020-04-23 18:31:50.882 INFO: [52] ffmpeg.call()     Stream #0:0: Video: rawvideo (BGR[0] / 0x524742), bgr0, 1280x720, 30 fps, 1000k tbr, 1000k tbn, 1000k tbc
2020-04-23 18:31:50.883 INFO: [52] ffmpeg.call() ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM bsnoop
2020-04-23 18:31:50.883 INFO: [52] ffmpeg.call() [alsa @ 0x56424ee20e80] cannot open audio device plug:bsnoop (No such file or directory)
2020-04-23 18:31:50.883 INFO: [52] ffmpeg.call() plug:bsnoop: Input/output error

Im lost because I have configured snd-aloop in my host and I have checked that is working from jibri with "aplay -l" and "arecord -l"

[netaskd]

cannot open audio device plug:bsnoop - possibly, ffmpeg do not see /home/jibri/.asoundrc
Anyway, it's not about this PR

[macoronado]

cannot open audio device plug:bsnoop - possibly, ffmpeg do not see /home/jibri/.asoundrc
Anyway, it's not about this PR

That was the issue, I updated the asoundrc file with the lastest from source code and its working now. Thank you! The only thing I dont understand its why I had to change the baseUrl parameter to make it work.

[bbaldino]

Can this be done with a chrome flag? Those are configurable now, but I'm not sure if there is an equivalent chrome flag to ChromeOption#setAcceptInsecureCerts. @saghul is this still needed?

[saghul]

I think the right way to fix this is to add a config option in Jibri to set the "base URL". If set we could use that to build the meeting URL instead of fishing it from the XMPP conference config. WDYT? I could try my hand at a patch next week I think!

[bbaldino]

I think the right way to fix this is to add a config option in Jibri to set the "base URL". If set we could use that to build the meeting URL instead of fishing it from the XMPP conference config. WDYT? I could try my hand at a patch next week I think!

I thought the issue was related to chrome loading an insecure URL, regardless of where the URL came from (the JID or some config)?

[saghul]

That's true, but the reason we end up loading an insecure site is because in Docker we use a non existing domain "meet.jitsi" which is routable only in the Docker environment. As a result, we don't have a valid cert.