Rusty's Blog

Thoughts and musings of someone who's not sure what 'normal' is…

Monday, July 20, 2009

90% done…

…90% to go.

I posted a half humorous note on my facebook page Friday (or was it Saturday morning?) that had a list of tasks I wanted to do this weekend. Asside from a bit of formatting, I’ve gotten what I think should be the most important part of the list done.

One of the problems I have at work is that I can’t exactly launch any IM client and start chatting with people. I have a few philisophical problems with the Microsoft Communicator client at work. But am happy to use it for the most part. The biggest issue I have is that you can’t update contact information to display a custom identifier for someone. If it isn’t published in the domain the way you want it to appear, too bad so sad. Oh, I understand some of the reasoning behind that. No labeling your boss the ‘idiot in charge’ and stuff like that. But if there are two John Smith’s in your business, it can take significant additional knowledge to confirm that you have selected the right John Smith to send a message to. If you know that one of them preferrs to be called Jonathan, it makes sense to be able to put that in an alias for the user in the IM client. But that’s locked out at the moment. I’m not holding out a lot of hope that it will change either.

However that’s still not the significant issue for me. The real issue is that I can’t connect to the resources I would like to. Particularily my own jabber server.

So I have had to come up with a kludge. And the first half works for now.

The kludge is that I have put together a monitoring client for my jabber server that attaches as one of my resources, and simply collects each IM that I receive, and tosses it into a tab separated values file. (I’ve had issues with comma separated values in the tool that I use to read the messages, so rather than fight with them, I’ve set up the tool to work with me.

The other issue I’ve had over the years or so has been that I’m never really sure what happens to an IM sent to me while I am away, or if I get something and the client dumps for some reason. This way I should get a reasonably comprehensive copy of my IMs while I am otherwise occupied. In theory I could set up the client so that at any time I could pull up a list of messages on another session, sort of using it as a secretary within jabber. Who knows, I may just do that at some point. Not tody though.

On top of that I needed a way of displaying those messages. I have that now too. I was able to use some of the code I wrote a while back. Ok, I basically grabbed something out of a php tutorial at some point, and I’ve been re-arranging things ever since. In any case I revised the code again, and now I can view the contents of the capture file. Basicly the tool I’m using displays the contents of the formatted text file in a table.

Things ain’t quite perfect yet. The script crashes out on unicode character issues, which I’m not sure I have a good way to get arround, but until it dies, I can at least see most of the messages I get.

The second half of that list should be easier. Well, the actual sending of messages will be. However I am not building the sender code without adding some security wrapper to the system. That URL will need authentication before it should accept a message to send. The reality is that I need to build the authorization and authentication system in such a way that it can not easily be spoofed. One of the problems with the easiest sollution I can come up with is that I don’t know if there is a way to maintain authentication without adding some sort of SSL or https sollution to the mix.

This is a ‘solved problem’ you may be saying. Use https or ssl. Not so fast. First of all I need to build the platform so that I can get such a solution through the firewall at work. Not necesarily trivial, however that on it’s own is not a serious problem. The greater problem is that to use the appropriate ports on my server, I need ot abandon features that I very much do not want to abandon. so not so easy.

The next obvious sollution is to use gpg to encrtype the user credentials and then base 64 encode the encrypted credentials and send that off as a cookie that can be asked for at any time. The problem here is that with the exception of a user on a public internet server, the encrypted credentials could be used by anyone on a nat traversing link. Capture the cookie with airsnort or the like, and you suddenly have everything you need to look like me to my server. So that’s not a solution I’m happy with.

I suppose I could implement a variation of a kerberose solution. Point the user at a third party location for logging in using a ssl or https session there, then that system provides a token back to the local web server that is provided to the user’s workstation in a cookie that is only good for a few minutes, and the user needs to re-authenticate again if they exceed that time. A varriation would be to only allow the user to post if a persistent authenticated secure session exists with the third party server. (separate tab or window that could be minimized) One possible variation would be to build in open-id/open-auth. I’m already using that at one level for this blog, however I’m not sure that either have a system that works well with passing arround jabber credentials securely.

I don’t think I’m going to get that part of the solution implemented this weekend.

Oh well.

posted by Rusty at 12:58 pm  

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress