sipXconfig
Wednesday, November 23, 2005
 
Embedding ANT as automatic DB schema upgrader
Anyone who has developed code with other developers that uses a database can sympathize with this dialog
Joe : "Hey, just checked in some code, you need to run this SQL script to create the new tables."
Mary: "It's not working, my schema already has some of those tables from last time"
Joe: "Drop all those, maybe you better drop entire db to be safe"
Mary: "But I'm in the middle of developing something, dang I shouldn't have updated my code"

sipXconfig went to use ANT to break up these little DB schema upgrades into "patches" that are intelligent enough to know when to run and remember when they've been run before. I'm very happy with this and it actually required ZERO java coding!
http://scm.sipfoundry.org/rep/sipX/main/sipXconfig/neoconf/etc/database/database.xml

Rule was you never edited a patch once it was checked in, you only patched other patches. It was still difficult in early development stages when your portion of the schema changed drastically and you left a long string of patches behind. So I came up with a patch that clears itself and applies itself everytime the application runs.


<target name="drop-firmware" if="firmware">
<sipx-sql>
drop table firmware;
drop sequence firmware_seq;
delete from patch where name = 'firmware';
</sipx-sql>
</target>

<target name="firmware" depends="drop-firmware">
<db-patch patch="firmware">
</target>


sipx-sql runs a SQL script and db-patch does the same but also marks that the script has been applied before so that next time this ant file is run "if=firmare" will be true. Details are in the database.xml from above.

At some point when these tables stablize, I can just change it to this


<target name="firmware" unless="firmware">
<db-patch patch="firmware">
</target>

Thursday, November 17, 2005
 
Waiting for remote video

somebody w/video call me...

Compusa had a sale on webcams, 2 Creative labs Live web cams for $70. Other one will be xmas gift so someone will call me, maybe my brother will use it.

Wednesday, November 16, 2005
 
Please, all sales final
It's how I remember what order to put my java method and field modifiers
public abstract static final ...
I say it to myself half-dozen times a day, so I thought I'd share.

Wednesday, November 09, 2005
 
SOAP Authentication
Decisions, decisions

As a web services rookie, authentication is a challenging assignment. First question: whether to use HTTP auth at the transport level, or WS-Security at the message level. Decision: use HTTP auth. It is simpler, mature and widely supported, and meets our current needs well.


Given the four types of HTTP auth:



which should we use?


We're using HTTP/SSL as the transport since sipXconfig data is the customer's private information and should be protected on the wire. So HTTP Digest auth offers no advantages over HTTP Basic. HTTPS Client auth, a.k.a. "client certificate authentication" has the extra security afforded by PKI integration, as well as extra complexity. Form-Based auth is interactive and therefore not suitable for web services.


Decision: start with HTTP Basic and support HTTPS Client later.


Implementing HTTP Basic authentication with Jetty

Jetty, the web container used by sipXconfig, is a great open source product, but the documentation is a bit scanty.


Step 1: Add security-related deployment descriptors to web.xml:



<security-constraint>
<web-resource-collection>
<web-resource-name>SipXconfig Web Services</web-resource-name>
<url-pattern>/services/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>

<!-- Use HTTP Basic authentication. -->
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>jetty realm</realm-name>
</login-config>

<security-role>
<role-name>admin</role-name>
</security-role>

BEA has a good explanation of what goes in web.xml. Briefly,


Step 2: Now how do we change the sipXconfig Java code to make the web application support this properly? Turns out that this is completely web container-dependent, sad to say, and the Jetty documentation offers little advice. By talking to my friend Damian, grepping around the Jetty distribution, and looking at the sipXconfig 2.8 code, I figured it out.


You have to create a class that implements the UserRealm interface and add it to your Jetty Server, as in the following new line in the sipXconfig JettyTestSetup class:



m_server.addWebApplication("/sipxconfig", war);
m_server.addRealm(new JettyUserRealm());
m_server.start();

Here JettyUserRealm is that class. If you now run sipXconfig in test mode and browse to the web services URL, http://localhost:9999/sipxconfig/services, the browser will prompt you to log in. Of course, this is just for testing, real use of the web services API is from a client application, not a user through a browser. The JettyUserRealm test class is just a dummy implementation, real authentication via the password tokens stored in the database is the next step in our plan.



Powered by Blogger