Recording Fails with error - Failed to read the 'localStorage' property from 'Window': Access is denied for this document.

[Groot90]

OS: Ubuntu 19.04
Both jitsi-meet and jibri are running on the same machine.

Added this to /etc/hosts:
127.0.0.1 meet.jitsylocaltest123.io

I can visit this url locally, and I can start the call. However, any time I click "Start Recording" it fails to record.

/var/log/jitsi/jibri/log.0.txt contains this:

2020-01-23 22:52:28.485 INFO: [21] org.jitsi.xmpp.mucclient.MucClient.log() [MucClient id=meet.jitsylocaltest123.io hostname=meet.jitsylocaltest123.io] connected
2020-01-23 22:52:28.623 INFO: [21] org.jitsi.xmpp.mucclient.MucClient.log() Joined MUC: jibribrewery@internal.auth.meet.jitsylocaltest123.io
2020-01-23 22:52:52.592 INFO: [35] org.jitsi.jibri.api.xmpp.XmppApi.handleJibriIq() Received JibriIq <iq to='jibri@auth.meet.jitsylocaltest123.io/S5K5A663' from='jibribrewery@internal.auth.meet.jitsylocaltest123.io/focus' id='amlicmlAYXV0aC5tZWV0LmppdHN5bG9jYWx0ZXN0MTIzLmlvL1M1SzVBNjYzAENoUHBXLTc1NADCvs55nleU7z99y2$
2020-01-23 22:52:52.593 INFO: [35] org.jitsi.jibri.api.xmpp.XmppApi.handleStartJibriIq() Received start request
2020-01-23 22:52:52.602 INFO: [35] org.jitsi.jibri.api.xmpp.XmppApi.handleStartJibriIq() Sending 'pending' response to start IQ
2020-01-23 22:52:52.604 INFO: [36] org.jitsi.jibri.api.xmpp.XmppApi.run() Starting service
2020-01-23 22:52:52.695 INFO: [36] org.jitsi.jibri.api.xmpp.XmppApi.handleStartService() Parsed call url info: CallUrlInfo(baseUrl=https://meet.jitsylocaltest123.io, callName=b44, urlParams=[])
2020-01-23 22:52:52.702 INFO: [36] org.jitsi.jibri.JibriManager.startFileRecording() Starting a file recording with params: FileRecordingRequestParams(callParams=CallParams(callUrlInfo=CallUrlInfo(baseUrl=https://meet.jitsylocaltest123.io, callName=b44, urlParams=[])), sessionId=kxsegoqkqxpovaqb, callLoginParams=Xm$
2020-01-23 22:52:54.488 INFO: [36] org.openqa.selenium.remote.ProtocolHandshake.createSession() Detected dialect: OSS
2020-01-23 22:52:54.517 INFO: [36] org.jitsi.jibri.selenium.JibriSelenium.() Starting empty call check with a timeout of PT30S
2020-01-23 22:52:54.544 FINE: [36] org.jitsi.jibri.capture.ffmpeg.FfmpegCapturer.() Detected os as OS: LINUX
2020-01-23 22:52:54.551 INFO: [36] org.jitsi.jibri.service.impl.FileRecordingJibriService.() Writing recording to /home/gogi/recordings/kxsegoqkqxpovaqb
2020-01-23 22:52:54.553 FINE: [36] org.jitsi.jibri.statsd.JibriStatsDClient.incrementCounter() Incrementing statsd counter: start:recording
2020-01-23 22:52:54.555 INFO: [36] org.jitsi.jibri.status.JibriStatusManager.log() Busy status has changed: IDLE -> BUSY
2020-01-23 22:52:54.555 INFO: [36] org.jitsi.jibri.api.xmpp.XmppApi.updatePresence() Jibri reports its status is now JibriStatus(busyStatus=BUSY, health=OverallHealth(healthStatus=HEALTHY, details={})), publishing presence to connections
2020-01-23 22:52:54.555 INFO: [36] org.jitsi.xmpp.mucclient.MucClientManager.log() Setting a presence extension: org.jitsi.xmpp.extensions.jibri.JibriStatusPacketExt@57374463
2020-01-23 22:52:54.785 SEVERE: [46] org.jitsi.jibri.selenium.JibriSelenium.run() An error occurred while joining the call: org.openqa.selenium.WebDriverException: : Failed to read the 'localStorage' property from 'Window': Access is denied for this document.
(Session info: chrome=79.0.3945.130)
(Driver info: chromedriver=79.0.3945.36 (3582db32b33893869b8c1339e8f4d9ed1816f143-refs/branch-heads/3945@{#614}),platform=Linux 5.0.0-38-generic x86_64) (WARNING: The server did not provide any stacktrace information)
Command duration or timeout: 0 milliseconds
Build info: version: 'unknown', revision: 'unknown', time: 'unknown'
System info: host: 'gogi-VirtualBox', ip: '127.0.1.1', os.name: 'Linux', os.arch: 'amd64', os.version: '5.0.0-38-generic', java.version: '11.0.5'
Driver info: org.openqa.selenium.chrome.ChromeDriver
Capabilities {acceptInsecureCerts: false, acceptSslCerts: false, applicationCacheEnabled: false, browserConnectionEnabled: false, browserName: chrome, chrome: {chromedriverVersion: 79.0.3945.36 (3582db32b3389..., userDataDir: /tmp/.com.google.Chrome.bw91Cc}, cssSelectorsEnabled: true, databaseEnabled: false, goog:c$
Session ID: 5f5980f45da76f666cf4f1759808c2fa with stack:
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
org.openqa.selenium.remote.ErrorHandler.createThrowable(ErrorHandler.java:214)
org.openqa.selenium.remote.ErrorHandler.throwIfResponseFailed(ErrorHandler.java:166)
org.openqa.selenium.remote.http.JsonHttpResponseCodec.reconstructValue(JsonHttpResponseCodec.java:40)
org.openqa.selenium.remote.http.AbstractHttpResponseCodec.decode(AbstractHttpResponseCodec.java:80)
org.openqa.selenium.remote.http.AbstractHttpResponseCodec.decode(AbstractHttpResponseCodec.java:44)
org.openqa.selenium.remote.HttpCommandExecutor.execute(HttpCommandExecutor.java:158)
org.openqa.selenium.remote.service.DriverCommandExecutor.execute(DriverCommandExecutor.java:83)
org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:543)
org.openqa.selenium.remote.RemoteWebDriver.executeScript(RemoteWebDriver.java:480)
org.jitsi.jibri.selenium.JibriSelenium.setLocalStorageValues(JibriSelenium.kt:175)
org.jitsi.jibri.selenium.JibriSelenium.access$setLocalStorageValues(JibriSelenium.kt:112)
org.jitsi.jibri.selenium.JibriSelenium$joinCall$1.run(JibriSelenium.kt:255)
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
java.base/java.lang.Thread.run(Thread.java:834)

2020-01-23 22:52:54.786 INFO: [46] org.jitsi.jibri.selenium.JibriSelenium.onSeleniumStateChange() Transitioning from state Starting up to Error: SESSION Failed to join call
2020-01-23 22:52:54.788 INFO: [46] org.jitsi.jibri.service.impl.FileRecordingJibriService.onServiceStateChange() File recording service transitioning from state Starting up to Error: SESSION Failed to join call

I checked the threads about disabling "Block third party cookies" setting in Chrome - and it was already unchecked - still the same error.

[bbaldino]

Are you sure that setting is checked for the chrome instance that Jibri is using?

[bbaldino]

Did you check the community posts about similar issues? https://community.jitsi.org/search?q=Failed%20to%20read%20the%20%27localStorage%27%20property%20from%20%27Window%27%3A%20Access%20is%20denied%20for%20this%20document

[Groot90]

@bbaldino Yes, as far as I know there is only one Chrome installed. This Ubuntu installation is running inside a VirtualBox VM so I can login using graphical interface (gdm3) and run the chrome normally. I'm not sure how I can see the exact path / version of chrome which Jibri is running?

Edit:
Yes, I have checked those threads, but I couldn't solve it.
I can load the page locally, and I'm sure chrome / selenium can reach it. Also, the checkbox in Chrome didn't help.

[damencho]

You run chrome as your user. Selenium starts chrome in new user folder.

[Groot90]

@bbaldino @damencho Thank you for your help. I think that I found the root cause now. It's the SSL certificate used by the local jitsy meet server (the default self generated SSL certificate). I recompiled jibri with the following line added:
chromeOptions.setCapability(CapabilityType.ACCEPT_SSL_CERTS , true)
in the file jibri/src/main/kotlin/org/jitsi/jibri/selenium/JibriSelenium.kt and it did the trick.

I'm using this setup for just for local testing, so it should be good enough for now. When I need to use it in any other setup, I will obtain a valid certificate and this error should disappear.

However, it would be great if the logs could say something more specific, instead of
"Failed to read the 'localStorage' property from 'Window': Access is denied for this document.".

[Roy202]

You can add the CA certificate to the CA storage of the jibri's chrome :

certutil -d sql:/home/jibri/.pki/nssdb -A -t TC -n "CAAD" -i CAAD48.crt

It's simplier than recompile.

[elbow]

Hi,

Like many also stuck trying to get jibri in docker-jisti-meet to work.

I modified jibri itself like this:

diff --git a/src/main/kotlin/org/jitsi/jibri/selenium/JibriSelenium.kt b/src/main/kotlin/org/jitsi/jibri/selenium/JibriSelenium.kt
index ccc13c0..d6046fa 100644
--- a/src/main/kotlin/org/jitsi/jibri/selenium/JibriSelenium.kt
+++ b/src/main/kotlin/org/jitsi/jibri/selenium/JibriSelenium.kt
@@ -144,6 +144,11 @@ class JibriSelenium(
                 "--disable-infobars",
                 "--autoplay-policy=no-user-gesture-required"
         )
+        /* SLD: accept any cert */
+        logger.info("Steve says: attempt to tell Chrome to accept insecure certs")
+        chromeOptions.setCapability(CapabilityType.ACCEPT_SSL_CERTS, true)
+        chromeOptions.setCapability(CapabilityType.ACCEPT_INSECURE_CERTS, true)
+        /* ends */
         chromeOptions.setExperimentalOption("w3c", false)
         chromeOptions.addArguments(jibriSeleniumOptions.extraChromeCommandLineFlags)
         val chromeDriverService = ChromeDriverService.Builder().withEnvironment(

So this did help - it resolves the Access is denied:

2020-04-17 22:21:01.135 INFO: [42] org.jitsi.jibri.JibriManager.startFileRecording() Starting a file recording with params: FileRecordingRequestParams(callParams=CallParams(callUrlInfo=CallUrlInfo(baseUrl=https://meet.jits
i, callName=xyz, urlParams=[])), sessionId=yncnjdqaptfhrlel, callLoginParams=XmppCredentials(domain=recorder.meet.jitsi, username=recorder, password=elided)) finalize script path: /config/finalize
.sh and recordings directory: /config/recordings
2020-04-17 22:21:01.152 INFO: [42] org.jitsi.jibri.selenium.JibriSelenium.<init>() Steve says: attempt to tell Chrome to accept insecure certs
2020-04-17 22:21:01.910 INFO: [42] org.openqa.selenium.remote.ProtocolHandshake.createSession() Detected dialect: OSS
2020-04-17 22:21:01.927 INFO: [42] org.jitsi.jibri.selenium.JibriSelenium.<init>() Starting empty call check with a timeout of PT30S
2020-04-17 22:21:01.938 FINE: [42] org.jitsi.jibri.capture.ffmpeg.FfmpegCapturer.<init>() Detected os as OS: LINUX
2020-04-17 22:21:01.944 INFO: [42] org.jitsi.jibri.service.impl.FileRecordingJibriService.<init>() Writing recording to /config/recordings/yncnjdqaptfhrlel
2020-04-17 22:21:01.948 FINE: [42] org.jitsi.jibri.statsd.JibriStatsDClient.incrementCounter() Incrementing statsd counter: start:recording
2020-04-17 22:21:01.950 INFO: [42] org.jitsi.jibri.status.JibriStatusManager.log() Busy status has changed: IDLE -> BUSY
2020-04-17 22:21:01.950 INFO: [42] org.jitsi.jibri.api.xmpp.XmppApi.updatePresence() Jibri reports its status is now JibriStatus(busyStatus=BUSY, health=OverallHealth(healthStatus=HEALTHY, details={})), publishing presence
 to connections
2020-04-17 22:21:01.950 FINE: [42] org.jitsi.xmpp.mucclient.MucClientManager.log() Setting a presence extension: org.jitsi.xmpp.extensions.jibri.JibriStatusPacketExt@25218412
2020-04-17 22:21:01.951 FINE: [42] org.jitsi.xmpp.mucclient.MucClientManager.log() Replacing presence extension: org.jitsi.xmpp.extensions.jibri.JibriStatusPacketExt@68105edc
2020-04-17 22:21:01.955 FINE: [32] org.jitsi.xmpp.extensions.DefaultPacketExtensionProvider.parse() Could not add a provider for element busy-status from namespace http://jitsi.org/protocol/jibri
2020-04-17 22:21:01.955 FINE: [32] org.jitsi.xmpp.extensions.DefaultPacketExtensionProvider.parse() Could not add a provider for element health-status from namespace http://jitsi.org/protocol/health
2020-04-17 22:21:02.809 FINE: [54] org.jitsi.jibri.selenium.pageobjects.CallPage.visit() Visiting url https://meet.jitsi/xyz#config.iAmRecorder=true&config.externalConnectUrl=null&config.startWithAudioMuted=true&config.sta
rtWithVideoMuted=true&interfaceConfig.APP_NAME="Jibri"&config.analytics.disabled=true&config.p2p.enabled=false
2020-04-17 22:21:33.408 SEVERE: [54] org.jitsi.jibri.selenium.pageobjects.CallPage.visit() Timed out waiting for call page to load
2020-04-17 22:21:33.410 INFO: [54] org.jitsi.jibri.selenium.JibriSelenium.onSeleniumStateChange() Transitioning from state Starting up to Error: FailedToJoinCall SESSION Failed to join the call

So the call page fails to load.

I think the reason is CORS. The browser.0.log has:

2020-04-17 22:21:33.490 INFO: [54] browser.leaveCallAndQuitBrowser() [2020-04-17T22:21:03+0200] [SEVERE] https://meet.jitsi/xyz#config.iAmRecorder=true&config.externalConnectUrl=null&config.startWithAudioMuted=true&config.startWithVideoMuted=true&interfaceConfig.APP_NAME=%22Jibri%22&config.analytics.disabled=true&config.p2p.enabled=false - Access to XMLHttpRequest at 'https://conf.elided.com/http-bind?room=xyz' from origin 'https://meet.jitsi' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

This is confusing since this method logged is "leaveCallAndQuitBrowser". But I presume that is CORS policy blocked this request it would have blocked earlier requests too.

Since API requests to the jitsi-meet server side fail that is a a credible explanation as to why the call page didn't load.

So it does seem like adding a "Access-Control-Allow-Origin: *" on the Jitsi-meet side might dodge this but I'm not sure if that is safe - don't know how these API calls are protected.

Otherwise jibri really needs to use the proper name of the jitsi-meet instance and not meet.jitsi.

[elbow]

Otherwise jibri really needs to use the proper name of the jitsi-meet instance and not meet.jitsi.

In the context of docker-jitsi-meet, where this should "just work" it definitely doesn't.

So for this case:

Inside the jibri container there is a /etc/jitsi/jibri/config.json

Unlike the other containers this is not on a volume, it appears to be generated from the .env with the help of jibri/rootfs/defaults/config.json - which is inside the container as /defaults/config.json.

Anyway, in there it says:

            // When jibri gets a request to start a service for a room, the room
            //  jid will look like:
            //  roomName@optional.prefixes.subdomain.xmpp_domain
            // We'll build the url for the call by transforming that into:
            //  https://xmpp_domain/subdomain/roomName
            // So if there are any prefixes in the jid (like jitsi meet, which
            //  has its participants join a muc at conference.xmpp_domain) then
            //  list that prefix here so it can be stripped out to generate
            //  the call url correctly
            "room_jid_domain_string_to_strip_from_start": "muc.",

We end up at https://meet.jitsi since we are talking to xmpp.jitsi.meet.

So this won't work inside docker with the use or jitsi.meet and the internal docker addresses.

And it doesn't look like there is a way to tell it the real domain.

So it looks like jibri needs a new config element in config.json which allows you to "fix" the conference domain and I can then put in https://conf.elided.com/ resulting in ChomeDriver opening the call page on the right domain that has the right cert and isn't cross-domain.

So I'm going to try to make this change

[jca27]

I'm having trouble recompiling Jibri after making the changes to the JibriSelenium.kt file.
Sorry, I am not particulary familiar with kotlinc, so any help compiling and copying the new code over would be great. Thanks!
--Solved: Maven solved it

[bbaldino]

I'm having trouble recompiling Jibri after making the changes to the JibriSelenium.kt file.
Sorry, I am not particulary familiar with kotlinc, so any help compiling and copying the new code over would be great. Thanks!

This is a good topic for the community forum, please start a thread at community.jitsi.org.

[RAJANAGORI]

You can add the CA certificate to the CA storage of the jibri's chrome :

certutil -d sql:/home/jibri/.pki/nssdb -A -t TC -n "CAAD" -i CAAD48.crt

It's simplier than recompile.

Hi, Could you please mention the steps of your solution?

[antuanix]

Based on comment from @elbow I solved the problem by extending the jibri.yml file with the followin:
links:
- web:meet.jitsi

This way for the jibri container resolves meet.jitsi internally to the web container