[jitsi-dev] locking down jitmeet


#1

Hi,

I've discussed this before on list about 1 year ago and I'm sure others are
also interested in this topic.

Here's what I've done so far to lock down access to my jitmeet installation.
I have enabled authentication = "internal_plain" in my prosody's virtual
host config, and indeed now anyone who wants to use my jitmeet server needs
to enter their xmpp creds.

This works well enough but I was thinking about how I could configure
prosody and jitmeet for the following scenario:

- I would like to force only the creators of a room to have to
authenticate, not the participants. The participants wouldn't be able to
create rooms on their own but would still be able to join an already
existing room simpy by clicking the link.

Unfortunately it seems to me that prosody's authentication works in an all
or nothing fashion. Is anyone aware of a prosody module and/or jitmeet hack
that would allow me to force authentication only for room creators?

Cheers,

Peter


#2

This is already possible. You have to allow muc creation for local domain
users only (anonymous are on a different domain). Jitsi Meet will ask you
to authenticate when a muc does not exist and that is the case. Hence only
room creators would need to do it.

--sent from my mobile

···

On 15 Nov 2014 4:18 PM, "Peter Villeneuve" <petervnv1@gmail.com> wrote:

Hi,

I've discussed this before on list about 1 year ago and I'm sure others
are also interested in this topic.

Here's what I've done so far to lock down access to my jitmeet
installation.
I have enabled authentication = "internal_plain" in my prosody's virtual
host config, and indeed now anyone who wants to use my jitmeet server needs
to enter their xmpp creds.

This works well enough but I was thinking about how I could configure
prosody and jitmeet for the following scenario:

- I would like to force only the creators of a room to have to
authenticate, not the participants. The participants wouldn't be able to
create rooms on their own but would still be able to join an already
existing room simpy by clicking the link.

Unfortunately it seems to me that prosody's authentication works in an all
or nothing fashion. Is anyone aware of a prosody module and/or jitmeet hack
that would allow me to force authentication only for room creators?

Cheers,

Peter

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

Ah. I see. That's great.

I presume I have to set restrict_room_creation to local as seen here
http://prosody.im/doc/modules/mod_muc ?
Is that all I need to do?

Cheers

···

On Sat, Nov 15, 2014 at 3:22 PM, Emil Ivov <emcho@jitsi.org> wrote:

This is already possible. You have to allow muc creation for local domain
users only (anonymous are on a different domain). Jitsi Meet will ask you
to authenticate when a muc does not exist and that is the case. Hence only
room creators would need to do it.

--sent from my mobile
On 15 Nov 2014 4:18 PM, "Peter Villeneuve" <petervnv1@gmail.com> wrote:

Hi,

I've discussed this before on list about 1 year ago and I'm sure others
are also interested in this topic.

Here's what I've done so far to lock down access to my jitmeet
installation.
I have enabled authentication = "internal_plain" in my prosody's virtual
host config, and indeed now anyone who wants to use my jitmeet server needs
to enter their xmpp creds.

This works well enough but I was thinking about how I could configure
prosody and jitmeet for the following scenario:

- I would like to force only the creators of a room to have to
authenticate, not the participants. The participants wouldn't be able to
create rooms on their own but would still be able to join an already
existing room simpy by clicking the link.

Unfortunately it seems to me that prosody's authentication works in an
all or nothing fashion. Is anyone aware of a prosody module and/or jitmeet
hack that would allow me to force authentication only for room creators?

Cheers,

Peter

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

Answering my own question, that didn't seem to do the trick.
I set restrict_room_creation = local according to the mod_muc link above,
but I'm still able to create rooms anonymously.
Strangely I don't see any errors in the prosody logs.

I have my domain set to anonymous authentication in prosody's config.
If I change it to authentication = "internal_hashed", I do get prompted for
my creds, but so do people just clicking the invite link.

Anyone have a working config they could share?

Cheers

···

On Sat, Nov 15, 2014 at 3:29 PM, Peter Villeneuve <petervnv1@gmail.com> wrote:

Ah. I see. That's great.

I presume I have to set restrict_room_creation to local as seen here
http://prosody.im/doc/modules/mod_muc ?
Is that all I need to do?

Cheers

On Sat, Nov 15, 2014 at 3:22 PM, Emil Ivov <emcho@jitsi.org> wrote:

This is already possible. You have to allow muc creation for local domain
users only (anonymous are on a different domain). Jitsi Meet will ask you
to authenticate when a muc does not exist and that is the case. Hence only
room creators would need to do it.

--sent from my mobile
On 15 Nov 2014 4:18 PM, "Peter Villeneuve" <petervnv1@gmail.com> wrote:

Hi,

I've discussed this before on list about 1 year ago and I'm sure others
are also interested in this topic.

Here's what I've done so far to lock down access to my jitmeet
installation.
I have enabled authentication = "internal_plain" in my prosody's virtual
host config, and indeed now anyone who wants to use my jitmeet server needs
to enter their xmpp creds.

This works well enough but I was thinking about how I could configure
prosody and jitmeet for the following scenario:

- I would like to force only the creators of a room to have to
authenticate, not the participants. The participants wouldn't be able to
create rooms on their own but would still be able to join an already
existing room simpy by clicking the link.

Unfortunately it seems to me that prosody's authentication works in an
all or nothing fashion. Is anyone aware of a prosody module and/or jitmeet
hack that would allow me to force authentication only for room creators?

Cheers,

Peter

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

You have to make sure that your anonymous domain is different than your
local domain. Is that the case?

--sent from my mobile

···

On 15 Nov 2014 6:12 PM, "Peter Villeneuve" <petervnv1@gmail.com> wrote:

Answering my own question, that didn't seem to do the trick.
I set restrict_room_creation = local according to the mod_muc link above,
but I'm still able to create rooms anonymously.
Strangely I don't see any errors in the prosody logs.

I have my domain set to anonymous authentication in prosody's config.
If I change it to authentication = "internal_hashed", I do get prompted
for my creds, but so do people just clicking the invite link.

Anyone have a working config they could share?

Cheers

On Sat, Nov 15, 2014 at 3:29 PM, Peter Villeneuve <petervnv1@gmail.com> > wrote:

Ah. I see. That's great.

I presume I have to set restrict_room_creation to local as seen here
http://prosody.im/doc/modules/mod_muc ?
Is that all I need to do?

Cheers

On Sat, Nov 15, 2014 at 3:22 PM, Emil Ivov <emcho@jitsi.org> wrote:

This is already possible. You have to allow muc creation for local
domain users only (anonymous are on a different domain). Jitsi Meet will
ask you to authenticate when a muc does not exist and that is the case.
Hence only room creators would need to do it.

--sent from my mobile
On 15 Nov 2014 4:18 PM, "Peter Villeneuve" <petervnv1@gmail.com> wrote:

Hi,

I've discussed this before on list about 1 year ago and I'm sure others
are also interested in this topic.

Here's what I've done so far to lock down access to my jitmeet
installation.
I have enabled authentication = "internal_plain" in my prosody's
virtual host config, and indeed now anyone who wants to use my jitmeet
server needs to enter their xmpp creds.

This works well enough but I was thinking about how I could configure
prosody and jitmeet for the following scenario:

- I would like to force only the creators of a room to have to
authenticate, not the participants. The participants wouldn't be able to
create rooms on their own but would still be able to join an already
existing room simpy by clicking the link.

Unfortunately it seems to me that prosody's authentication works in an
all or nothing fashion. Is anyone aware of a prosody module and/or jitmeet
hack that would allow me to force authentication only for room creators?

Cheers,

Peter

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#6

That's surely the problem.

This is how I have my config hosts setup

domain: 'meet.domain.com',
        //anonymousdomain: 'guest.example.com',
        muc: 'conference.meet.domain.com', // FIXME: use XEP-0030
        bridge: 'jitsi-videobridge.meet.domain.com', // FIXME: use XEP-0030
        call_control: 'callcontrol.meet.domain.com'

I guess I need to uncomment //anonymousdomain. but won't that then mess up
jitmeet (ie won't it try to create rooms in meet.domain.com by default)?

···

On Sat, Nov 15, 2014 at 5:25 PM, Emil Ivov <emcho@jitsi.org> wrote:

You have to make sure that your anonymous domain is different than your
local domain. Is that the case?

--sent from my mobile
On 15 Nov 2014 6:12 PM, "Peter Villeneuve" <petervnv1@gmail.com> wrote:

Answering my own question, that didn't seem to do the trick.
I set restrict_room_creation = local according to the mod_muc link
above, but I'm still able to create rooms anonymously.
Strangely I don't see any errors in the prosody logs.

I have my domain set to anonymous authentication in prosody's config.
If I change it to authentication = "internal_hashed", I do get prompted
for my creds, but so do people just clicking the invite link.

Anyone have a working config they could share?

Cheers

On Sat, Nov 15, 2014 at 3:29 PM, Peter Villeneuve <petervnv1@gmail.com> >> wrote:

Ah. I see. That's great.

I presume I have to set restrict_room_creation to local as seen here
http://prosody.im/doc/modules/mod_muc ?
Is that all I need to do?

Cheers

On Sat, Nov 15, 2014 at 3:22 PM, Emil Ivov <emcho@jitsi.org> wrote:

This is already possible. You have to allow muc creation for local
domain users only (anonymous are on a different domain). Jitsi Meet will
ask you to authenticate when a muc does not exist and that is the case.
Hence only room creators would need to do it.

--sent from my mobile
On 15 Nov 2014 4:18 PM, "Peter Villeneuve" <petervnv1@gmail.com> wrote:

Hi,

I've discussed this before on list about 1 year ago and I'm sure
others are also interested in this topic.

Here's what I've done so far to lock down access to my jitmeet
installation.
I have enabled authentication = "internal_plain" in my prosody's
virtual host config, and indeed now anyone who wants to use my jitmeet
server needs to enter their xmpp creds.

This works well enough but I was thinking about how I could configure
prosody and jitmeet for the following scenario:

- I would like to force only the creators of a room to have to
authenticate, not the participants. The participants wouldn't be able to
create rooms on their own but would still be able to join an already
existing room simpy by clicking the link.

Unfortunately it seems to me that prosody's authentication works in an
all or nothing fashion. Is anyone aware of a prosody module and/or jitmeet
hack that would allow me to force authentication only for room creators?

Cheers,

Peter

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

OK I've uncommented anonymousdomain: 'guest.example.com'
I've setup in prosody config the virtual hosts guest.example.com with
authentication=anonymous and meet.domain.com with
authentication=internal-hashed.

I get prompted for my creds when trying to create a room in meet.domain.com
as expected. But, as I feared, the room gets created under meet.domain.com,
so sending out the link obviously leads to participants also getting
prompted for credentials.

What else do I need to do? Is there any doc anywhere explaining the fairly
new anonymousdomain option in jitsimeet? Any working example one could
follow? The example config docs in github are very basic and old.

Thanks

···

On Sat, Nov 15, 2014 at 5:42 PM, Peter Villeneuve <petervnv1@gmail.com> wrote:

That's surely the problem.

This is how I have my config hosts setup

domain: 'meet.domain.com',
        //anonymousdomain: 'guest.example.com',
        muc: 'conference.meet.domain.com', // FIXME: use XEP-0030
        bridge: 'jitsi-videobridge.meet.domain.com', // FIXME: use
XEP-0030
        call_control: 'callcontrol.meet.domain.com'

I guess I need to uncomment //anonymousdomain. but won't that then mess up
jitmeet (ie won't it try to create rooms in meet.domain.com by default)?

On Sat, Nov 15, 2014 at 5:25 PM, Emil Ivov <emcho@jitsi.org> wrote:

You have to make sure that your anonymous domain is different than your
local domain. Is that the case?

--sent from my mobile
On 15 Nov 2014 6:12 PM, "Peter Villeneuve" <petervnv1@gmail.com> wrote:

Answering my own question, that didn't seem to do the trick.
I set restrict_room_creation = local according to the mod_muc link
above, but I'm still able to create rooms anonymously.
Strangely I don't see any errors in the prosody logs.

I have my domain set to anonymous authentication in prosody's config.
If I change it to authentication = "internal_hashed", I do get prompted
for my creds, but so do people just clicking the invite link.

Anyone have a working config they could share?

Cheers

On Sat, Nov 15, 2014 at 3:29 PM, Peter Villeneuve <petervnv1@gmail.com> >>> wrote:

Ah. I see. That's great.

I presume I have to set restrict_room_creation to local as seen here
http://prosody.im/doc/modules/mod_muc ?
Is that all I need to do?

Cheers

On Sat, Nov 15, 2014 at 3:22 PM, Emil Ivov <emcho@jitsi.org> wrote:

This is already possible. You have to allow muc creation for local
domain users only (anonymous are on a different domain). Jitsi Meet will
ask you to authenticate when a muc does not exist and that is the case.
Hence only room creators would need to do it.

--sent from my mobile
On 15 Nov 2014 4:18 PM, "Peter Villeneuve" <petervnv1@gmail.com> >>>>> wrote:

Hi,

I've discussed this before on list about 1 year ago and I'm sure
others are also interested in this topic.

Here's what I've done so far to lock down access to my jitmeet
installation.
I have enabled authentication = "internal_plain" in my prosody's
virtual host config, and indeed now anyone who wants to use my jitmeet
server needs to enter their xmpp creds.

This works well enough but I was thinking about how I could configure
prosody and jitmeet for the following scenario:

- I would like to force only the creators of a room to have to
authenticate, not the participants. The participants wouldn't be able to
create rooms on their own but would still be able to join an already
existing room simpy by clicking the link.

Unfortunately it seems to me that prosody's authentication works in
an all or nothing fashion. Is anyone aware of a prosody module and/or
jitmeet hack that would allow me to force authentication only for room
creators?

Cheers,

Peter

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#8

Hi,

this is how it is supposed to work. You have meet.domain.com which
needs authentication and it is configured as domain: 'meet.domain.com'
in config.js.
You also have 'guest.example.com', which is configured as anonymous
login and is configured in config.js as anonymousdomain:
'guest.example.com'.
You must have prosody 0.8+ and you must have enabled
restrict_room_creation = local for your muc service
conference.meet.domain.com (from config.js muc:
'conference.meet.domain.com'), the domain here is the one that needs
authentication.
When one enters the room for the first time, he will be asked for
credentials as he is trying to create a room, then he sends the link
to other participants and as the room is already created they will use
the anonymous one guest.example.com to login and enter the room.

Is this all setup as described? Please also make sure you have done
hard refresh on the hosts you test, if you already has done some tests
there. Sometimes config.js is cached and an old config is used.

Regards
damencho

···

On Sat, Nov 15, 2014 at 9:09 PM, Peter Villeneuve <petervnv1@gmail.com> wrote:

OK I've uncommented anonymousdomain: 'guest.example.com'
I've setup in prosody config the virtual hosts guest.example.com with
authentication=anonymous and meet.domain.com with
authentication=internal-hashed.

I get prompted for my creds when trying to create a room in meet.domain.com
as expected. But, as I feared, the room gets created under meet.domain.com,
so sending out the link obviously leads to participants also getting
prompted for credentials.

What else do I need to do? Is there any doc anywhere explaining the fairly
new anonymousdomain option in jitsimeet? Any working example one could
follow? The example config docs in github are very basic and old.

Thanks

On Sat, Nov 15, 2014 at 5:42 PM, Peter Villeneuve <petervnv1@gmail.com> > wrote:

That's surely the problem.

This is how I have my config hosts setup

domain: 'meet.domain.com',
        //anonymousdomain: 'guest.example.com',
        muc: 'conference.meet.domain.com', // FIXME: use XEP-0030
        bridge: 'jitsi-videobridge.meet.domain.com', // FIXME: use
XEP-0030
        call_control: 'callcontrol.meet.domain.com'

I guess I need to uncomment //anonymousdomain. but won't that then mess up
jitmeet (ie won't it try to create rooms in meet.domain.com by default)?

On Sat, Nov 15, 2014 at 5:25 PM, Emil Ivov <emcho@jitsi.org> wrote:

You have to make sure that your anonymous domain is different than your
local domain. Is that the case?

--sent from my mobile

On 15 Nov 2014 6:12 PM, "Peter Villeneuve" <petervnv1@gmail.com> wrote:

Answering my own question, that didn't seem to do the trick.
I set restrict_room_creation = local according to the mod_muc link
above, but I'm still able to create rooms anonymously.
Strangely I don't see any errors in the prosody logs.

I have my domain set to anonymous authentication in prosody's config.
If I change it to authentication = "internal_hashed", I do get prompted
for my creds, but so do people just clicking the invite link.

Anyone have a working config they could share?

Cheers

On Sat, Nov 15, 2014 at 3:29 PM, Peter Villeneuve <petervnv1@gmail.com> >>>> wrote:

Ah. I see. That's great.

I presume I have to set restrict_room_creation to local as seen here
http://prosody.im/doc/modules/mod_muc ?
Is that all I need to do?

Cheers

On Sat, Nov 15, 2014 at 3:22 PM, Emil Ivov <emcho@jitsi.org> wrote:

This is already possible. You have to allow muc creation for local
domain users only (anonymous are on a different domain). Jitsi Meet will ask
you to authenticate when a muc does not exist and that is the case. Hence
only room creators would need to do it.

--sent from my mobile

On 15 Nov 2014 4:18 PM, "Peter Villeneuve" <petervnv1@gmail.com> >>>>>> wrote:

Hi,

I've discussed this before on list about 1 year ago and I'm sure
others are also interested in this topic.

Here's what I've done so far to lock down access to my jitmeet
installation.
I have enabled authentication = "internal_plain" in my prosody's
virtual host config, and indeed now anyone who wants to use my jitmeet
server needs to enter their xmpp creds.

This works well enough but I was thinking about how I could configure
prosody and jitmeet for the following scenario:

- I would like to force only the creators of a room to have to
authenticate, not the participants. The participants wouldn't be able to
create rooms on their own but would still be able to join an already
existing room simpy by clicking the link.

Unfortunately it seems to me that prosody's authentication works in
an all or nothing fashion. Is anyone aware of a prosody module and/or
jitmeet hack that would allow me to force authentication only for room
creators?

Cheers,

Peter

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#9

Hi Damian,

Indeed that is the setup I have, but it doesn't seem to be working as
expected:

Party A goes to meet.domain.com. Creates a room, prosody's popup asks for
creds, party A enters creds and room is created as expected. He then sends
the link to party B, party B clicks the link (the url is
meet.domain.com/room not guest.domain.com/room as I had hoped) and is also
prompted for creds.

I have tried in prosody config setting meet.domain.com's authentication to
1st authentication = "internal_plain" and after that I also
tried authentication = "anonymous". guest.domain.com always has
authentication = "anonymous"
Strangely it asked for creds regardless if I had authentication =
"internal_plain" or "anonymous", even when only joining the room (Party
B's case). I understand it should prompt for creds when creating the room
(I have restrict_room_creation = local) even if meet.domain.com is set to
anonymous, but I don't understand why it also prompts party B that is only
joining an already existing room.

Not sure what's going on. Should I change in config.js '
conference.meet.domain.com' to 'conference.guest.domain.com' ?

Cheers,
Peter

···

On Sun, Nov 16, 2014 at 7:17 AM, Damian Minkov <damencho@jitsi.org> wrote:

Hi,

this is how it is supposed to work. You have meet.domain.com which
needs authentication and it is configured as domain: 'meet.domain.com'
in config.js.
You also have 'guest.example.com', which is configured as anonymous
login and is configured in config.js as anonymousdomain:
'guest.example.com'.
You must have prosody 0.8+ and you must have enabled
restrict_room_creation = local for your muc service
conference.meet.domain.com (from config.js muc:
'conference.meet.domain.com'), the domain here is the one that needs
authentication.
When one enters the room for the first time, he will be asked for
credentials as he is trying to create a room, then he sends the link
to other participants and as the room is already created they will use
the anonymous one guest.example.com to login and enter the room.

Is this all setup as described? Please also make sure you have done
hard refresh on the hosts you test, if you already has done some tests
there. Sometimes config.js is cached and an old config is used.

Regards
damencho

On Sat, Nov 15, 2014 at 9:09 PM, Peter Villeneuve <petervnv1@gmail.com> > wrote:
> OK I've uncommented anonymousdomain: 'guest.example.com'
> I've setup in prosody config the virtual hosts guest.example.com with
> authentication=anonymous and meet.domain.com with
> authentication=internal-hashed.
>
> I get prompted for my creds when trying to create a room in
meet.domain.com
> as expected. But, as I feared, the room gets created under
meet.domain.com,
> so sending out the link obviously leads to participants also getting
> prompted for credentials.
>
> What else do I need to do? Is there any doc anywhere explaining the
fairly
> new anonymousdomain option in jitsimeet? Any working example one could
> follow? The example config docs in github are very basic and old.
>
> Thanks
>
>
>
> On Sat, Nov 15, 2014 at 5:42 PM, Peter Villeneuve <petervnv1@gmail.com> > > wrote:
>>
>> That's surely the problem.
>>
>> This is how I have my config hosts setup
>>
>> domain: 'meet.domain.com',
>> //anonymousdomain: 'guest.example.com',
>> muc: 'conference.meet.domain.com', // FIXME: use XEP-0030
>> bridge: 'jitsi-videobridge.meet.domain.com', // FIXME: use
>> XEP-0030
>> call_control: 'callcontrol.meet.domain.com'
>>
>>
>> I guess I need to uncomment //anonymousdomain. but won't that then mess
up
>> jitmeet (ie won't it try to create rooms in meet.domain.com by
default)?
>>
>> On Sat, Nov 15, 2014 at 5:25 PM, Emil Ivov <emcho@jitsi.org> wrote:
>>>
>>> You have to make sure that your anonymous domain is different than
your
>>> local domain. Is that the case?
>>>
>>> --sent from my mobile
>>>
>>> On 15 Nov 2014 6:12 PM, "Peter Villeneuve" <petervnv1@gmail.com> > wrote:
>>>>
>>>> Answering my own question, that didn't seem to do the trick.
>>>> I set restrict_room_creation = local according to the mod_muc link
>>>> above, but I'm still able to create rooms anonymously.
>>>> Strangely I don't see any errors in the prosody logs.
>>>>
>>>> I have my domain set to anonymous authentication in prosody's config.
>>>> If I change it to authentication = "internal_hashed", I do get
prompted
>>>> for my creds, but so do people just clicking the invite link.
>>>>
>>>> Anyone have a working config they could share?
>>>>
>>>> Cheers
>>>>
>>>> On Sat, Nov 15, 2014 at 3:29 PM, Peter Villeneuve < > petervnv1@gmail.com> > >>>> wrote:
>>>>>
>>>>> Ah. I see. That's great.
>>>>>
>>>>> I presume I have to set restrict_room_creation to local as seen here
>>>>> http://prosody.im/doc/modules/mod_muc ?
>>>>> Is that all I need to do?
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Nov 15, 2014 at 3:22 PM, Emil Ivov <emcho@jitsi.org> wrote:
>>>>>>
>>>>>> This is already possible. You have to allow muc creation for local
>>>>>> domain users only (anonymous are on a different domain). Jitsi Meet
will ask
>>>>>> you to authenticate when a muc does not exist and that is the case.
Hence
>>>>>> only room creators would need to do it.
>>>>>>
>>>>>> --sent from my mobile
>>>>>>
>>>>>> On 15 Nov 2014 4:18 PM, "Peter Villeneuve" <petervnv1@gmail.com> > >>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I've discussed this before on list about 1 year ago and I'm sure
>>>>>>> others are also interested in this topic.
>>>>>>>
>>>>>>> Here's what I've done so far to lock down access to my jitmeet
>>>>>>> installation.
>>>>>>> I have enabled authentication = "internal_plain" in my prosody's
>>>>>>> virtual host config, and indeed now anyone who wants to use my
jitmeet
>>>>>>> server needs to enter their xmpp creds.
>>>>>>>
>>>>>>> This works well enough but I was thinking about how I could
configure
>>>>>>> prosody and jitmeet for the following scenario:
>>>>>>>
>>>>>>> - I would like to force only the creators of a room to have to
>>>>>>> authenticate, not the participants. The participants wouldn't be
able to
>>>>>>> create rooms on their own but would still be able to join an
already
>>>>>>> existing room simpy by clicking the link.
>>>>>>>
>>>>>>> Unfortunately it seems to me that prosody's authentication works in
>>>>>>> an all or nothing fashion. Is anyone aware of a prosody module
and/or
>>>>>>> jitmeet hack that would allow me to force authentication only for
room
>>>>>>> creators?
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Peter
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> dev mailing list
>>>>>>> dev@jitsi.org
>>>>>>> Unsubscribe instructions and other list options:
>>>>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> dev mailing list
>>>>>> dev@jitsi.org
>>>>>> Unsubscribe instructions and other list options:
>>>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> dev mailing list
>>>> dev@jitsi.org
>>>> Unsubscribe instructions and other list options:
>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev@jitsi.org
>>> Unsubscribe instructions and other list options:
>>> http://lists.jitsi.org/mailman/listinfo/dev
>>
>>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#10

I tried changing config.js 'conference.meet.domain.com' to '
conference.guest.domain.com' and now I never get prompted for creds at all,
even when creating the room, so that's not the answer either.

I guess the big mystery is why does an invited party get prompted for
creds? Supposedly by setting the anonymousdomain in config.js and setting
that domain to anonymous authentication in prosody's config, one would
expect not to have to enter creds to join an already existing room, but it
isn't working like that at all for me.

I'm still getting all or nothing authentication regardless if the
anonymousdomain is set.

Any clues?

Cheers

···

On Sun, Nov 16, 2014 at 2:05 PM, Peter Villeneuve <petervnv1@gmail.com> wrote:

Hi Damian,

Indeed that is the setup I have, but it doesn't seem to be working as
expected:

Party A goes to meet.domain.com. Creates a room, prosody's popup asks for
creds, party A enters creds and room is created as expected. He then sends
the link to party B, party B clicks the link (the url is
meet.domain.com/room not guest.domain.com/room as I had hoped) and is
also prompted for creds.

I have tried in prosody config setting meet.domain.com's authentication
to 1st authentication = "internal_plain" and after that I also
tried authentication = "anonymous". guest.domain.com always has
authentication = "anonymous"
Strangely it asked for creds regardless if I had authentication =
"internal_plain" or "anonymous", even when only joining the room (Party
B's case). I understand it should prompt for creds when creating the room
(I have restrict_room_creation = local) even if meet.domain.com is set to
anonymous, but I don't understand why it also prompts party B that is only
joining an already existing room.

Not sure what's going on. Should I change in config.js '
conference.meet.domain.com' to 'conference.guest.domain.com' ?

Cheers,
Peter

On Sun, Nov 16, 2014 at 7:17 AM, Damian Minkov <damencho@jitsi.org> wrote:

Hi,

this is how it is supposed to work. You have meet.domain.com which
needs authentication and it is configured as domain: 'meet.domain.com'
in config.js.
You also have 'guest.example.com', which is configured as anonymous
login and is configured in config.js as anonymousdomain:
'guest.example.com'.
You must have prosody 0.8+ and you must have enabled
restrict_room_creation = local for your muc service
conference.meet.domain.com (from config.js muc:
'conference.meet.domain.com'), the domain here is the one that needs
authentication.
When one enters the room for the first time, he will be asked for
credentials as he is trying to create a room, then he sends the link
to other participants and as the room is already created they will use
the anonymous one guest.example.com to login and enter the room.

Is this all setup as described? Please also make sure you have done
hard refresh on the hosts you test, if you already has done some tests
there. Sometimes config.js is cached and an old config is used.

Regards
damencho

On Sat, Nov 15, 2014 at 9:09 PM, Peter Villeneuve <petervnv1@gmail.com> >> wrote:
> OK I've uncommented anonymousdomain: 'guest.example.com'
> I've setup in prosody config the virtual hosts guest.example.com with
> authentication=anonymous and meet.domain.com with
> authentication=internal-hashed.
>
> I get prompted for my creds when trying to create a room in
meet.domain.com
> as expected. But, as I feared, the room gets created under
meet.domain.com,
> so sending out the link obviously leads to participants also getting
> prompted for credentials.
>
> What else do I need to do? Is there any doc anywhere explaining the
fairly
> new anonymousdomain option in jitsimeet? Any working example one could
> follow? The example config docs in github are very basic and old.
>
> Thanks
>
>
>
> On Sat, Nov 15, 2014 at 5:42 PM, Peter Villeneuve <petervnv1@gmail.com> >> > wrote:
>>
>> That's surely the problem.
>>
>> This is how I have my config hosts setup
>>
>> domain: 'meet.domain.com',
>> //anonymousdomain: 'guest.example.com',
>> muc: 'conference.meet.domain.com', // FIXME: use XEP-0030
>> bridge: 'jitsi-videobridge.meet.domain.com', // FIXME: use
>> XEP-0030
>> call_control: 'callcontrol.meet.domain.com'
>>
>>
>> I guess I need to uncomment //anonymousdomain. but won't that then
mess up
>> jitmeet (ie won't it try to create rooms in meet.domain.com by
default)?
>>
>> On Sat, Nov 15, 2014 at 5:25 PM, Emil Ivov <emcho@jitsi.org> wrote:
>>>
>>> You have to make sure that your anonymous domain is different than
your
>>> local domain. Is that the case?
>>>
>>> --sent from my mobile
>>>
>>> On 15 Nov 2014 6:12 PM, "Peter Villeneuve" <petervnv1@gmail.com> >> wrote:
>>>>
>>>> Answering my own question, that didn't seem to do the trick.
>>>> I set restrict_room_creation = local according to the mod_muc link
>>>> above, but I'm still able to create rooms anonymously.
>>>> Strangely I don't see any errors in the prosody logs.
>>>>
>>>> I have my domain set to anonymous authentication in prosody's config.
>>>> If I change it to authentication = "internal_hashed", I do get
prompted
>>>> for my creds, but so do people just clicking the invite link.
>>>>
>>>> Anyone have a working config they could share?
>>>>
>>>> Cheers
>>>>
>>>> On Sat, Nov 15, 2014 at 3:29 PM, Peter Villeneuve < >> petervnv1@gmail.com> >> >>>> wrote:
>>>>>
>>>>> Ah. I see. That's great.
>>>>>
>>>>> I presume I have to set restrict_room_creation to local as seen here
>>>>> http://prosody.im/doc/modules/mod_muc ?
>>>>> Is that all I need to do?
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Nov 15, 2014 at 3:22 PM, Emil Ivov <emcho@jitsi.org> wrote:
>>>>>>
>>>>>> This is already possible. You have to allow muc creation for local
>>>>>> domain users only (anonymous are on a different domain). Jitsi
Meet will ask
>>>>>> you to authenticate when a muc does not exist and that is the
case. Hence
>>>>>> only room creators would need to do it.
>>>>>>
>>>>>> --sent from my mobile
>>>>>>
>>>>>> On 15 Nov 2014 4:18 PM, "Peter Villeneuve" <petervnv1@gmail.com> >> >>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I've discussed this before on list about 1 year ago and I'm sure
>>>>>>> others are also interested in this topic.
>>>>>>>
>>>>>>> Here's what I've done so far to lock down access to my jitmeet
>>>>>>> installation.
>>>>>>> I have enabled authentication = "internal_plain" in my prosody's
>>>>>>> virtual host config, and indeed now anyone who wants to use my
jitmeet
>>>>>>> server needs to enter their xmpp creds.
>>>>>>>
>>>>>>> This works well enough but I was thinking about how I could
configure
>>>>>>> prosody and jitmeet for the following scenario:
>>>>>>>
>>>>>>> - I would like to force only the creators of a room to have to
>>>>>>> authenticate, not the participants. The participants wouldn't be
able to
>>>>>>> create rooms on their own but would still be able to join an
already
>>>>>>> existing room simpy by clicking the link.
>>>>>>>
>>>>>>> Unfortunately it seems to me that prosody's authentication works
in
>>>>>>> an all or nothing fashion. Is anyone aware of a prosody module
and/or
>>>>>>> jitmeet hack that would allow me to force authentication only for
room
>>>>>>> creators?
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Peter
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> dev mailing list
>>>>>>> dev@jitsi.org
>>>>>>> Unsubscribe instructions and other list options:
>>>>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> dev mailing list
>>>>>> dev@jitsi.org
>>>>>> Unsubscribe instructions and other list options:
>>>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> dev mailing list
>>>> dev@jitsi.org
>>>> Unsubscribe instructions and other list options:
>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev@jitsi.org
>>> Unsubscribe instructions and other list options:
>>> http://lists.jitsi.org/mailman/listinfo/dev
>>
>>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#11

Hi,

I've just tested it and everything is working fine. Here is what I did
to enable it:
- apt-get install jitsi-meet
- open the file for my host in /etc/prosody/conf.avail. Set the
authentication for the host to authentication = "internal_plain". Then
copy the virtual host declaration and add to the name guest. and
change the authentication to anonymous. Add restrict_room_creation
= "local" after component muc declaration.
- restart prosody
- Add account prosodyctl adduser me@my.domain
- open jitsi-meet config.js and uncomment anonymousdomain: and set the
domain to guest....my.domain
- Open the url and was asked for credentials, enter them
- open the url on second tab no credentials asked and connect was successful

Regards
damencho

···

-

On Sun, Nov 16, 2014 at 7:21 PM, Peter Villeneuve <petervnv1@gmail.com> wrote:

I tried changing config.js 'conference.meet.domain.com' to
'conference.guest.domain.com' and now I never get prompted for creds at all,
even when creating the room, so that's not the answer either.

I guess the big mystery is why does an invited party get prompted for creds?
Supposedly by setting the anonymousdomain in config.js and setting that
domain to anonymous authentication in prosody's config, one would expect not
to have to enter creds to join an already existing room, but it isn't
working like that at all for me.

I'm still getting all or nothing authentication regardless if the
anonymousdomain is set.

Any clues?

Cheers

On Sun, Nov 16, 2014 at 2:05 PM, Peter Villeneuve <petervnv1@gmail.com> > wrote:

Hi Damian,

Indeed that is the setup I have, but it doesn't seem to be working as
expected:

Party A goes to meet.domain.com. Creates a room, prosody's popup asks for
creds, party A enters creds and room is created as expected. He then sends
the link to party B, party B clicks the link (the url is
meet.domain.com/room not guest.domain.com/room as I had hoped) and is also
prompted for creds.

I have tried in prosody config setting meet.domain.com's authentication to
1st authentication = "internal_plain" and after that I also tried
authentication = "anonymous". guest.domain.com always has authentication =
"anonymous"
Strangely it asked for creds regardless if I had authentication =
"internal_plain" or "anonymous", even when only joining the room (Party B's
case). I understand it should prompt for creds when creating the room (I
have restrict_room_creation = local) even if meet.domain.com is set to
anonymous, but I don't understand why it also prompts party B that is only
joining an already existing room.

Not sure what's going on. Should I change in config.js
'conference.meet.domain.com' to 'conference.guest.domain.com' ?

Cheers,
Peter

On Sun, Nov 16, 2014 at 7:17 AM, Damian Minkov <damencho@jitsi.org> wrote:

Hi,

this is how it is supposed to work. You have meet.domain.com which
needs authentication and it is configured as domain: 'meet.domain.com'
in config.js.
You also have 'guest.example.com', which is configured as anonymous
login and is configured in config.js as anonymousdomain:
'guest.example.com'.
You must have prosody 0.8+ and you must have enabled
restrict_room_creation = local for your muc service
conference.meet.domain.com (from config.js muc:
'conference.meet.domain.com'), the domain here is the one that needs
authentication.
When one enters the room for the first time, he will be asked for
credentials as he is trying to create a room, then he sends the link
to other participants and as the room is already created they will use
the anonymous one guest.example.com to login and enter the room.

Is this all setup as described? Please also make sure you have done
hard refresh on the hosts you test, if you already has done some tests
there. Sometimes config.js is cached and an old config is used.

Regards
damencho

On Sat, Nov 15, 2014 at 9:09 PM, Peter Villeneuve <petervnv1@gmail.com> >>> wrote:
> OK I've uncommented anonymousdomain: 'guest.example.com'
> I've setup in prosody config the virtual hosts guest.example.com with
> authentication=anonymous and meet.domain.com with
> authentication=internal-hashed.
>
> I get prompted for my creds when trying to create a room in
> meet.domain.com
> as expected. But, as I feared, the room gets created under
> meet.domain.com,
> so sending out the link obviously leads to participants also getting
> prompted for credentials.
>
> What else do I need to do? Is there any doc anywhere explaining the
> fairly
> new anonymousdomain option in jitsimeet? Any working example one could
> follow? The example config docs in github are very basic and old.
>
> Thanks
>
>
>
> On Sat, Nov 15, 2014 at 5:42 PM, Peter Villeneuve <petervnv1@gmail.com> >>> > wrote:
>>
>> That's surely the problem.
>>
>> This is how I have my config hosts setup
>>
>> domain: 'meet.domain.com',
>> //anonymousdomain: 'guest.example.com',
>> muc: 'conference.meet.domain.com', // FIXME: use XEP-0030
>> bridge: 'jitsi-videobridge.meet.domain.com', // FIXME: use
>> XEP-0030
>> call_control: 'callcontrol.meet.domain.com'
>>
>>
>> I guess I need to uncomment //anonymousdomain. but won't that then
>> mess up
>> jitmeet (ie won't it try to create rooms in meet.domain.com by
>> default)?
>>
>> On Sat, Nov 15, 2014 at 5:25 PM, Emil Ivov <emcho@jitsi.org> wrote:
>>>
>>> You have to make sure that your anonymous domain is different than
>>> your
>>> local domain. Is that the case?
>>>
>>> --sent from my mobile
>>>
>>> On 15 Nov 2014 6:12 PM, "Peter Villeneuve" <petervnv1@gmail.com> >>> >>> wrote:
>>>>
>>>> Answering my own question, that didn't seem to do the trick.
>>>> I set restrict_room_creation = local according to the mod_muc link
>>>> above, but I'm still able to create rooms anonymously.
>>>> Strangely I don't see any errors in the prosody logs.
>>>>
>>>> I have my domain set to anonymous authentication in prosody's
>>>> config.
>>>> If I change it to authentication = "internal_hashed", I do get
>>>> prompted
>>>> for my creds, but so do people just clicking the invite link.
>>>>
>>>> Anyone have a working config they could share?
>>>>
>>>> Cheers
>>>>
>>>> On Sat, Nov 15, 2014 at 3:29 PM, Peter Villeneuve >>> >>>> <petervnv1@gmail.com> >>> >>>> wrote:
>>>>>
>>>>> Ah. I see. That's great.
>>>>>
>>>>> I presume I have to set restrict_room_creation to local as seen
>>>>> here
>>>>> http://prosody.im/doc/modules/mod_muc ?
>>>>> Is that all I need to do?
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Nov 15, 2014 at 3:22 PM, Emil Ivov <emcho@jitsi.org> wrote:
>>>>>>
>>>>>> This is already possible. You have to allow muc creation for local
>>>>>> domain users only (anonymous are on a different domain). Jitsi
>>>>>> Meet will ask
>>>>>> you to authenticate when a muc does not exist and that is the
>>>>>> case. Hence
>>>>>> only room creators would need to do it.
>>>>>>
>>>>>> --sent from my mobile
>>>>>>
>>>>>> On 15 Nov 2014 4:18 PM, "Peter Villeneuve" <petervnv1@gmail.com> >>> >>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I've discussed this before on list about 1 year ago and I'm sure
>>>>>>> others are also interested in this topic.
>>>>>>>
>>>>>>> Here's what I've done so far to lock down access to my jitmeet
>>>>>>> installation.
>>>>>>> I have enabled authentication = "internal_plain" in my prosody's
>>>>>>> virtual host config, and indeed now anyone who wants to use my
>>>>>>> jitmeet
>>>>>>> server needs to enter their xmpp creds.
>>>>>>>
>>>>>>> This works well enough but I was thinking about how I could
>>>>>>> configure
>>>>>>> prosody and jitmeet for the following scenario:
>>>>>>>
>>>>>>> - I would like to force only the creators of a room to have to
>>>>>>> authenticate, not the participants. The participants wouldn't be
>>>>>>> able to
>>>>>>> create rooms on their own but would still be able to join an
>>>>>>> already
>>>>>>> existing room simpy by clicking the link.
>>>>>>>
>>>>>>> Unfortunately it seems to me that prosody's authentication works
>>>>>>> in
>>>>>>> an all or nothing fashion. Is anyone aware of a prosody module
>>>>>>> and/or
>>>>>>> jitmeet hack that would allow me to force authentication only for
>>>>>>> room
>>>>>>> creators?
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Peter
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> dev mailing list
>>>>>>> dev@jitsi.org
>>>>>>> Unsubscribe instructions and other list options:
>>>>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> dev mailing list
>>>>>> dev@jitsi.org
>>>>>> Unsubscribe instructions and other list options:
>>>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> dev mailing list
>>>> dev@jitsi.org
>>>> Unsubscribe instructions and other list options:
>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev@jitsi.org
>>> Unsubscribe instructions and other list options:
>>> http://lists.jitsi.org/mailman/listinfo/dev
>>
>>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#12

Maybe the issue or maybe not, but previously in this thread nobody has
had quotes around "local" in Prosody's config. They're important...

   restrict_room_creation = "local"

Also make sure it's placed under the MUC component in the config, and
not inadvertently under another host/component.

Regards,
Matthew

···

On 17 November 2014 08:30, Damian Minkov <damencho@jitsi.org> wrote:

Hi,

I've just tested it and everything is working fine. Here is what I did
to enable it:
- apt-get install jitsi-meet
- open the file for my host in /etc/prosody/conf.avail. Set the
authentication for the host to authentication = "internal_plain". Then
copy the virtual host declaration and add to the name guest. and
change the authentication to anonymous. Add restrict_room_creation
= "local" after component muc declaration.
- restart prosody
- Add account prosodyctl adduser me@my.domain
- open jitsi-meet config.js and uncomment anonymousdomain: and set the
domain to guest....my.domain
- Open the url and was asked for credentials, enter them
- open the url on second tab no credentials asked and connect was successful


#13

Thanks for trying to help out guys.
The issue isn't the " around restrict_room_creation = "local".

I have done everything as damencho described, the only difference being
that I installed from git and not apt-get.

Everything works as expected until the last step

- open the url on second tab no credentials asked and connect was

successful
Unfortunately on that last step I still get prompted for creds. I'm not
sure why it isn't working for me as it should. Has there been any recent
change in the code on git that isn't in the debian package yet and could be
causing this issue?

I restart prosody and even nginx to make sure the config changes take
effect. I have cleared all the history in the Chrome clients used to test
to make sure they weren't holding anything in cache, yet the creds popup
continues when entering an already created room. It's almost as if the
authentication
= "anonymous" in guest.my.domain never gets applied.

Any clue to explain this behavior?

Cheers,
Peter

Here's a snippet from my prosody config (and yes anonymousdomain has been
uncommented and changed to guest.my.domain)

----------- Virtual hosts -----------
-- You need to add a VirtualHost entry for each domain you wish Prosody to
serve.
-- Settings under each VirtualHost entry apply *only* to that host.

--VirtualHost "localhost"

VirtualHost "guest.my.domain"
--enabled = false -- Remove this line to enable this host
authentication = "anonymous"
ssl = {
key = "/etc/prosody/certs/meet.my.domain.key";
certificate = "/etc/prosody/certs/meet.my.domain.crt";
}

-- we need bosh
        modules_enabled = {
            "bosh";
            "pubsub";
    "turncredentials";
        }

VirtualHost "my.domain"
--enabled = false -- Remove this line to enable this host
authentication = "internal_plain"
ssl = {
key = "/etc/prosody/certs/meet.my.domain.key";
certificate = "/etc/prosody/certs/meet.my.domain.crt";
}

VirtualHost "meet.my.domain"
        -- enabled = false -- Remove this line to enable this host

authentication = "internal_plain"

        ssl = {
                key = "/etc/prosody/certs/meet.my.domain.key";
                certificate = "/etc/prosody/certs/meet.my.domain.crt";
        }

        -- we need bosh
        modules_enabled = {
            "bosh";
            "pubsub";
    "turncredentials";
        }

Component "conference.meet.my.domain" "muc"
restrict_room_creation = "local"

Component "jitsi-videobridge.meet.my.domain"
    component_secret = "xxxxx"

Component "callcontrol.meet.my.domain" component_secret = "yyyyyyy"

And from jitmeet's config.js

var config = {
    hosts: {
        domain: 'meet.my.domain',
        anonymousdomain: 'guest.my.domain',
        muc: 'conference.meet.my.domain', // FIXME: use XEP-0030
        bridge: 'jitsi-videobridge.meet.my.domain', // FIXME: use XEP-0030
        call_control: 'callcontrol.meet.my.domain'
},

···

On Mon, Nov 17, 2014 at 4:36 PM, Matthew Wild <mwild1@gmail.com> wrote:

On 17 November 2014 08:30, Damian Minkov <damencho@jitsi.org> wrote:
> Hi,
>
> I've just tested it and everything is working fine. Here is what I did
> to enable it:
> - apt-get install jitsi-meet
> - open the file for my host in /etc/prosody/conf.avail. Set the
> authentication for the host to authentication = "internal_plain". Then
> copy the virtual host declaration and add to the name guest. and
> change the authentication to anonymous. Add restrict_room_creation
> = "local" after component muc declaration.
> - restart prosody
> - Add account prosodyctl adduser me@my.domain
> - open jitsi-meet config.js and uncomment anonymousdomain: and set the
> domain to guest....my.domain
> - Open the url and was asked for credentials, enter them
> - open the url on second tab no credentials asked and connect was
successful

Maybe the issue or maybe not, but previously in this thread nobody has
had quotes around "local" in Prosody's config. They're important...

   restrict_room_creation = "local"

Also make sure it's placed under the MUC component in the config, and
not inadvertently under another host/component.

Regards,
Matthew

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#14

I've done a reboot of the server just to make sure it wasn't caching the
config anywhere.
Unfortunately I stil get prompted for creds as described above, so that's
not the problem either.

Damian, could you post your config.js from jitmeet and your prosody.config
somewhere so I can look at it?

Cheers,
Peter

···

On Tue, Nov 18, 2014 at 5:32 PM, Peter Villeneuve <petervnv1@gmail.com> wrote:

Thanks for trying to help out guys.
The issue isn't the " around restrict_room_creation = "local".

I have done everything as damencho described, the only difference being
that I installed from git and not apt-get.

Everything works as expected until the last step
> - open the url on second tab no credentials asked and connect was
successful
Unfortunately on that last step I still get prompted for creds. I'm not
sure why it isn't working for me as it should. Has there been any recent
change in the code on git that isn't in the debian package yet and could be
causing this issue?

I restart prosody and even nginx to make sure the config changes take
effect. I have cleared all the history in the Chrome clients used to test
to make sure they weren't holding anything in cache, yet the creds popup
continues when entering an already created room. It's almost as if the authentication
= "anonymous" in guest.my.domain never gets applied.

Any clue to explain this behavior?

Cheers,
Peter

Here's a snippet from my prosody config (and yes anonymousdomain has been
uncommented and changed to guest.my.domain)

----------- Virtual hosts -----------
-- You need to add a VirtualHost entry for each domain you wish Prosody to
serve.
-- Settings under each VirtualHost entry apply *only* to that host.

--VirtualHost "localhost"

VirtualHost "guest.my.domain"
--enabled = false -- Remove this line to enable this host
authentication = "anonymous"
ssl = {
key = "/etc/prosody/certs/meet.my.domain.key";
certificate = "/etc/prosody/certs/meet.my.domain.crt";
}

-- we need bosh
        modules_enabled = {
            "bosh";
            "pubsub";
    "turncredentials";
        }

VirtualHost "my.domain"
--enabled = false -- Remove this line to enable this host
authentication = "internal_plain"
ssl = {
key = "/etc/prosody/certs/meet.my.domain.key";
certificate = "/etc/prosody/certs/meet.my.domain.crt";
}

VirtualHost "meet.my.domain"
        -- enabled = false -- Remove this line to enable this host

authentication = "internal_plain"

        ssl = {
                key = "/etc/prosody/certs/meet.my.domain.key";
                certificate = "/etc/prosody/certs/meet.my.domain.crt";
        }

        -- we need bosh
        modules_enabled = {
            "bosh";
            "pubsub";
    "turncredentials";
        }

Component "conference.meet.my.domain" "muc"
restrict_room_creation = "local"

Component "jitsi-videobridge.meet.my.domain"
    component_secret = "xxxxx"

Component "callcontrol.meet.my.domain" component_secret = "yyyyyyy"

And from jitmeet's config.js

var config = {
    hosts: {
        domain: 'meet.my.domain',
        anonymousdomain: 'guest.my.domain',
        muc: 'conference.meet.my.domain', // FIXME: use XEP-0030
        bridge: 'jitsi-videobridge.meet.my.domain', // FIXME: use XEP-0030
        call_control: 'callcontrol.meet.my.domain'
},

On Mon, Nov 17, 2014 at 4:36 PM, Matthew Wild <mwild1@gmail.com> wrote:

On 17 November 2014 08:30, Damian Minkov <damencho@jitsi.org> wrote:
> Hi,
>
> I've just tested it and everything is working fine. Here is what I did
> to enable it:
> - apt-get install jitsi-meet
> - open the file for my host in /etc/prosody/conf.avail. Set the
> authentication for the host to authentication = "internal_plain". Then
> copy the virtual host declaration and add to the name guest. and
> change the authentication to anonymous. Add restrict_room_creation
> = "local" after component muc declaration.
> - restart prosody
> - Add account prosodyctl adduser me@my.domain
> - open jitsi-meet config.js and uncomment anonymousdomain: and set the
> domain to guest....my.domain
> - Open the url and was asked for credentials, enter them
> - open the url on second tab no credentials asked and connect was
successful

Maybe the issue or maybe not, but previously in this thread nobody has
had quotes around "local" in Prosody's config. They're important...

   restrict_room_creation = "local"

Also make sure it's placed under the MUC component in the config, and
not inadvertently under another host/component.

Regards,
Matthew

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#15

Hi,

as I described earlier, the configs are the standard one, that are
from the debian package, so there are those that you can find in the
git repo. I just added one more host and setting some configs. Here
are they. The prosody config is just a host configs put in
/etc/prosody/conf.avail and link in /etc/prosody/conf.d.

Regards
damencho

prosody.cfg.lua-jvb.example.txt (1.48 KB)

config.js (1.46 KB)

···

On Wed, Nov 19, 2014 at 7:43 PM, Peter Villeneuve <petervnv1@gmail.com> wrote:

I've done a reboot of the server just to make sure it wasn't caching the
config anywhere.
Unfortunately I stil get prompted for creds as described above, so that's
not the problem either.

Damian, could you post your config.js from jitmeet and your prosody.config
somewhere so I can look at it?

Cheers,
Peter

On Tue, Nov 18, 2014 at 5:32 PM, Peter Villeneuve <petervnv1@gmail.com> > wrote:

Thanks for trying to help out guys.
The issue isn't the " around restrict_room_creation = "local".

I have done everything as damencho described, the only difference being
that I installed from git and not apt-get.

Everything works as expected until the last step
> - open the url on second tab no credentials asked and connect was
> successful
Unfortunately on that last step I still get prompted for creds. I'm not
sure why it isn't working for me as it should. Has there been any recent
change in the code on git that isn't in the debian package yet and could be
causing this issue?

I restart prosody and even nginx to make sure the config changes take
effect. I have cleared all the history in the Chrome clients used to test to
make sure they weren't holding anything in cache, yet the creds popup
continues when entering an already created room. It's almost as if the
authentication = "anonymous" in guest.my.domain never gets applied.

Any clue to explain this behavior?

Cheers,
Peter

Here's a snippet from my prosody config (and yes anonymousdomain has been
uncommented and changed to guest.my.domain)

----------- Virtual hosts -----------
-- You need to add a VirtualHost entry for each domain you wish Prosody to
serve.
-- Settings under each VirtualHost entry apply *only* to that host.

--VirtualHost "localhost"

VirtualHost "guest.my.domain"
--enabled = false -- Remove this line to enable this host
authentication = "anonymous"
ssl = {
key = "/etc/prosody/certs/meet.my.domain.key";
certificate = "/etc/prosody/certs/meet.my.domain.crt";
}

-- we need bosh
        modules_enabled = {
            "bosh";
            "pubsub";
   "turncredentials";
        }

VirtualHost "my.domain"
--enabled = false -- Remove this line to enable this host
authentication = "internal_plain"
ssl = {
key = "/etc/prosody/certs/meet.my.domain.key";
certificate = "/etc/prosody/certs/meet.my.domain.crt";
}

VirtualHost "meet.my.domain"
        -- enabled = false -- Remove this line to enable this host

authentication = "internal_plain"

        ssl = {
                key = "/etc/prosody/certs/meet.my.domain.key";
                certificate = "/etc/prosody/certs/meet.my.domain.crt";
        }

        -- we need bosh
        modules_enabled = {
            "bosh";
            "pubsub";
   "turncredentials";
        }

Component "conference.meet.my.domain" "muc"
restrict_room_creation = "local"

Component "jitsi-videobridge.meet.my.domain"
    component_secret = "xxxxx"

Component "callcontrol.meet.my.domain" component_secret = "yyyyyyy"

And from jitmeet's config.js

var config = {
    hosts: {
        domain: 'meet.my.domain',
        anonymousdomain: 'guest.my.domain',
        muc: 'conference.meet.my.domain', // FIXME: use XEP-0030
        bridge: 'jitsi-videobridge.meet.my.domain', // FIXME: use XEP-0030
        call_control: 'callcontrol.meet.my.domain'
},

On Mon, Nov 17, 2014 at 4:36 PM, Matthew Wild <mwild1@gmail.com> wrote:

On 17 November 2014 08:30, Damian Minkov <damencho@jitsi.org> wrote:
> Hi,
>
> I've just tested it and everything is working fine. Here is what I did
> to enable it:
> - apt-get install jitsi-meet
> - open the file for my host in /etc/prosody/conf.avail. Set the
> authentication for the host to authentication = "internal_plain". Then
> copy the virtual host declaration and add to the name guest. and
> change the authentication to anonymous. Add restrict_room_creation
> = "local" after component muc declaration.
> - restart prosody
> - Add account prosodyctl adduser me@my.domain
> - open jitsi-meet config.js and uncomment anonymousdomain: and set the
> domain to guest....my.domain
> - Open the url and was asked for credentials, enter them
> - open the url on second tab no credentials asked and connect was
> successful

Maybe the issue or maybe not, but previously in this thread nobody has
had quotes around "local" in Prosody's config. They're important...

   restrict_room_creation = "local"

Also make sure it's placed under the MUC component in the config, and
not inadvertently under another host/component.

Regards,
Matthew

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#16

Hi,

Thanks again Damian. I just wanted to make sure I wasn't missing anything
obvious.
The only difference I see in regards to my configs is that I also have a
domain.com virtual host (also with internal_plain) besides the
meet.domain.com (internal_plain) and guest.domain.com (anonymous).
I also have callcontrol enabled but that shouldn't make any difference.

I guess my next step is to purge jitmeet and reinstall the debian packages
again to see if the issue goes away for good.

Cheers

···

On Wed, Nov 19, 2014 at 7:22 PM, Damian Minkov <damencho@jitsi.org> wrote:

Hi,

as I described earlier, the configs are the standard one, that are
from the debian package, so there are those that you can find in the
git repo. I just added one more host and setting some configs. Here
are they. The prosody config is just a host configs put in
/etc/prosody/conf.avail and link in /etc/prosody/conf.d.

Regards
damencho

On Wed, Nov 19, 2014 at 7:43 PM, Peter Villeneuve <petervnv1@gmail.com> > wrote:
> I've done a reboot of the server just to make sure it wasn't caching the
> config anywhere.
> Unfortunately I stil get prompted for creds as described above, so that's
> not the problem either.
>
> Damian, could you post your config.js from jitmeet and your
prosody.config
> somewhere so I can look at it?
>
> Cheers,
> Peter
>
> On Tue, Nov 18, 2014 at 5:32 PM, Peter Villeneuve <petervnv1@gmail.com> > > wrote:
>>
>> Thanks for trying to help out guys.
>> The issue isn't the " around restrict_room_creation = "local".
>>
>> I have done everything as damencho described, the only difference being
>> that I installed from git and not apt-get.
>>
>> Everything works as expected until the last step
>> > - open the url on second tab no credentials asked and connect was
>> > successful
>> Unfortunately on that last step I still get prompted for creds. I'm not
>> sure why it isn't working for me as it should. Has there been any recent
>> change in the code on git that isn't in the debian package yet and
could be
>> causing this issue?
>>
>> I restart prosody and even nginx to make sure the config changes take
>> effect. I have cleared all the history in the Chrome clients used to
test to
>> make sure they weren't holding anything in cache, yet the creds popup
>> continues when entering an already created room. It's almost as if the
>> authentication = "anonymous" in guest.my.domain never gets applied.
>>
>>
>> Any clue to explain this behavior?
>>
>> Cheers,
>> Peter
>>
>>
>> Here's a snippet from my prosody config (and yes anonymousdomain has
been
>> uncommented and changed to guest.my.domain)
>>
>> ----------- Virtual hosts -----------
>> -- You need to add a VirtualHost entry for each domain you wish Prosody
to
>> serve.
>> -- Settings under each VirtualHost entry apply *only* to that host.
>>
>> --VirtualHost "localhost"
>>
>>
>> VirtualHost "guest.my.domain"
>> --enabled = false -- Remove this line to enable this host
>> authentication = "anonymous"
>> ssl = {
>> key = "/etc/prosody/certs/meet.my.domain.key";
>> certificate = "/etc/prosody/certs/meet.my.domain.crt";
>> }
>>
>> -- we need bosh
>> modules_enabled = {
>> "bosh";
>> "pubsub";
>> "turncredentials";
>> }
>>
>>
>>
>> VirtualHost "my.domain"
>> --enabled = false -- Remove this line to enable this host
>> authentication = "internal_plain"
>> ssl = {
>> key = "/etc/prosody/certs/meet.my.domain.key";
>> certificate = "/etc/prosody/certs/meet.my.domain.crt";
>> }
>>
>>
>> VirtualHost "meet.my.domain"
>> -- enabled = false -- Remove this line to enable this host
>>
>> authentication = "internal_plain"
>>
>> ssl = {
>> key = "/etc/prosody/certs/meet.my.domain.key";
>> certificate = "/etc/prosody/certs/meet.my.domain.crt";
>> }
>>
>> -- we need bosh
>> modules_enabled = {
>> "bosh";
>> "pubsub";
>> "turncredentials";
>> }
>>
>>
>>
>> Component "conference.meet.my.domain" "muc"
>> restrict_room_creation = "local"
>>
>> Component "jitsi-videobridge.meet.my.domain"
>> component_secret = "xxxxx"
>>
>> Component "callcontrol.meet.my.domain" component_secret = "yyyyyyy"
>>
>>
>>
>> And from jitmeet's config.js
>>
>> var config = {
>> hosts: {
>> domain: 'meet.my.domain',
>> anonymousdomain: 'guest.my.domain',
>> muc: 'conference.meet.my.domain', // FIXME: use XEP-0030
>> bridge: 'jitsi-videobridge.meet.my.domain', // FIXME: use
XEP-0030
>> call_control: 'callcontrol.meet.my.domain'
>> },
>>
>> On Mon, Nov 17, 2014 at 4:36 PM, Matthew Wild <mwild1@gmail.com> wrote:
>>>
>>> On 17 November 2014 08:30, Damian Minkov <damencho@jitsi.org> wrote:
>>> > Hi,
>>> >
>>> > I've just tested it and everything is working fine. Here is what I
did
>>> > to enable it:
>>> > - apt-get install jitsi-meet
>>> > - open the file for my host in /etc/prosody/conf.avail. Set the
>>> > authentication for the host to authentication = "internal_plain".
Then
>>> > copy the virtual host declaration and add to the name guest. and
>>> > change the authentication to anonymous. Add
restrict_room_creation
>>> > = "local" after component muc declaration.
>>> > - restart prosody
>>> > - Add account prosodyctl adduser me@my.domain
>>> > - open jitsi-meet config.js and uncomment anonymousdomain: and set
the
>>> > domain to guest....my.domain
>>> > - Open the url and was asked for credentials, enter them
>>> > - open the url on second tab no credentials asked and connect was
>>> > successful
>>>
>>> Maybe the issue or maybe not, but previously in this thread nobody has
>>> had quotes around "local" in Prosody's config. They're important...
>>>
>>> restrict_room_creation = "local"
>>>
>>> Also make sure it's placed under the MUC component in the config, and
>>> not inadvertently under another host/component.
>>>
>>> Regards,
>>> Matthew
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev@jitsi.org
>>> Unsubscribe instructions and other list options:
>>> http://lists.jitsi.org/mailman/listinfo/dev
>>
>>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#17

Just to let you guys know I purged my previous install and started again
from scratch.

It now works as expected. Not sure what the problem was but I'm glad it's
working.

Thanks to all those that helped out.

Cheers,
Peter

···

On Thu, Nov 20, 2014 at 3:26 PM, Peter Villeneuve <petervnv1@gmail.com> wrote:

Hi,

Thanks again Damian. I just wanted to make sure I wasn't missing anything
obvious.
The only difference I see in regards to my configs is that I also have a
domain.com virtual host (also with internal_plain) besides the
meet.domain.com (internal_plain) and guest.domain.com (anonymous).
I also have callcontrol enabled but that shouldn't make any difference.

I guess my next step is to purge jitmeet and reinstall the debian packages
again to see if the issue goes away for good.

Cheers

On Wed, Nov 19, 2014 at 7:22 PM, Damian Minkov <damencho@jitsi.org> wrote:

Hi,

as I described earlier, the configs are the standard one, that are
from the debian package, so there are those that you can find in the
git repo. I just added one more host and setting some configs. Here
are they. The prosody config is just a host configs put in
/etc/prosody/conf.avail and link in /etc/prosody/conf.d.

Regards
damencho

On Wed, Nov 19, 2014 at 7:43 PM, Peter Villeneuve <petervnv1@gmail.com> >> wrote:
> I've done a reboot of the server just to make sure it wasn't caching the
> config anywhere.
> Unfortunately I stil get prompted for creds as described above, so
that's
> not the problem either.
>
> Damian, could you post your config.js from jitmeet and your
prosody.config
> somewhere so I can look at it?
>
> Cheers,
> Peter
>
> On Tue, Nov 18, 2014 at 5:32 PM, Peter Villeneuve <petervnv1@gmail.com> >> > wrote:
>>
>> Thanks for trying to help out guys.
>> The issue isn't the " around restrict_room_creation = "local".
>>
>> I have done everything as damencho described, the only difference being
>> that I installed from git and not apt-get.
>>
>> Everything works as expected until the last step
>> > - open the url on second tab no credentials asked and connect was
>> > successful
>> Unfortunately on that last step I still get prompted for creds. I'm not
>> sure why it isn't working for me as it should. Has there been any
recent
>> change in the code on git that isn't in the debian package yet and
could be
>> causing this issue?
>>
>> I restart prosody and even nginx to make sure the config changes take
>> effect. I have cleared all the history in the Chrome clients used to
test to
>> make sure they weren't holding anything in cache, yet the creds popup
>> continues when entering an already created room. It's almost as if the
>> authentication = "anonymous" in guest.my.domain never gets applied.
>>
>>
>> Any clue to explain this behavior?
>>
>> Cheers,
>> Peter
>>
>>
>> Here's a snippet from my prosody config (and yes anonymousdomain has
been
>> uncommented and changed to guest.my.domain)
>>
>> ----------- Virtual hosts -----------
>> -- You need to add a VirtualHost entry for each domain you wish
Prosody to
>> serve.
>> -- Settings under each VirtualHost entry apply *only* to that host.
>>
>> --VirtualHost "localhost"
>>
>>
>> VirtualHost "guest.my.domain"
>> --enabled = false -- Remove this line to enable this host
>> authentication = "anonymous"
>> ssl = {
>> key = "/etc/prosody/certs/meet.my.domain.key";
>> certificate = "/etc/prosody/certs/meet.my.domain.crt";
>> }
>>
>> -- we need bosh
>> modules_enabled = {
>> "bosh";
>> "pubsub";
>> "turncredentials";
>> }
>>
>>
>>
>> VirtualHost "my.domain"
>> --enabled = false -- Remove this line to enable this host
>> authentication = "internal_plain"
>> ssl = {
>> key = "/etc/prosody/certs/meet.my.domain.key";
>> certificate = "/etc/prosody/certs/meet.my.domain.crt";
>> }
>>
>>
>> VirtualHost "meet.my.domain"
>> -- enabled = false -- Remove this line to enable this host
>>
>> authentication = "internal_plain"
>>
>> ssl = {
>> key = "/etc/prosody/certs/meet.my.domain.key";
>> certificate = "/etc/prosody/certs/meet.my.domain.crt";
>> }
>>
>> -- we need bosh
>> modules_enabled = {
>> "bosh";
>> "pubsub";
>> "turncredentials";
>> }
>>
>>
>>
>> Component "conference.meet.my.domain" "muc"
>> restrict_room_creation = "local"
>>
>> Component "jitsi-videobridge.meet.my.domain"
>> component_secret = "xxxxx"
>>
>> Component "callcontrol.meet.my.domain" component_secret = "yyyyyyy"
>>
>>
>>
>> And from jitmeet's config.js
>>
>> var config = {
>> hosts: {
>> domain: 'meet.my.domain',
>> anonymousdomain: 'guest.my.domain',
>> muc: 'conference.meet.my.domain', // FIXME: use XEP-0030
>> bridge: 'jitsi-videobridge.meet.my.domain', // FIXME: use
XEP-0030
>> call_control: 'callcontrol.meet.my.domain'
>> },
>>
>> On Mon, Nov 17, 2014 at 4:36 PM, Matthew Wild <mwild1@gmail.com> >> wrote:
>>>
>>> On 17 November 2014 08:30, Damian Minkov <damencho@jitsi.org> wrote:
>>> > Hi,
>>> >
>>> > I've just tested it and everything is working fine. Here is what I
did
>>> > to enable it:
>>> > - apt-get install jitsi-meet
>>> > - open the file for my host in /etc/prosody/conf.avail. Set the
>>> > authentication for the host to authentication = "internal_plain".
Then
>>> > copy the virtual host declaration and add to the name guest. and
>>> > change the authentication to anonymous. Add
restrict_room_creation
>>> > = "local" after component muc declaration.
>>> > - restart prosody
>>> > - Add account prosodyctl adduser me@my.domain
>>> > - open jitsi-meet config.js and uncomment anonymousdomain: and set
the
>>> > domain to guest....my.domain
>>> > - Open the url and was asked for credentials, enter them
>>> > - open the url on second tab no credentials asked and connect was
>>> > successful
>>>
>>> Maybe the issue or maybe not, but previously in this thread nobody has
>>> had quotes around "local" in Prosody's config. They're important...
>>>
>>> restrict_room_creation = "local"
>>>
>>> Also make sure it's placed under the MUC component in the config, and
>>> not inadvertently under another host/component.
>>>
>>> Regards,
>>> Matthew
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev@jitsi.org
>>> Unsubscribe instructions and other list options:
>>> http://lists.jitsi.org/mailman/listinfo/dev
>>
>>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#18

Unfortunately I also noticed that now jigasi is broken after adding the
anonymous domain and locking down jitmeet.

It used to work well and it still does if I unlock jitmeet.

Anyone else noticed this behavior?

Here's the jigasi log:

19:34:46.372 INFO: [44]
impl.protocol.jabber.OperationSetBasicTelephonyJabberImpl.registrationStateChanged().106
Jingle : ON
19:34:46.372 INFO: [44]
org.jitsi.jigasi.JvbConference.registrationStateChanged().432 XMPP
(149e872eb65@callcontrol.meet.my.domain): RegistrationStateChangeEvent[
oldState=Unregistered; newState=RegistrationState=Registering;
reasonCode=-1; reason=null]

Cheers,
Peter

···

On Fri, Nov 21, 2014 at 5:03 PM, Peter Villeneuve <petervnv1@gmail.com> wrote:

Just to let you guys know I purged my previous install and started again
from scratch.

It now works as expected. Not sure what the problem was but I'm glad it's
working.

Thanks to all those that helped out.

Cheers,
Peter

On Thu, Nov 20, 2014 at 3:26 PM, Peter Villeneuve <petervnv1@gmail.com> > wrote:

Hi,

Thanks again Damian. I just wanted to make sure I wasn't missing anything
obvious.
The only difference I see in regards to my configs is that I also have a
domain.com virtual host (also with internal_plain) besides the
meet.domain.com (internal_plain) and guest.domain.com (anonymous).
I also have callcontrol enabled but that shouldn't make any difference.

I guess my next step is to purge jitmeet and reinstall the debian
packages again to see if the issue goes away for good.

Cheers

On Wed, Nov 19, 2014 at 7:22 PM, Damian Minkov <damencho@jitsi.org> >> wrote:

Hi,

as I described earlier, the configs are the standard one, that are
from the debian package, so there are those that you can find in the
git repo. I just added one more host and setting some configs. Here
are they. The prosody config is just a host configs put in
/etc/prosody/conf.avail and link in /etc/prosody/conf.d.

Regards
damencho

On Wed, Nov 19, 2014 at 7:43 PM, Peter Villeneuve <petervnv1@gmail.com> >>> wrote:
> I've done a reboot of the server just to make sure it wasn't caching
the
> config anywhere.
> Unfortunately I stil get prompted for creds as described above, so
that's
> not the problem either.
>
> Damian, could you post your config.js from jitmeet and your
prosody.config
> somewhere so I can look at it?
>
> Cheers,
> Peter
>
> On Tue, Nov 18, 2014 at 5:32 PM, Peter Villeneuve <petervnv1@gmail.com >>> > >>> > wrote:
>>
>> Thanks for trying to help out guys.
>> The issue isn't the " around restrict_room_creation = "local".
>>
>> I have done everything as damencho described, the only difference
being
>> that I installed from git and not apt-get.
>>
>> Everything works as expected until the last step
>> > - open the url on second tab no credentials asked and connect was
>> > successful
>> Unfortunately on that last step I still get prompted for creds. I'm
not
>> sure why it isn't working for me as it should. Has there been any
recent
>> change in the code on git that isn't in the debian package yet and
could be
>> causing this issue?
>>
>> I restart prosody and even nginx to make sure the config changes take
>> effect. I have cleared all the history in the Chrome clients used to
test to
>> make sure they weren't holding anything in cache, yet the creds popup
>> continues when entering an already created room. It's almost as if the
>> authentication = "anonymous" in guest.my.domain never gets applied.
>>
>>
>> Any clue to explain this behavior?
>>
>> Cheers,
>> Peter
>>
>>
>> Here's a snippet from my prosody config (and yes anonymousdomain has
been
>> uncommented and changed to guest.my.domain)
>>
>> ----------- Virtual hosts -----------
>> -- You need to add a VirtualHost entry for each domain you wish
Prosody to
>> serve.
>> -- Settings under each VirtualHost entry apply *only* to that host.
>>
>> --VirtualHost "localhost"
>>
>>
>> VirtualHost "guest.my.domain"
>> --enabled = false -- Remove this line to enable this host
>> authentication = "anonymous"
>> ssl = {
>> key = "/etc/prosody/certs/meet.my.domain.key";
>> certificate = "/etc/prosody/certs/meet.my.domain.crt";
>> }
>>
>> -- we need bosh
>> modules_enabled = {
>> "bosh";
>> "pubsub";
>> "turncredentials";
>> }
>>
>>
>>
>> VirtualHost "my.domain"
>> --enabled = false -- Remove this line to enable this host
>> authentication = "internal_plain"
>> ssl = {
>> key = "/etc/prosody/certs/meet.my.domain.key";
>> certificate = "/etc/prosody/certs/meet.my.domain.crt";
>> }
>>
>>
>> VirtualHost "meet.my.domain"
>> -- enabled = false -- Remove this line to enable this host
>>
>> authentication = "internal_plain"
>>
>> ssl = {
>> key = "/etc/prosody/certs/meet.my.domain.key";
>> certificate = "/etc/prosody/certs/meet.my.domain.crt";
>> }
>>
>> -- we need bosh
>> modules_enabled = {
>> "bosh";
>> "pubsub";
>> "turncredentials";
>> }
>>
>>
>>
>> Component "conference.meet.my.domain" "muc"
>> restrict_room_creation = "local"
>>
>> Component "jitsi-videobridge.meet.my.domain"
>> component_secret = "xxxxx"
>>
>> Component "callcontrol.meet.my.domain" component_secret = "yyyyyyy"
>>
>>
>>
>> And from jitmeet's config.js
>>
>> var config = {
>> hosts: {
>> domain: 'meet.my.domain',
>> anonymousdomain: 'guest.my.domain',
>> muc: 'conference.meet.my.domain', // FIXME: use XEP-0030
>> bridge: 'jitsi-videobridge.meet.my.domain', // FIXME: use
XEP-0030
>> call_control: 'callcontrol.meet.my.domain'
>> },
>>
>> On Mon, Nov 17, 2014 at 4:36 PM, Matthew Wild <mwild1@gmail.com> >>> wrote:
>>>
>>> On 17 November 2014 08:30, Damian Minkov <damencho@jitsi.org> wrote:
>>> > Hi,
>>> >
>>> > I've just tested it and everything is working fine. Here is what I
did
>>> > to enable it:
>>> > - apt-get install jitsi-meet
>>> > - open the file for my host in /etc/prosody/conf.avail. Set the
>>> > authentication for the host to authentication = "internal_plain".
Then
>>> > copy the virtual host declaration and add to the name guest. and
>>> > change the authentication to anonymous. Add
restrict_room_creation
>>> > = "local" after component muc declaration.
>>> > - restart prosody
>>> > - Add account prosodyctl adduser me@my.domain
>>> > - open jitsi-meet config.js and uncomment anonymousdomain: and set
the
>>> > domain to guest....my.domain
>>> > - Open the url and was asked for credentials, enter them
>>> > - open the url on second tab no credentials asked and connect was
>>> > successful
>>>
>>> Maybe the issue or maybe not, but previously in this thread nobody
has
>>> had quotes around "local" in Prosody's config. They're important...
>>>
>>> restrict_room_creation = "local"
>>>
>>> Also make sure it's placed under the MUC component in the config, and
>>> not inadvertently under another host/component.
>>>
>>> Regards,
>>> Matthew
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev@jitsi.org
>>> Unsubscribe instructions and other list options:
>>> http://lists.jitsi.org/mailman/listinfo/dev
>>
>>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev