Tag: java

Categories
computer

AmericanExpress.com: Tip On Configuring Your Web App

For all you web application developers, I’d like to briefly note the following stack trace I received from the American Express website while clicking around:

And here is the same trace in plain-text format:

JSPG0036E: Failed to find resource /cardcenter/common/interstitial.jsp

Root Cause:

java.io.FileNotFoundException: JSPG0036E: Failed to find resource /cardcenter/common/interstitial.jsp
	at com.ibm.ws.jsp.webcontainerext.AbstractJSPExtensionProcessor.findWrapper(AbstractJSPExtensionProcessor.java:322)
	at com.ibm.ws.jsp.webcontainerext.AbstractJSPExtensionProcessor.handleRequest(AbstractJSPExtensionProcessor.java:284)
	at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3548)
	at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:269)
	at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:818)
	at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1478)
	at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:126)
	at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:458)
	at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:387)
	at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:102)
	at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
	at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
	at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
	at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
	at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:196)
	at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:751)
	at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:881)
	at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1497)

Most developers might say, “So what? You just clicked on a broken link somewhere. Go back and go about your business.”

And that’s exactly what I did, since I just wanted to pay a credit card bill. But what if “my business” had been to gather forensic information about potential American Express website vulnerabilities? A stack trace may look innocuous, but we can be almost certain that this HTTP request was handled by a Java servlet. It uses Java Server Pages (JSPs) for view templating, and the application appears to be running on IBM WebSphere. Not only this, but we have line numbers for each stack frame, and the CSS appears to be some form of default styling.

Large institutions such as AmEx tend to not upgrade to the latest versions of development libraries until a future interal release cycle where the new version(s) can be internally vetted, tested, QA’d and put through a due diligence process. (Or for older apps, dependencies might not be upgraded at all.) This makes stack traces extremely valuable to an attacker. Why? Because I can obtain all historical versions of technologies such as WebSphere, and map every specific call in the stack trace back to the code until I find the software versions where the line numbers match up. The attacker should at least be able to narrow down the software version numbers to a range, if not the specific release version. After gathering this information, the attacker may choose to fixate on the older packages, and consult databases of vulnerabilities in legacy software until a vulnerability is discovered.

Long story short: turn off the rendering of stack traces in public-facing production applications. They’re convenient for validation of production errors, yes, but you don’t know what they may reveal.

Categories
Uncategorized

Spring 2011 ASU Webapp Course

In Spring 2011, the College of Technology and Innovation at the ASU Polytechnic campus will again be offering CST 533/494: Database-Centric Enterprise Application Development. The calendar is not yet out, but should soon be listed as a Thursday evening class: one night per week for the Spring semester. The course will be available at both undergraduate and graduate levels for 3 credit hours.
The course essentially teaches dynamic web application architecture concepts and development processes using Ruby (w/Rails), Java (w/Spring, Eclipse, and Tomcat), SQLite, MySQL, and other industry favorite technologies as a means to the learning process.
  • New technologists: If you’re looking for training and experience in this area, definitely check out the ASU Polytechnic campus.
  • Old hats: If you are an “old hat” software engineer just looking for the credit hours, this may provide a fun, project-oriented opportunity towards working on your degree.
  • Companies: I am always on the lookout for opportunities to expose students to industry perspectives. If you’re interested in any sort of corporate sponsorship or collaboration, please contact me directly.
Categories
Uncategorized

3D OSX Applications With Ruby-Processing Screencast

A two-part screencast series demonstating two different 3D ruby-processing applications. A slide presentation from 2009 created for the Phoenix Ruby Group is also attached as bonus material. Enjoy!

Part 1: Starfield

Demo of a 3D starfield simulation written in pure Ruby, running on the JRuby runtime as a nicely packaged .app program for Mac OS X. (Runs on Snow Leopard and Leopard.)

Part 2: Twiverse

3D Twitter client written in pure Ruby, running on the JRuby runtime as a nicely packaged .app program for Mac OS X. (Runs on Snow Leopard and Leopard.)

Slide Show

Writing 3D Applications Using ruby-processing

View more presentations from Preston Lee.
Categories
computer

What If Ruby Had Final Variables Like Java Or Erlang?

ruby

After a long confusing Ruby debate today at OpenRain on the merits of functional, Erlang-esque write-once-read-many variables, I’m going to step onto the podium and just say it… Ruby should get “final” or “const” variables in a similar semantic style to Java, except at runtime. Rather than ramble on for 12 paragraphs explaining exactly how this might work, read this fictitious Ruby code snippet instead. (Optional: Also check out the chapter on “final” in Hardcore Java.)

Final variables like this are really just an inline TDD mechanism.

Allowing local stack data to be constant provides no functional enhancements to the software, but alleviates the need for certain types of tests by using the compiler and/or runtime to assert certain memory is immutable. The “friend_best” method variant in the code snippet would obviously break most existing Ruby programs, but ups the bar for defensive programming by preventing many common bugs out-of-the-box while still providing support for traditional Ruby variables. At the very least we should have something like “friend_better”. Adding this information to the parse tree will also make it easier for IDEs to provide features more easily implemented for static languages.

TDD/BDD is in–no qualms about it–but we can make our code safer, cleaner and more concise by applying some of the lessons learned by our statically-typed language cousins over the last few decades.

Categories
computer

J2ME Acronym Cheat Sheet

l2_rockinduke.gif

Sometimes I think we’ll eventually run out of TLAs (three letter acronyms) in the Java space. Here’s a quick reference for the forgetful..

  • ABB (Audio Building Block)
  • API (Application Programming Interface)
  • BCC (Bluetooth Control Center)
  • BPWD (W3C Mobile Web Best Practices Working Group)
  • CBS (Cell Broadcast Service)
  • CDC (Connect Device Configuration)
  • CLDC (Connected, Limited Device Configuration)
  • CSS (Cascading Style Shee)
  • CSS-MP (Cascading Style Sheet – Mobile Profile)
  • DDC (Default Delivery Context)
  • GCF (Generic Connection Framework)
  • J2ME/JME (Java Micro Edition)
  • JTWI (Java Technology for the Wireless Industry)
  • JMF (Java Media Framework)
  • JSR (Java Specification Request)
  • JVM (Java Virtual Machine)
  • MMAPI (Mobile Media API)
  • OBEX (Object Exchange Protocol)
  • OMA (Open Mobile Alliance)
  • PAN (Personal Area Network)
  • PDA (Personal Digital Assistant)
  • PDAP (PDA Profile)
  • PIM (Personal Information Management)
  • MIDP (Mobile Information Device Profile)
  • MMS (Multimedia Message Service)
  • SMS (Short Message Service)
  • SDD (Service Discovery Database)
  • UAP (User Agent Profile)
  • WAP (Wireless Application Protocol)
  • WCSS (Wireless Cascading Style Sheet)
  • WMA (Wireless Messaging API)
  • WML (Wireless Markup Languge)
  • WTK (The Sun Java Wireless Toolkit/J2ME Wireless Toolkit)
  • XHTML-MP (XHTML Mobile Profile)
Categories
computer

JXTA: Not The Solution To Java Peer Discovery

sun_jxta.gifOnly developers with hair should use JXTA, because those with bald or shaven heads won’t have anything to violently rip from their skulls while they develop with it. I have been, and continue to be excited by, JXTA’s potential, but have been very disappointed at the pace at which a project progresses when using it. JXTA’s capabilities, on the PowerPoint level, are impressive. It facilitates a great deal of networking features necessary for peer-to-peer operation and service discovery. So what’s my beef? A couple major areas off the top o’ me head..

Documentation

There isn’t exactly a massive community using JXTA. There are limitless possibilities of the platform and a few significant projects that use it, but it’s not exactly a common-place technology. That’s ok. Communities need time to grow. But to build a better mousetrap, people must understand why yours is better, and how to use it properly. At first I suspected I had jumped into the system at a particularly odd moment, but most of the documentation I’ve read is either out of date, or, in the case of much of the code itself, completely missing. This may come as a surprise to the good folks at jxta.org who provide many links to JXTA articles, but as a developer new to the platform sitting down and getting started, you’ll find yourself confused by deprecated and changed APIs without a clear understanding of the Right Way to do things. The – popular – books – are – long – outdated.

Testing

As an advocate of test-driven development, my application unit tests attempt to cover the interactions between multiple peers on the JXTA network. Doing so requires instantiating multiple cores within the same Java unit test process, and being able to reset them to initial states between test cases. Unfortunately, JXTA is designed as a singleton, which as we already know is not a friendly pattern to test-driven development. Couple this unfortunate design with the general difficulties of multi-threaded unit testing, and you’ll either be spending vast amount of time with your unit tests, or forgoing the complicated ones completely. Probably the latter. So what’s the solution? I’m not exactly sure, but I’ve started working on one.

Journeta

Currently code named “Journeta”, that goal is to create a greatly simplified, zero-configuration-required peer discovery and communication Java library for “trusted” networks. No configuration files, hefty learning curve or even constructor arguments, but no security or over-the-internet functionality either. (At least at the library level.) While I haven’t been actively developing it this year, I started the project last year over at OpenRain, and anticipate releasing a build sometime this summer. Let me know if you’re interested and I’ll ping you when we release a demo.