I see some disadvantages with the above approach and am wondering whether you think the problem could be successfully tackled as follows:
- Take the following system requirements into account:
(a) Only users of my Wordpress site who have been given a appropriate set of permissions should be able to use sparkweb and connect to openfire.
(b) Control over what services (e.g. chatrooms/conferences) a user is allowed (and when) to access could perhaps be managed using Wordpress group and permissions system.
© The only communications allowed are between wordpress users.from the site
(d) Openfire and wordpress are running on the same system
- How easy would it therefore be to:
(a) Manage openfire so that access to certain services could only be made via sparkweb provided the request comes from the appropriate port and IP combination.
(b) Remove the need for the user to supply username/password combinations and rely solely on wordpress controlling user access to certain pages.
I feel this approach, for my purposes, would be simpler to implement and maintain.
Could such a method be viable? It has the advantage of keeping, as far as possible, wordpress-sparkweb-openfire data storage systems independent of one another and removes complications when upgrades occur. It also means everything might be controllable from within Wordpress. There would ogf course still be the need to set up user names, room ID’s etc in openfire but a script to simultaneously update both databases would not be difficult to write. Once openfire is relieved of password testing it becomes a lot easier to control.
I think this would mean some changes to the way sparkweb operates so that the service requirement (e.g username/room name) could be passed when the page is called.
If anyone thinks there is some mileage in this it would help me an awful lot, bearing in mind my total unfamilarity with the source tree, if so0meone could possibly point me to the files and sections of code I would need to adapt to serve my purpose.
Many many thanks in advance for any further guidance.