Sorry for my stupid question...
But I really miss the point.
Why can be need authentication with external databases etc ?
Even with external authentication ejabberd has to store user data, roster, JID, offline messages, and so on...
Also, if we disable or delete record from external database, data in ejabberd still be there...
Maybe it will be easier and more handy... to use ejabberd data and external DB-data and credentials as well (if You need it for some purpose). I mean same logins and passwords.
What the advantage of external authentication? We just save a bytes needed to store password in mnesia, or what?
I think I'm wrong, but I can't understand, where I'm wrong :)
Well, I guess
When data is duplicated, there's a chance for inconsistency. When a duplicate changes, then that change must be spread to all the duplications.
Imagine an organization that already has a LDAP server to store usernames and passwords of 10.000 humans. They used it for years to authenticate SMTP server, POP3 server, WebDAV and machine logins. Now they plan to deploy ejabberd for instant messaging.
They could export the LDAP database to the format of ejabberd's 'passwd' table. Then import that data in ejabberd. And then setup a script that, everytime a new user is created in LDAP, or deleted, or changes his password; that change is replicated in ejabberd database.
Or they can configure ejabberd to authenticate the users against a remote LDAP server.
Again
Thanx for reply...
BTW.. I still wonder, why the need in auth with external databases... if You use external auth, You should however create, delete entity of "user" in ejabberd, when You create or delete user in external DB...
But!... It seems I find a cool and very usefull thing for web-clients... (details I'll write later, if it succeed)...
And in my idea, main thing - is ability to auth ejabberd users with "external script"...
I browsed in these scripts http://www.ejabberd.im/extauth
And I found, that ejabberd can actually make a 3 types of requests to the external auth script:
They are:
1. "auth" ejabberd sends to script User:Server:Password - and check if a username/password pair is correct
2. "isuser" ejabberd sends "User:Server" and check if it’s a valid user
3. "setpass" - ejabbed tries to change user's password.
I don't think is need in my purpose to provide an ability to change password with jabber-client (as I see, many scripts also denies such request)... so I not interested much in this..
But... I'd like to kindly ask You... and my question is -
Can You please tell, in wich case ejabberd sends "isuser" request to the external script? When user with jabber-client tries to login, ejabberd first checks, if user exist, and if it's true, makes a second, "auth" request with provided password?
Is this true? If just "auth" request is not enough to login?
Try register, Anonymous login and other usages
Can You please tell, in wich case ejabberd sends "isuser" request to the external script? When user with jabber-client tries to login, ejabberd first checks, if user exist, and if it's true, makes a second, "auth" request with provided password?
Is this true? If just "auth" request is not enough to login?
It just takes some minutes to search in the source code:
is_user_exists(User, Server) ->
call_port(Server, ["isuser", User, Server]).
%% We do not allow empty password:
try_register(_User, _Server, "") ->
{error, not_allowed};
try_register(User, Server, Password) ->
case is_user_exists(User,Server) of
true ->
{atomic, exists};
false ->
...
mech_step(State, _ClientIn) ->
%% We generate a random username:
User = lists:concat([randoms:get_string() | tuple_to_list(now())]),
Server = State#state.server,
%% Checks that the username is available
case ejabberd_auth:is_user_exists(User, Server) of
true -> {error, "not-authorized"};
false -> {ok, [{username, User},
{auth_module, ejabberd_auth_anonymous}]}
end.
It's also called in ejabberd_sm, mod_configure and mod_vcard_ldap.
So I guess 'isuser' is not called to login an existing account.
Yes, dear badlop
You're right, "isuser" is not called to login....
I accept Your allusion, that I should first check the source code before asking a question.
But... I'm novice in erlang, at last weekend I started to learn it, but.. I'm not very young, I feel it more and more, and new conceptions is not easly comes to me, I feel that my head is almost full of info of different kind...
But it's irrelevent...
Yes, I should as least write my own auth script and log request... but I done it now...
And I discover, that "isuser" is not called to login, You're right, but... it seems, that "isuser" is sent in every case, that user want to send a message to another user, or chat.
And now it's looks also strange for me... Imagine, for example, I wrote script to authenticate with my DB... So, if I get request at every user login, it would be OK, but, if my script get "isuser" command at every message, and has to ask DB.... it's very heavy load thing, I suppose...
Why is need in external "isuser" request to script, isn't jabberd itself can serve it?
To finalize this topic :)
Unfortunately, my "cool idea" to authenticate with external sript, failed...
As I wrote in previous message, I think, this idea is not good, because of unreliability (I have no idea, how many processes/scripts will run on quite heavy loaded server), how to kill time to time these scripts..
Also, I repeat, I found, that auth script will called at EVERY message (maybe only when destination user is offline)... and I think it's unacceptable on heavy deployments.
Maybe I'm wrong... But... I decided to go "another way"...
However... I think my idea may interested someone... also, I saw in older topics, someone asked about "temparary passwords", ans so on... Maybe someone find here something useful.
So... Imagine, You have a website. User should login... after that, user redirects to page with some content and flash-jabber client (have You patched Your ejabberd with flash- and policy- hacks? :).
There is a problem. User should enter his password twice to connect to ejabberd with flashclient (it's sucks :)
OR - webmaster should call flashclient with paramters, where is jabber login and password (it's insecure :)
OR - flashclient can load login and password at very start, using, for example, "loadvars" or "loadVariables" flash object.
Regretfully, it is also insecure - because some webbrowsers with some flash client stores loaded (with loadvars) html-data in local file, even loaded html has full set of "nocache" headers and "POST" method used.
So... solution (not good solution, I reject it) - is following:
Suppose user enter login and password with HTML form. PHP script than checks the data, and if OK, stores some flag in $_SESSION variable - i.e. $_SESSION['user_id'].
After that flash-jabber client is called with two params - login and PHPSESSID - !
And last one, PHPSESSID will be used to connect to jabber server!
And our ejabberd server configured to use external auth script.
Script as simple as -
#!/usr/bin/php<?php
ini_set ('session.use_cookies', '0');
ini_set ('session.save_path', '/tmp/');
// it's command-line script, in many installations session save path is different in webserver and cli.
// We must shure, that this path is the same in both.
ini_set ('display_errors', '0');
define ('SERVERNAME', 'coolserver');
function authOK() { fwrite(STDOUT, "\0\2\0\1"); }
function authFail() { fwrite(STDOUT, "\0\2\0\0"); }
// according to docs, we must provide ONLY two cases - OK or not OK :)
while(1)
{
$iHeader=fgets(STDIN,3);
$aLength=unpack('n', $iHeader);
$iLength=$aLength['1'];
if ($iLength > 9) // minimum length of user and password.
{
$sData=fgets(STDIN, $iLength+1);
list($Command,$User,$Server,$Password)=explode(":",$sData);
if ($Command=='auth' && $Server==SERVERNAME)
{
session_id($Password); // force session with given temporary PHPSESSID as password
session_start();
$uid=$_SESSION['id'];
session_write_close();
if ($uid && $uid==substr($User,1)) authOK(); else authFail();
}
else authFail();
}
else authFail();
}
So... maybe I miss something, but something like that works ok for me with test cases...
Despite, as I said, I decided not use it... it can be useful to someone, I think...
Or, maybe, will lead to better solution...