Kopano Meet guests being prompted for credentials

Apps & App Center
#1

I have installed Kopano Meet and have it working fine for Univention users be they on the same LAN as the Meet server or remote.

However, when I create a group with public access allowed, the link made available to share is along the lines of:-

https://meet.mydomain.com/meet/r/group/public/GroupName#guest=1

That seem’s fine from the documentation, but when the invitee clicks on that link they are redirected to:-

https://meet.mydomain.com/signin/v1/identifier?client_id=kopano-meet&code_challenge=......

Where they are presented with a UCS login prompt.

Just wondering if I’ve missed something simple during configuration? Everything works fine for authenticated UCS users.

#2

Hi @tose,

since you seem to be running meet and openid on the same domain, did you rerun the join script after changing domains?

For further debugging it would be interesting what the response to the above http request was, as well as what konnect and kwmserver did log at that time. It may be required to up logging for both services to get a meaningful response, though.

Logging can be changed with an override file. An example is located at https://stash.z-hub.io/projects/K4U/repos/kopano-apps/browse/kopano-meet/docker-compose.override.yml

#4

Hi Felix,

Yes, I definitely re-ran the domain join scripts for both Meet & OpenID & they completed successfully.

I used the BirdEatsBug tool I’ve seen you refer to in other posts to capture the below response to the http request:-

0:36		
Navigated to https://meet.mydomain.com/meet/r/group/public/TG1#guest=1
0:36		
prev state{…}
0:36		
action{…}
0:36		
next state{…}
0:36		
localeen-GB
0:36		
moment localeen-gb
0:36		
prev state{…}
0:36		
action{…}
0:36		
next state{…}
0:36		
Loaded persisted store data
0:36		
Kopano KWM js version: 1.1.1
0:36		
media global settings{…} {…}
0:36		
using supportedConstraints{…}
0:36		
using audio/video bugs list{…}
0:36		
Is mobilefalse
0:36		
Is touch device0
0:36		
prev state{…}
0:36		
action{…}
0:36		
next state{…}
0:36		
prev state{…}
0:36		
action{…}
0:36		
next state{…}
0:36		
prev state{…}
0:36		
action{…}
0:36		
next state{…}
0:36		
prev state{…}
0:36		
action{…}
0:36		
next state{…}
0:36		
oidc user unloaded
0:36		
prev state{…}
0:36		
action{…}
0:36		
next state{…}
0:36		
POST https://meet.mydomain.com/api/kwm/v2/guest/logon 403
0:36		
prev state{…}
0:36		
action{…}
0:36		
next state{…}
0:36		
try guest logon failedError
    at https://meet.mydomain.com/meet/static/js/7.12ebb414.chunk.js?__WB_REVISION__=73c4b07a44a1b8d3227e:1:262355
0:36		
ResponseValidator._processSigninParams: Response was errorlogin_required
0:36		
oidc silent sign-in failedErrorResponse: IdentifierIdentityManager: not signed in
    at new e (https://meet.mydomain.com/meet/static/js/7.12ebb414.chunk.js?__WB_REVISION__=73c4b07a44a1b8d3227e:1:46589)
    at t._processSigninParams (https://meet.mydomain.com/meet/static/js/7.12ebb414.chunk.js?__WB_REVISION__=73c4b07a44a1b8d3227e:1:250342)
    at t.validateSigninResponse (https://meet.mydomain.com/meet/static/js/7.12ebb414.chunk.js?__WB_REVISION__=73c4b07a44a1b8d3227e:1:248168)
    at https://meet.mydomain.com/meet/static/js/7.12ebb414.chunk.js?__WB_REVISION__=73c4b07a44a1b8d3227e:1:51066
0:36		
prev state{…}
0:36		
action{…}
0:36		
next state{…}
0:36		
prev state{…}
0:36		
action{…}
0:36		
next state{…}
0:36		
app initialized
0:46		
oidc user unloaded
0:46		
POST https://meet.mydomain.com/api/kwm/v2/guest/logon 403
0:46		
Navigated to https://meet.mydomain.com/signin/v1/identifier?client_id=kopano-meet&code_challenge=fUAAMtaZb1I0zaRu05yEjKBz-_oDhR4CeqreFsqo-m8%3D&code_challenge_method=S256&flow=oidc&nonce=vBw7w4Duz3tLL3BJOmwonoKuBtk-qtg6dZ5f-XYKGqc%3D&prompt=select_account&redirect_uri=https%3A%2F%2Fmeet.mydomain.com%2Fkopanoid%2Fsignin%2Fv1%2Fidentifier%2Foauth2%2Fcb&response_mode=query&response_type=id_token&scope=openid+profile+email&state=PxQpg930sjqRuSsFCoA1px1F-w3juX5Rvb1IU8-fDbg%3D

So it looks as though guest login is being denied, hence the redirection to a UCS login page.

My docker foo is not particularly strong so it may take some time to gather the logging you requested. I assume that occurs within the Meet docker container?

#5

by this output the logging of kwmserver could be interesting.

disclaimer: I am this week not in the (home-)office. If you have a subscription I would recommend to get in direct contact with the kopano support.

#6

Thanks for the response Felix. I have raised a ticket with Kopano support & will report any findings/resolution back here for the benefit of others.

1 Like
#7

In the end my holiday was over sooner than planned :smiley:

I did look a bit further into this and it turns out that repeated restarts of the app incorrectly patch the identifier registration, which leads to the client registration going missing.

The quick fix is to delete /etc/kopano/docker/konnectd-identifier-registration.yaml and then call docker-compose restart from within /home/fbartels/dev-workspace/univention/kopano-apps/kopano-meet. This will create the file with all needed parts again.

A proper fix for this is included in the 2.1.0 app update which I just submitted to Univention for testing.

#8

Hi again Felix,

I have been corresponding with Kopano support on this issue and they did indeed advise me to take the actions you have mentioned above. In my case however, it did not resolve the issue, and on following the guest link an invitee still lands on a UCS login prompt.

Kopano support acknowledged that at least one other customer has had the same experience as me. While not yet available from the “production” UCS AppCenter repository, an updated Meet package designed to fix the problem is available in the “Test” UCS AppCenter repository.

My preference will be to wait for the updated App to be approved by Univention and hence available from the production AppCenter repository, but I mention this for the benefit of others who may experience the same issue.

I will report my findings back here when that happens.

#9

Hi @tose,

the app update has meanwhile been released by Univention.

If it still does not work afterwards I’d recommend to ask for a remote session.

#10

Hi again Felix,

I’ve now installed the updated Kopano Meet (2.1.0_0-1) and it does to some extent solve the problem. Some invitees could navigate to the public meeting while some were again prompted for UCS credentials. In those cases I found that deleting Cookies solved the issue in some browsers but not in others. (Gotta love modern web browsers NOT)

What I did eventually discover was this. The url for the meeting made available is in the following format:-

https://host.mydomain.com/meet/r/group/public/GroupName

Once a browser has successfully navigated into the meeting the url showing in the address bar is as follows:-

https://host.mydomain.com/meet/r/group/public/GroupName#guest=1

So, out of curiosity I went back to one of the browsers that continued to land on a UCS login page and pasted the 2nd url into the address bar. Hey presto, successful navigation into the public meeting. So again I suspect that there is a slight issue with the way the url is handled in certain browsers. I try for the most part to stick to Chrome for anything UCS related but could not nail down a particular Chrome version or OS that suffered this particular problem.

I hope these shreds of info might be helpful to other users & maybe even the Meet devs.

#11

Hi @tose,

hm… with the 2.1 release there is a new guest flow, which also comes with a new url endpoint. New guest urls look like this (this is what is sent when you share the link from inside of Meet or invite via mail):

https://domain/meet/r/join/group/public/groupname

The url endpoint (/meet//r/join) was previously only for logged in users and therefore if someone has used guest access in the past and Meet still cached (read: nothing to do with cookies, but the browser cache) then he could see the login screen instead of the actual new guest flow.

There is a notice about this in the update readme in the appcenter:

<li>this release features a new and improved guest login workflow where guests have the possibility to give their name and check microphone/webcam before joining a call</li>
<li>guests that have used a previous release will need to reload Meet manually to see the new guest flow</li>

Reloading Meet will bring the guest to the right url.

Once the guest has completed the guest flow he will indeed be redirected to a url that ends with /meet/r/group/public/groupname#guest=1

#12

Thanks again Felix. Absolutely correct. Mathias from Kopano support has also drawn this to my attention. Not sure how I missed that :astonished:

1 Like
Mastodon