Hello – I have a website that has a pre-existing MSSQL database and set of user tables used for authentication, and I’‘ve spent most of the afternoon trying to get Wildfire to use that preexisting database for its authentication needs, but the normal Jive database for everything else. (Essentially, I’'m trying to use two databases, one for authentication, and the other for everything else Wildfire does.) Using this thread as the best reference I could, I did the following things:
Message was edited by: delfuego (added line breaks to make the XML more readable)
combine the two DBs into one, but so far, I’'m seeing
that it’'s not going to work without at least moving
some defined subset of the Jive tables into my other
DB – jiveID, jiveVersion, jiveProperties, and
mucRoom, so far. Is this right?
No, not neccessarily. If you look at the bottom on the thread you linked to you’‘ll see how I talked about creating a second set of connection properities () if you don’‘t want to want to mix your existing tables with Wildfire’'s.
Yeah, Ryan, you’‘ll see from my first step that I created a new provider rather than editing the default one. Nonetheless, it seems that this provider is being used for gaining access to tables I didn’‘t think it should – and that’‘s what’'s confusing to me.
Are there any other classes that depend on the AuthProvider and UserProvider for access to their database and tables? If so, these are all going to look to my custom database, or at least that’‘s the behavior I’'m seeing.
Thinking about this a bit over the past hour, let me throw out an idea: in my custom classes (MyAuthProvider and MyUserProvider), I use DbConnectionManager.setConnectionProvider to change to my new custom provider for the auth calls. Does this set the provider globally, and thus interfere with any other classes that might be simultaneously (or just after) trying to connect using the DbConnectionManager? On the notion that this might be happening, I even created a new private instance of the DbConnectionManager in each of my custom classes, but this didn’'t help anything.
I’'d be happy to provide links to my custom files, if anyone thinks that this would help decode what might be happening!
I sorta answered my own question by looking over the DbConnectionManager class tonight and realizing that the whole thing is static, meaning that I am definitely setting my database provider globally when I use setConnectionProvider. This causes all database calls – those that have to do with user auth, yes, but also any that are happening at the same time or just after my call to setConnectionProvider – to be against my custom DB, not against the standard Jive database.
Is there a way to use the Wildfire API to set a second connection provider just for the user auth calls, but leave the connection provider intact for all other calls?
Has anyone got this working? I have a similar situation and have no idea where to start as far as writing custom connection classes and recompiling wildfire, etc… our shop is mainly LAMP, but i’'m trying to work the Wildfire server into our model – can anyone help?
So I managed to write a custom connection class that authenticates against different tables than the standard Wildfire ones… but learned that there really isn’‘t any way to get Wildfire to use an entirely different database for authentication than it uses for the rest of its operation. The DB connection class really is written in such a way that this would require quite a bit of modification to the base Wildfire source… and that’‘s not something that I’'m interested in doing.
I can confirm that we’'re running Wildfire with external user database. We use the LDAP user provider and Penrose virtual directory server to source the data from the database.
For more details see http://penrose.safehouse.com - Penrose has it’‘s warts and it’‘s still unreleased software, but compared to OctetString VDE it’'s free.
If anybody is interested, I could write a small article about the integration.
ddimitro, correct me if I’‘m wrong, but it sounds like you’‘re able to use a different user database by also using a different method of accessing the DB (LDAP, rather than the normal DB connection manager)… which makes sense. For my setup, I wanted simply to use my user tables that live in another entire MS SQL database (the same database that hosts my entire website) – but it seems like Wildfire’'s DbConnectionManager really is set up to provide a single DB connection across all the classes and components of the server, meaning that when I change the connection in order to access my user tables in the other database, any other (concurrent) DB accesses being made by other Wildfire classes get redirected to my database, and that causes big errors.
(Incidentally, I don’‘t really mean to complain about this, but felt it was worth a mention: it seems like the modus operandi for ryang is to pop into threads like this, provide ostensible answers to conundrums, and then when they don’‘t pan out to disappear entirely… which makes it hard to know if the assumptions we’‘re working on, or the solutions we’'ve found, are in fact correct…)
Yes, I’‘m using completely different access method (LDAP). I can’‘t really see the benefit of having only some tables from the Jive schema in a different database. For what it’'s worth you can set up a view.
If you really want to change the code, you’‘d better take a look at the LdapUserProvider and implement something in that fashion. You can have your own connection pool - e.g. using DBCP on top of a standard driver. It’'s a bit of work, but it should be straightforward.
No, it’‘s not that I wanted a few Jive tables in another database – it’‘s that I’‘ve had a database-driven website with user logins for about six years now, and I wanted Wildfire to use the user tables from that database. It doesn’'t make sense to me to force my users to have a second set of login credentials, one for the website and one for the Jabber server, nor did it seem like a great idea for me to come up with some complicated way of keeping the two user tables synchronized in real-time – hence me wanting to just use my original tables.
In the end, I just imported the entire Jive database schema into my website’‘s database, and left it at that. It isn’‘t too clean, and it means that now I’‘m trusting that there isn’'t anything hidden in the Wildfire code that could cause problems in the rest of my database… but it really was the only way to get the outcome I wanted.