Docker Server Api Call ERROR - Strophe: Server did not yet offer a supported authentication mechanism. Sending a blank poll request

I am using Docker Jitsi server and it is working nicely… though I am running it in local environment I made the connection secure with custom certificate for https://fuji (in private ip by configuring /etc/hosts).

secure jitsi docker server pic (working fine normally)

And I am calling external api (to create a room in that server) from an angular app running at my https://localhost:4200

secured angular app connection pic

now while calling the api I am getting error in console log :

"Strophe: Server did not yet offer a supported authentication mechanism. Sending a blank poll request"

and the after a while (1 min, though it was successful sometimes) :

"blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource"



Though I did everything like :

  • consider_bosh_secure = true
  • cross_domain_bosh = true
  • made secure https connection for both jitsi and angular server
  • curl -i https://fuji says it is working

what is the problem actually about? I thought it was just a certificate problem but now I am afraid because I am totally stuck here for few days and couldn’t find any suitable solution anywhere… what should I do ? it is totally working fine normally but the problem occurs when api is called from angular app.I asked earlier but everyone thought it was a certificate pb then. Plz help …!!
edit : I am creating the API by giving a custom layer in front of lib-jitsi-meet
@saghul @damencho @Boris_Grozev
Thanx in advance for any help :heart: :slightly_smiling_face:

@saghul @damencho
I also put consider_bosh_secure=true in prosody.cfg.lua



-- Prosody Example Configuration File
--
-- Information on configuring Prosody can be found on our
-- website at http://prosody.im/doc/configure
--
-- Tip: You can check that the syntax of this file is correct
-- when you have finished by running: luac -p prosody.cfg.lua
-- If there are any errors, it will let you know what and where
-- they are, otherwise it will keep quiet.
--
-- The only thing left to do is rename this file to remove the .dist ending, and fill in the
-- blanks. Good luck, and happy Jabbering!


---------- Server-wide settings ----------
-- Settings in this section apply to the whole server and are the default settings
-- for any virtual hosts

-- This is a (by default, empty) list of accounts that are admins
-- for the server. Note that you must create the accounts separately
-- (see http://prosody.im/doc/creating_accounts for info)
-- Example: admins = { "user1@example.com", "user2@example.net" }
admins = { }

-- Enable use of libevent for better performance under high load
-- For more information see: http://prosody.im/doc/libevent
--use_libevent = true;

-- This is the list of modules Prosody will load on startup.
-- It looks for mod_modulename.lua in the plugins folder, so make sure that exists too.
-- Documentation on modules can be found at: http://prosody.im/doc/modules
modules_enabled = {
		"muc_size";
	-- Generally required
		"roster"; -- Allow users to have a roster. Recommended ;)
		"saslauth"; -- Authentication for clients and servers. Recommended if you want to log in.
		"tls"; -- Add support for secure TLS on c2s/s2s connections
		"dialback"; -- s2s dialback support
		"disco"; -- Service discovery

	-- Not essential, but recommended
		"private"; -- Private XML storage (for room bookmarks, etc.)
		"vcard"; -- Allow users to set vCards
	
	-- These are commented by default as they have a performance impact
		--"privacy"; -- Support privacy lists
		--"compression"; -- Stream compression (Debian: requires lua-zlib module to work)

	-- Nice to have
		"version"; -- Replies to server version requests
		"uptime"; -- Report how long server has been running
		"time"; -- Let others know the time here on this server
		"ping"; -- Replies to XMPP pings with pongs
		"pep"; -- Enables users to publish their mood, activity, playing music and more
		"register"; -- Allow users to register on this server using a client and change passwords

	-- Admin interfaces
		"admin_adhoc"; -- Allows administration via an XMPP client that supports ad-hoc commands
		--"admin_telnet"; -- Opens telnet console interface on localhost port 5582
	
	-- HTTP modules
		--"bosh"; -- Enable BOSH clients, aka "Jabber over HTTP"
		--"http_files"; -- Serve static files from a directory over HTTP

	-- Other specific functionality
		"posix"; -- POSIX functionality, sends server to background, enables syslog, etc.
		--"groups"; -- Shared roster support
		--"announce"; -- Send announcement to all online users
		--"welcome"; -- Welcome users who register accounts
		--"watchregistrations"; -- Alert admins of registrations
		--"motd"; -- Send a message to users when they log in
		--"legacyauth"; -- Legacy authentication. Only used by some old clients and bots.
        
};

https_ports = { }

-- These modules are auto-loaded, but should you want
-- to disable them then uncomment them here:
modules_disabled = {
	-- "offline"; -- Store offline messages
	-- "c2s"; -- Handle client connections
	-- "s2s"; -- Handle server-to-server connections
};

enable_roomsize_token_verification=false;

-- Disable account creation by default, for security
-- For more information see http://prosody.im/doc/creating_accounts
allow_registration = false;

daemonize = false;

pidfile = "/config/data/prosody.pid";


-- Force clients to use encrypted connections? This option will
-- prevent clients from authenticating unless they are using encryption.

c2s_require_encryption = false;


--The traditional solution to solving the same-origin problem is to have the web server that serves the app script also act as a proxy to the real BOSH server at some URL.
consider_bosh_secure = true

--There is a relatively new HTTP extension that allows web servers to tell browsers that cross-domain requests are ok and permitted, called CORS.
cross_domain_bosh = true

-- Force certificate authentication for server-to-server connections?
-- This provides ideal security, but requires servers you communicate
-- with to support encryption AND present valid, trusted certificates.
-- NOTE: Your version of LuaSec must support certificate verification!
-- For more information see http://prosody.im/doc/s2s#security

s2s_secure_auth = false;

-- Many servers don't support encryption or have invalid or self-signed
-- certificates. You can list domains here that will not be required to
-- authenticate using certificates. They will be authenticated using DNS.

--s2s_insecure_domains = { "gmail.com" }

-- Even if you leave s2s_secure_auth disabled, you can still require valid
-- certificates for some domains by specifying a list here.

--s2s_secure_domains = { "jabber.org" }

-- Select the authentication backend to use. The 'internal' providers
-- use Prosody's configured data storage to store the authentication data.
-- To allow Prosody to offer secure authentication mechanisms to clients, the
-- default provider stores passwords in plaintext. If you do not trust your
-- server please see http://prosody.im/doc/modules/mod_auth_internal_hashed
-- for information about using the hashed backend.

authentication = "internal_plain";

-- Select the storage backend to use. By default Prosody uses flat files
-- in its configured data directory, but it also supports more backends
-- through modules. An "sql" backend is included by default, but requires
-- additional dependencies. See http://prosody.im/doc/storage for more info.

--storage = "sql" -- Default is "internal" (Debian: "sql" requires one of the
-- lua-dbi-sqlite3, lua-dbi-mysql or lua-dbi-postgresql packages to work)

-- For the "sql" backend, you can uncomment *one* of the below to configure:
--sql = { driver = "SQLite3", database = "prosody.sqlite" } -- Default. 'database' is the filename.
--sql = { driver = "MySQL", database = "prosody", username = "prosody", password = "secret", host = "localhost" }
--sql = { driver = "PostgreSQL", database = "prosody", username = "prosody", password = "secret", host = "localhost" }

-- Logging configuration
-- For advanced logging see http://prosody.im/doc/logging
--
-- Debian:
--  Logs info and higher to /var/log
--  Logs errors to syslog also



log = {
	{ levels = {min = "info"}, to = "console"};
}



component_interface = { "*" }

data_path = "/config/data"

Include "conf.d/*.cfg.lua"

but nothing worked,same error… is this can be any problem from api? bcz I am not finding any difficulties creating room by going to server… the problem occurs when I make a external api call? should I update strophe.js or make some change in middleware ? or there is a sequence issue creating this problem?
Thanx in advance :heart:

The problem here is you are accessing your app at localhost:4200 and bosh is using localhost:8080. Make them use the same port.

1 Like

Oh…! I actually have little knowledge about how bosh works :confused: and dependent to calling origin port…!
But I am having same problem after running the angular app at https://localhost:8080 but same “Strophe:server did not…” is this

Error Message pic

actually what is happening here…! I m getting so depressed stucking here :upside_down_face:
we are not having problem calling https://meet.jit.si from this app then why not my https://fuji …!
is there something silly mistake I am doing? is there any other issue possible while calling from an app? is this problem for docker only?

Network while calling

isnt bosh working in 5280 port? but if I wanna run angular app in this port,it says “port already in use” as expected :slightly_smiling_face:
Plz help me @damencho and srry for late reply…!! @saghul
Thanx in advance for any suggestion and instruction :heart: :upside_down_face:

@saghul
I added : ports:
- “5280:5280”
in prosody service in docker compose yml file to access the 5280 port of internal network…
http
can that be a pb running angular app in same port? but

  • the api call is working for https://meet.jit.si from my angular app and
  • my docker jitsi server is working normally fine without api call
    then where the pb can be?

I think this is my type of issue : https://github.com/jitsi/docker-jitsi-meet/issues/87 which go unnoticed,plz take a look
is this about server config? I did add consider bosh secure and cross domain bosh secure at top of prosody general config…
I am just getting mad :disappointed:

Hi @saghul @damencho
I solved the issue primarily by following exactly https://github.com/jitsi/docker-jitsi-meet/issues/87 solution
I had to edit the “hosts” portion in the api that I made from lib-jitsi-meet :

hosts: {
        domain: "meet.jitsi", //meet.jitsi is the internal network of docker-compose
        muc: "muc.meet.jitsi", //check to use muc.meet.jitsi as it is conference.your.domain for normal 
        anonymousdomain: "meet.jitsi" //don't need if no anonymus is allowed
       },
      bosh: "https://fuji/http-bind" //here "fuji" is 192.168.0.149 which is the private ip of mine, and I edited /etc/hosts to access the ip with name "fuji" and this is the name used for hosting the docker jitsi server
}

now I am good with calling from the angular app and working fine with 2 or more user in my pc with differenet tabs in chrome.

working pic

" But, The problem is, it is having problem accessing from another pc in same network. My angular app is showing that another user has joined but there is no audio/video incoming/outgoing, just a instance ".
in console log in that pc :

Bridge Channel send : no opened channel

in the container log :

SCTP connection with ${participants_id} not ready
No available transport channel, can't send a message

Any idea ? should I create new topic about this as this is docker issue and api from lib jitsi meet? :slightly_smiling_face:

@damencho I did some digging and found out that may b this is happening because my jvb container port 4443/tcp,10000/udp is unaccessible from public (even in same network)?
I can access web,prosody container ports both from inside and outside my ip.
I cant even access these jvb container ports locally from my pc :confused: though it works fine in my pc, pb occurs when other pc in same network make the api call. when 3rd participant joins,one need to reconnect. actually the pb is may b the jvb bcz I tried after stopping the jvb container in my pc and the same result what happened from other pc…

Detailed pic of port stats, container stats and accesibility to ports

what should I do ? I tried enabling firewall and opening that ports but same result.
Thanx in advance :heart:

You cannot telnet to port 10000 because that’s UDP.

how can I solve it? as it is working fine in my pc in different chrome tabs bt not among different pc in same network?

Looks like you are exporting the Docker ports just fine. Do you have a firewall in your machine? Run ufw status to check.

yeah… I enabled but ufw was not enabled first… then I enabled every port I needed bt same
ufw
I ran without jvb container only and the output was same… so I thought may be the problem mainly is about jvb container port which isn’t accessible… may be…! any idea?
last time I was trying some changes and suddenly it was working with two machines… but then suddenly not… may be simple bt imp misconfiguration…! should I try using 4443/tcp rather than 10000/udp? will there be any benifit? because for the first two user (p2p) it is working fine with 2 machines…! when the 3rd user comes,some problems start occuring…
Thanx in advance :heart:

@saghul Now I am seeing that in normal access is not happening when two machines connect to same room in https://fuji :slightly_smiling_face:
when the 3rd user joins… video/audio gone and no open bridge channel error …!
plz help…! @damencho

@saghul
solved the issue…env file I didnt uncomment the

#DOCKER_HOST_ADDRESS=192.168.0.149

because I ran by this before … and by inspecting I saw it was set randomly whether I set it by my private ip or not…
and then I saw it was not having problem passing audio/video from my pc(different chrome tabs) in my ip bt pb occurs when another pc in same network connects and dont pass audio/video… actually what is the pb?
should I set it to my private ip for now? and if so when I am gonna deploy it in production server what ip should I use for dockerhost? Thanx in advance… ! I didnt even think it would cause such problem…