>Boris Jordanov wrote: >> >>> >>> A quick and simple description of how things are done. All data that >>> we get from RT is collected directly from the MySQL database. All >>> data that we put back in (create/update tickets) are done through the >>> CommandByMail extension. >> >> Not very useful in an open environment (internet, public networks). To >> make the database accessible from all over the net... >> >> >That's true. I'm not to familiar with global settings MySQL server, but >you have the possibility to use wildcards when setting up the user with >select rights on the database. That way you can at least restrict the >user to only connect from certain IP addresses. I'm guessing you have >some of those settings in the server settings also, but I'm not sure. > >Since it's a requirement form our "employer" (Gjøvik University College) >that this must be a stand-alone application we only had 2 choices. >Either try to get the data from the RT web service or get the data >directly from the MySQL database. We went for the second one. We have >the possibility to do SSL encryption on the SQL connection, but this >will still keep your MySQL server accessible...... > >If you or anyone else have a better solution for the problem we'll take >that into consideration and mabye change the way things are done now. >
I do have a better suggestion, but it's too involved and complicated to be of short term use to you. That is, RT needs a network API that you should use. It does have one, the REST/1.0 code used by the existing command line interpreter, but that is not extensive or extendable enough. I have sketched some thoughts on this here: http://tigger.uic.edu/~bobg/rt_api.html But I haven't had any time to write code and see how well it might work. The reason the API is needed is not so much for security, but because the official interpretation of the data _is_ the perl code. If you want to write a new java UI, you really want to be manipulating the perl objects on the server, not the raw data. (Doesn't matter they are perl. A remote machine would think of them as 'server objects') That way, all the ACLs and other data interpretation/enforcement are done properly and consistently, particularly when RT is upgraded. And, of course, such an API would make it much easier and safer to integrate RT with other systems. (My personal need is to hookup RT with our account provisioning system. Another is to connect RT with a non-RTFM Knowledge Database. I can also imagine connecting RT with other (RT as well as non-RT) helpdesk systems to share tickets. ) And, alternate UIs for specialized purposes. bobg _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
