I have seen in the <The Other> (name omitted for courtesy) XMPP server that it has possibility to authenticate the users via any external script. It starts the script and the scripts keep running, and it uses std. in, and out to communicate with the script. This is a very flexible thing and I miss it from Openfire. I just wanted to ask if anybody has done it yet? I guess I am going to write it anyway. It should be done such a way that the interface would be the same so that an authentication script would work with both XMPP servers. I would also publish it if I got OK from my employer.
It could be a useful AuthProvider if you do publish it. My biggest concerns with that method of doing things is saleability, but for small and medium sized setups that may not be so bad. Does the script interface also provide user-lookup (ie the UserProvider) or is it just for authentication?
The last link talks about the actual protocol and what it can do.
BTW, the problem to be solved was to authenticate using Drupal password or session id (both can be given by the client). I was not sure if HybridAuthProvider could handle two JDBCAuthProvider-s with different SQL queries. Another idea was to subclass from JDBCAuthProvider to create the specialized AuthProvider I needed, but it is not possible, because all the required member variables and functions are private. It may be a good idea to change these to protected. I didn’t want to do a wholesale code duplication, and started to think that a script based authentication provider could be the most flexible solution.
I just started to write the class and it should be ready on monday (I guess). If I get the green sign I will attach it. If not, everyone can write one easily.
I am happy to announce that the first version of ScriptAuthProvider is ready! I have been busy hence the delay. Please somebody review and commit it (I don’t want to bother for just one file). Could you please make sure that it gets to 3.5.2 even if experimental. That would be terrific. When will 3.5.2 be out?
It has been written using the 3.5.1 code snapshot, but I trust that it is compatible with the latest code.
Please note that I did not test it under heavy load, just tried it.
I think you want to synchronize the whole doAuthenticate method (or at least the write and reads together). On a busy server with multiple threads you might get threads A and B enter the first sync block as A,B, then both swap out, then hit the next sync block as B,A. Rare chance, but easily fixed for correct behavior.
It also wouldn’t be too much work to extend the support to handle the setPassword() method, since the script API supports this. Overall it looks ok. Ill talk to some Jive folks to see about getting it included if we can get the above changes implemented. In order to do so, you will need to fill out a contributer agreement form (How to contribute code), if you have not already. Without that agreement signed we cannot accept your code.
Thanks for the review, I have corrected my stupid synchronization bug. I have also added the set password support as you requested. I have attached the result.
Re: the link you gave: clicking on it I have to select a Community and then it creates a blank document with title “DOC-1495”.
OK, my company is a bigger one, so I will have to start the formal process including filling some internal form, getting legal, IPR, whatever OK for the contribution. Until then this “unofficial” contribution can be found and downloaded from here and can be taken into use. Not too big visibility though (but giving the URL of this thread in the documentation would help a lot). BTW if I remember correctly some existing auth providers are not mentioned in the documentation, for example the HybridAuthProvider. I just got aware of that by browsing the source. I understand though that maintaining the documentation is usually a low priority and boring job.
Oops, I didn’t update the page before replying. As I already wrote it will take some time before I will sign the contributor agreement as I would like to have the formal agreement to do so from my company. I hope that is not a major problem. Till then (and thereafter as well) may the source be with you!
The latest and greatest version (in case anyone cares to use it). What’s new:
Logs the stdout of the authenticator process (to Openfire log) if it does not send the expected stuff, useful for debugging the authenticator program,
Better handling for the case when the authenticator process exits (the earlier version did not authorize the auth request if the authenticator process exited, but only handled the next authentication request correctly).
I am sorry, I still haven’t started the opensource process at my company, I am busy and I don’t have much energy for the bureaucracy.