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.
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?
In the end my holiday was over sooner than planned
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.
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.
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:-
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.
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
