headers
Bzzz | 1 Jun 2012 20:58
Picon
Favicon

Users can join a password protected room + another question

Debian sid
ejabberd 2.1.10-2
pidgin 2.10.4-1.1 on sid (package)
pidgin from 2.10.4 tarball (on squeeze)
========================

Hi list,

I've got a setup as:

{access, muc_admin, [{allow, all}]}.  %% Anybody can create (FUGITIVE) rooms
{access, muc_admin_persistent, [{allow, admin}]}. %% BUT ONLY admins can create PERSISTENT rooms
{access, muc_access, [{allow, all}]}.  %% All users are allowed to use MUC service
...
...
    {mod_muc,  [
        {host, "conference. <at> HOST <at> "},
        {access, muc_access},           %% Who's able to access rooms?
        {access_create, muc_admin},     %% Who's able to create rooms?
        {access_persistent, muc_admin_persistent},  %% Only admins can create persistent rooms
        {access_admin, muc_admin},      %% Only admins can administer rooms
        {max_room_name, 60},            %% Max 60 chars for room names
        {max_room_description, 250},    %% Max 250 chars for room descriptions
        {history_size, 10},             %% Send the last 10 msgs to new comers
        {max_users, 500},               %% Max Nb of users per room
        {default_room_options, [        %% Default options for new rooms
            {allow_change_subj, false}, %% Only the creator can change the room subject
            {allow_query_users, false}, %% ? (can't see ≠ from true)
            {allow_private_messages, true},  %% Allow each user to privately contact another one
            {members_by_default, false},     %% ?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bzzz | 4 Jun 2012 01:54
Picon
Favicon

Re: Users can join a password protected room + another question - [solved]

On Fri, 1 Jun 2012 20:58:07 +0200
Bzzz <lazyvirus <at> gmx.com> wrote:

> pidgin 2.10.4-1.1 on sid (package)
> pidgin from 2.10.4 tarball (on squeeze)

This one was weird (and cost me some time to grep a debug log:(

In this version of Pidgin it seems the only way to correctly
configure a chatroom is to do it _after_ its creation by 
typing /config into the chatroom text input area (which open 
exactly the same conf window than when creating it).

JY
--

-- 
Alimony is like buying oats for a dead horse.
		-- Arthur Baer
Permalink | Reply | 0 comments |
headers
Badlop | 6 Jun 2012 13:53
Picon

Re: Users can join a password protected room + another question

On 1 June 2012 20:58, Bzzz <lazyvirus <at> gmx.com> wrote:
> {access, muc_admin, [{allow, all}]}.  %% Anybody can create (FUGITIVE) rooms
> {access, muc_admin_persistent, [{allow, admin}]}. %% BUT ONLY admins can create PERSISTENT rooms
> {access, muc_access, [{allow, all}]}.  %% All users are allowed to use MUC service

With that, muc_admin allows everybody.

>    {mod_muc,  [
>        {host, "conference. <at> HOST <at> "},
>        {access, muc_access},           %% Who's able to access rooms?
>        {access_create, muc_admin},     %% Who's able to create rooms?
>        {access_persistent, muc_admin_persistent},  %% Only admins can create persistent rooms
>        {access_admin, muc_admin},      %% Only admins can administer rooms

And with that, access_admin is for everybody.

> * Users can create fugitive rooms, but if the user protect he's room
>  w/ a password, any other user can connect without entering this
>  password!? (my test users are, of course, not admins).

Right, because access_admin allows, among other things, to bypass the
room passwords verification.

> So, my 1st question is: where am I wrong with users's rooms password
> access not working?

Your configuration is incorrect for what you want to do.
Probably this will be better:

{access, muc_everyone [{allow, all}]}.
(Continue reading)

Permalink | Reply | 2 comments |
headers
郎咸武 | 7 Jun 2012 14:16
Picon

About mod_pubsub() confused

Hi guys.

Recently, I read mod_pubsub source.
There are some confused in the mod_pubsub:init_nodes/4.
It create 2 nodes via 
 create_node(Host, ServerHost, string_to_node("/home"), service_jid(Host), "hometree"), 
 create_node(Host, ServerHost, string_to_node("/home"), service_jid(Host), "hometree"), 
source code.
I do not understand what these two nodes is used to do.
Please help me .
I can really appreciate your reply .

Cheers, Jason
--
只为成功找方法，不为失败找理由
_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Permalink | Reply | 2 comments |
headers
CGS | 7 Jun 2012 15:14
Picon

Re: About mod_pubsub() confused

Hi,


I am not an expert in Ejabberd, but I see those nodes as necessary as two types of connections are necessary (publishers and subscribers) for the same pointer. I am not sure if that is the reason, so, maybe someone more knowledgeable will come forward with a better answer.

CGS




On Thu, Jun 7, 2012 at 2:16 PM, 郎咸武 <langxianzhe <at> gmail.com> wrote:
Hi guys.
Recently, I read mod_pubsub source.
There are some confused in the mod_pubsub:init_nodes/4.
It create 2 nodes via 
 create_node(Host, ServerHost, string_to_node("/home"), service_jid(Host), "hometree"), 
 create_node(Host, ServerHost, string_to_node("/home"), service_jid(Host), "hometree"), 
source code.
I do not understand what these two nodes is used to do.
Please help me .
I can really appreciate your reply .

Cheers, Jason
--
只为成功找方法，不为失败找理由

_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd


_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Permalink | Reply | 1 comment |
headers
Bzzz | 7 Jun 2012 15:50
Picon
Favicon

Re: Users can join a password protected room + another question

On Wed, 6 Jun 2012 13:53:22 +0200
Badlop <badlop <at> gmail.com> wrote:

> On 1 June 2012 20:58, Bzzz <lazyvirus <at> gmx.com> wrote:
> > {access, muc_admin, [{allow, all}]}.  %% Anybody can create
> > (FUGITIVE) rooms {access, muc_admin_persistent, [{allow,
> > admin}]}. %% BUT ONLY admins can create PERSISTENT rooms
> > {access, muc_access, [{allow, all}]}.  %% All users are allowed
> > to use MUC service
> 
> With that, muc_admin allows everybody.

I first missed what you explain below: that MUC admin is tied to
to the service, not to the owner's right to administer its own 
room.

> 
> Right, because access_admin allows, among other things, to bypass
> the room passwords verification.

This is what I finally discovered. 

> 
> Your configuration is incorrect for what you want to do.
> Probably this will be better:
> 
> {access, muc_everyone [{allow, all}]}.
> {access, muc_admin, [{allow, admin}]}.
> 
> and then (notice that I set in capital some conceptual
> corrections):
> 
>         {access, muc_everyone},           %% Who's able to access
> rooms? {access_create, muc_everyone},     %% Who's able to create
> rooms? {access_persistent, muc_admin},  %% Only admins can SET
> ROOMS AS persistent
>         {access_admin, muc_admin},      %% Only admins can
> administer THE SERVICE

I did almost exactly what you say, except I created 4 VARs for
my own understanding: muc_access, muc_create, muc_persistent &
muc_admin - the first two are bound to [{allow, all}] and the last
two to [{allow, admin}]; unfortunately this is not working.
Users aren't able to create their own rooms!

This is what I do (and I did before) in Pidgin to try to create
a user room:
Main menu Buddies > Join a chat > [enter a new chat name] > hit the
Join button
but I get a popup w/ a "401: Not authorized".

In order to be sure it wasn't due to Pidgin retaining old setup, I
stopped all clients and restarted  ejabberd, then restarted the
clients.

> > My 2nd question is: where can I found a correspondance list
> > between pidgin room detailed options and ejabberd primitives, in
> > order to have the room details pre-filled as I want (thus people
> > won't have to edit details)?

I figured this one (thanks to the ejabberd embedded docs:)

--

-- 
Never argue with a woman when she's tired -- or rested.
_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Permalink | Reply | 1 comment |
headers
Bzzz | 7 Jun 2012 17:47
Picon
Favicon

Re: Users can join a password protected room + another question [SOLVED]

On Thu, 7 Jun 2012 15:50:05 +0200
Bzzz <lazyvirus <at> gmx.com> wrote:

My bad: I didn't realized that indicating a password in
the default_room_options is creating a side effect as enforcing
the obligation to use it,  even when a user creates he's 
own chatroom.

Thanks for your explanations, Badlop!

Jean-Yves
--

-- 
<Overfiend> the kind of landscape that laughs at "AWD" vehicles and
            sends them tumbling into ravines
Permalink | Reply | 0 comments |
headers
郎咸武 | 8 Jun 2012 04:47
Picon

Re: About mod_pubsub() confused

CGS, Thanks, me too.

2012/6/7 CGS <cgsmcmlxxv <at> gmail.com>
Hi,

I am not an expert in Ejabberd, but I see those nodes as necessary as two types of connections are necessary (publishers and subscribers) for the same pointer. I am not sure if that is the reason, so, maybe someone more knowledgeable will come forward with a better answer.

CGS




On Thu, Jun 7, 2012 at 2:16 PM, 郎咸武 <langxianzhe <at> gmail.com> wrote:
Hi guys.
Recently, I read mod_pubsub source.
There are some confused in the mod_pubsub:init_nodes/4.
It create 2 nodes via 
 create_node(Host, ServerHost, string_to_node("/home"), service_jid(Host), "hometree"), 
 create_node(Host, ServerHost, string_to_node("/home"), service_jid(Host), "hometree"), 
source code.
I do not understand what these two nodes is used to do.
Please help me .
I can really appreciate your reply .

Cheers, Jason
--
只为成功找方法，不为失败找理由

_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd



_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd




--
只为成功找方法，不为失败找理由
_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Permalink | Reply | 0 comments |
headers
Bzzz | 8 Jun 2012 16:55
Picon
Favicon

Forbid parts of web administration I/F

Hi list,

Knowing people for whom I'll install ejabberd, and they 
won't have a root access to the server, I'd like to 
forbid some parts of the web administration I/F to
avoid bulls.

Specifically, I don't want them to have access to:
* ACLs
* Access rules
* Database configuration

If it need "sub-admins", this is not a problem.

I greped the docs and googled about that, but I can't find
any valuable information.

Jean-Yves
--

-- 
* Culus fears perl - the language with optional errors
Permalink | Reply | 6 comments |
headers
Badlop | 8 Jun 2012 17:39
Picon

Re: Forbid parts of web administration I/F

On 8 June 2012 16:55, Bzzz <lazyvirus <at> gmx.com> wrote:
> Hi list,
>
> Knowing people for whom I'll install ejabberd, and they
> won't have a root access to the server, I'd like to
> forbid some parts of the web administration I/F to
> avoid bulls.
>
> Specifically, I don't want them to have access to:
> * ACLs
> * Access rules
> * Database configuration
>
> If it need "sub-admins", this is not a problem.

Basically, if I understood correctly, you want them to administer only
some vhosts, not the whole server.

For that, don't define such admins as server admins:
{acl, admin, {user, "user34", "example.org"}}. %% NO!

Instead, define them as admins of a specific vhost:
{host_config, "example.org",
 [
  {acl, admin, {user, "user34", "example.org"}}
 ]
}.

Or go to the webadmin and check yourself that those users are only
described as admins in the ACL pages of the corresponding vhosts, not
on the whole/root ACL page.

---
Badlop
ProcessOne
Permalink | Reply | 5 comments |

Gmane