I am trying to set up Gateway permissions (i.e., which users can connect to which transports). I go into the Gateway Settings page, click on Permissions on any of the transports and select “These users and/or groups can register”. When I select “Modify Users” or “Modify Groups”, the setting goes back to “All users can register” and I get the Gateway Settings page. This happens on both Firefox and Safari.
Looking at the Wiki documentation I see that I can set the plugin.gateway.XXXX.registration property to 2 to enable this. Now, how do I set up the users and groups (even if I have to set them up manually without the UI)? Does this functionality currently work?
I upgraded to the latest gateway.jar and now the UI works. I haven’'t had a chance to check whether it actually does something or not, though.
well, for me the second option (These users and/or groups can register) is not working. I’‘ve already added an user and saved ok, no problem…but when this user try to register i got an error, like this user doesn’'t have rights to register.
I’'m using imgateway 1.6b and Spark as client.
Everything else is working (about permissions)
Hrm. What did you enter for the username? Full JID or just the username period of the JID?
I’‘ve tried both, just the username and thge full JID, and neither worked. FWIW, I’‘m using LDAP authentication. After adding them I looked in the gatewayRestrictions table and it was empty (I assume that’'s where the allowed users/groups are stored?). What would also be good is to know how the permissions are actually stored in the tables, so we could integrate them into our user management system.
Message was edited by: mcamou
Message was edited by: mcamou
Hrm. I wonder if I have to do something special to look up LDAP users in my code? I verify all users before I accept them in the list. I created GATE-163 to remind myself to look into it.
As for the actual gatewayRestrictions table, basically you just put in the transportType (aim, icq, yahoo, msn, or irc), and EITHER fill in the groupname field or the username field. The username will be the store non-full jid (like daniel instead of daniel@jabber.vorpalcloud.org). Groups are short names of groups, but you don’'t appear to be asking about that. You could fill in all that information directly if you want. =D (ie insert directly into the database table)
The groups are actually working fine (with the group name), it’‘s just individual users that don’'t work (and it would be a great thing to have users working for integration into our admin system). One thing I wonder… what happens if you have 2 groups in LDAP with the same name? (In my mapping I use the cn attribute as the group name and you could conceivably – even easily – have 2 or more groups with the same name). In my particular scenario it would be excellent if the group acted as a single group composed of the members of both groups.
However, it would be best to have the authorization by user working since we will have several thousand users and the authorization groups could conceivably be really large (which slows things down tremendously at the LDAP layer). If it worked by user you would get a single row back from the DB (I’'ve been looking at the PostgreSQL logs to see what the queries look like).
mcamou wrote:
The groups are actually working fine (with the group name), it’‘s just individual users that don’'t work (and it would be a great thing to have users working for integration into our admin system). One thing I wonder… what happens if you have 2 groups in LDAP with the same name? (In my mapping I use the cn attribute as the group name and you could conceivably – even easily – have 2 or more groups with the same name). In my particular scenario it would be excellent if the group acted as a single group composed of the members of both groups.
I don’‘t actually know what would happen in that scenario without diving deep into the Wildfire source itself. I’‘m using Wildfire API calls to get at the groups. I’'d be interested in hearing what the answer to this is though! Would you mind posting this question in the Wildfire Support forum?
However, it would be best to have the authorization by user working since we will have several thousand users and the authorization groups could conceivably be really large (which slows things down tremendously at the LDAP layer). If it worked by user you would get a single row back from the DB (I’'ve been looking at the PostgreSQL logs to see what the queries look like).
GATE-167 =)
Well, i’'m not using LDAP, just postgresql and i have the same problem.
I can add users and groups to ‘‘white list’’, but when i try to set-up signup info on clients i got an error, the same as when user is not enabled to use this service/gateway.
BTW, i’'ve tried username and full JID…none worked.
Message was edited by: jmaurin
jmaurin wrote:
Well, i’'m not using LDAP, just postgresql and i have the same problem.
I can add users and groups to ‘‘white list’’, but when i try to set-up signup info on clients i got an error, the same as when user is not enabled to use this service/gateway.
BTW, i’'ve tried username and full JID…none worked.
Message was edited by: jmaurin
After you saved your white list and reloaded the page, does the list remain in place? Do you see anything in your debug/error logs when the person tries to sign up? I’'m assuming, of course, that all of the users are on the same server that the plugin is running on. If you look in the gatewayRestrictions, do you see the white list that you had created?
In my case, if I add the users with the full JID they eventually disappear. If I add them with just the userid they remain (but still can’‘t log on). I will check later if there are any messages in the logs but I don’'t seem to recall seeing any either on the debug or the error logs.
So far I can’‘t duplicate this, but I’'m still trying some things as well.