[ejabberd] Subdomains Authetication!

Henrique Fernandes sf.rique at gmail.com
Mon Feb 28 19:41:19 MSK 2011


Another ideias ?


[]'sf.rique


On Mon, Feb 28, 2011 at 1:01 PM, Armando Di Cianno <
armando.dicianno at gmail.com> wrote:

> On Mon, Feb 28, 2011 at 10:39 AM, Henrique Fernandes <sf.rique at gmail.com>
> wrote:
> > I already configured the ejabberd to exterauth. it is already working!
>
> Glad it works! In the long run, you may want to consider implementing
> your auth scheme by adding a new auth module to ejabberd - for e.g.,
> try copying the pam one ejabberd_auth_pam.erl, it's pretty simple, and
> you'll find less weird behavior over all. YMMV with extauth, but for
> me while it worked as advertised, there were too many quirks,
> especially regarding timeouts and disconnects followed by
> re-authentication.
>
> We don't wnat that kind of effort. I mean, if it is the only option wi
might consider but not right now!

> > So i just need to configured the ajabberd to authenticated subdomains.
>
> You could have the auth module enact different behavior based on the
> host it was started on. When you configure per-host settings for any
> module, it will start a process for each host, so you will have the
> particulars like the domain name available. (This has been my
> experience, someone correct me if I'm fudging the intricacies.)
>

It will not be any diference for any host.
I just don't want multiple script to be loaded.

But thanks!

>
> >The
> > problem is, if i set in {hosts ["all", "my", "host"} it will open one
> script
> > for each subdomain, and we have about 70 subdomains. It takes lots of
> > resources from the machine. Plus my script autenticated any subdomain!
>
> I have a script that generates the files for my servers, for all the
> virtual hosts / domains. The result resembles the following
> description:
>
>  * Extremely minimal ejabberd.cfg - a "default" domain setup for admin
> purposes, but barely any modules turned on. Script generates the
> {host, ...} entry.
>  * The bottom of ejabberd.cfg looks like the following:
>   > {include_config_file, "/etc/ejabberd/HOST_A/all.cfg"}.
>   ...
>   > {include_config_file, "/etc/ejabberd/HOST_Z/all.cfg"}.
>  * Most of my "hosts" have sub-sub-domains, ergo the "all.cfg" file
> that includes even more. E.g. all.cfg:
>   > {include_config_file, "/etc/ejabberd/HOST_A/demo.cfg"}.
>   > {include_config_file, "/etc/ejabberd/HOST_A/test.cfg"}.
>   > {include_config_file, "/etc/ejabberd/HOST_A/staging.cfg"}.
> ... not all my hosts have this, but most do.
>  * Then, in the actual, really-this-time config files referenced in
> the step above, I do my per-host configuration.
>  * I wish I knew how to refactor out the {hosts, ...} line out of the
> main ejabberd.cfg file, but I do not.
>  * I wish I could rely on the DB more, and not just the config files,
> but the admins here don't like that idea (*sigh*).
>
> __armando
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jabber.ru/pipermail/ejabberd/attachments/20110228/ccc22bd8/attachment-0001.html>


More information about the ejabberd mailing list