treatment method commenced. Usually overcoming impotence supplies adult men african mango West african mango extract

Published January 6th, 2010 by Jim O'Halloran

Red5 and Apache Axis web serviuce client crashes

First post in a very long time, but I justwanted to document for the world something I’ve ran into and was stumped by for a while.  The solution isn’t documented anywhere specifically regarding Red5 and unless you’re familiar with the Apache Commons probably isn’t obvious.

I’m developing a small Red5 application which allows users of a web site t stream video directly from their webcam to the server where it’ll be stored and played back later.  My problems began when I wanted to allow only authenticated users to store and playback video, but wanted to keep thatlogic in my PHP application (which is the primary user intrace) rather than the Java code of the Red5 application.  No problems, I thought, I’ll justuse a SOAP web service and have my Java code call the PHP for authentication.

I built a WSDL file and implemented a Proof of Concept soap server in PHP, then I went through the Web Service Client wizard in Eclipse to generate the necessary Java proxy classes.  However, whenever I tried to instantiate the locator classthe system would throw an Exception at runtile as follows:

 Caused by: org.apache.commons.discovery.DiscoveryException: Class org.apache.commons.logging.impl.SLF4JLogFactory does not implement org.apache.commons.logging.LogFactory
    at org.apache.commons.discovery.tools.ClassUtils.verifyAncestory(ClassUtils.java:180)
    at org.apache.commons.discovery.tools.SPInterface.verifyAncestory(SPInterface.java:201)
    at org.apache.commons.discovery.tools.SPInterface.newInstance(SPInterface.java:195)
    at org.apache.commons.discovery.tools.DiscoverClass.newInstance(DiscoverClass.java:579)
    at org.apache.commons.discovery.tools.DiscoverSingleton.find(DiscoverSingleton.java:418)
    at org.apache.commons.discovery.tools.DiscoverSingleton.find(DiscoverSingleton.java:378)
    at org.apache.axis.components.logger.LogFactory$1.run(LogFactory.java:45)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.apache.axis.components.logger.LogFactory.getLogFactory(LogFactory.java:41)
    at org.apache.axis.components.logger.LogFactory.<clinit>(LogFactory.java:33)
    ... 51 more

What’s happened here is that the LogFactory class provided by theRed5 runtime and that provided in the commons-logging.jar added to your project by the Web Service Client wizard are different versions (see this Apache.org page for more info).  The linked page goes intosome detail as to how you can fix that with configuration, but being somewhat of a Java n00b, I went for the brute force approach.

My fix is to delete (through Eclipse so it doesn’t come back upon deplayment) the commons-logging.jar file from the project.  You fine it under “WebContent/WEB-INF/lib” in your project.  Right click on “commons-logging.jar” and delete the file.  I’m not sure why this works, but it seems to force Apache Commons to use the logging classes within Red, and everything seems to work with no adverse consequences.  There are probably better solutions, but that’s mine!

Published October 24th, 2007 by Jim O'Halloran

Building a Complete CodeIgniter Application: Part 3

I left you at the end of part 2 with the news that there was a large security hole in the work we’d done so far. Readers who’ve done a bit of web development in the past should recognise the vulnerability as cross site scripting (XSS) and might understand the problems XSS can create. In this part I want to discuss some common security problems, and the steps we need to take to eliminate those.

Understand that security is not a product but a process. We can’t buy security, we can’t develop our code and “bolt on” some security later. Effective security needs to be built into the product/project from the time it’s first written, and ongoing care and attention needs to be paid to making sure that every new line of code doesn’t compromise our security in some way. If you need evidence of that, there’s any number of Open Source CMS or forum products out there which were put together and released, and have struggled for many many releases (often with little success) to properly secure themselves against attack. Security in the applications we write is the result of education, awareness, care and attention to detail in every piece of code we write, secure code should be the result of the process we use to write our code, not an afterthought.

In the first two parts I’ve done a couple of things already which were security related, so lets first loop back and explain what we did and why. Then settle in while I explain cross site scripting (XSS) and we look at the HTML Purifier tool then apply it to the problem at hand. Finally I’ll talk about handling user logins and secure storage of passwords. Continue reading ‘Building a Complete CodeIgniter Application: Part 3′

Published October 18th, 2007 by Jim O'Halloran

links for 2007-10-17

Published October 12th, 2007 by Jim O'Halloran

links for 2007-10-11

Published October 5th, 2007 by Jim O'Halloran

links for 2007-10-04

Published October 4th, 2007 by Jim O'Halloran

links for 2007-10-03

Published October 2nd, 2007 by Jim O'Halloran

links for 2007-10-01

Published September 30th, 2007 by Jim O'Halloran

links for 2007-09-29

Published September 29th, 2007 by Jim O'Halloran

links for 2007-09-28

Published September 27th, 2007 by Jim O'Halloran

links for 2007-09-26