eclipse luna

Main menu:

Topics

Recent Posts

Blog

July 2014
M T W T F S S
« Jun    
 123456
78910111213
14151617181920
21222324252627
28293031  

Past Posts

Java/Java EE

JDBC

Other

eclipse luna

July 1st, 2014 by Jeanne Boyarsky

When I went to eclipse.org, I wasn’t greeted the cool Kepler book from last year. I did see “are you ready for Java 8″ front and center. The matrix comparing the packages is still clear. I chose the Java EE version. The download page had a warning that “Eclipse requires Mac OS X 10.5 (Leopard) or greater.” No problem. I’m on the latest version. I’m also on the latest version of Java 8.

Initial launch

When launching my workspace, I got the warning:

Warning: Workspace ‘/myWorkspace’ was written with an older version of the product and will be updated. Updating the workspace can make it incompatible with older versions of the product. Are you sure you want to continue with this workspace.

Which is fine. I’m not going backward. And all the important code is in Subversion or Git anyway. The “Failed to load the JNI shared library” error I got with Kepler is fixed. To be fair, it was fixed in Kepler SR 1, but I never upgraded. It’s nice to be able to launch Eclipse through the icon again though.

Installing the plugins

Like last year, I decided to install the plugins I need for Eclipse Marketplace so I can shed the plugins I tried out and don’t actually want. Cleaning plugin house once a year is nice. The biggest plugin I wanted to shed was the old experimental FIRST robotics plugin. It was never intended for Kepler. I installed it last month to write a presentation.

The significant plugins I use are listed in this table. A number of plugins were beta for Luna or I had to use the Kepler version. I don’t remember that problem in previous years.

Plugin Purpose
Mongrel Tomcat integration supporting Tomcat 7.  (The version of Sysdeo I was using seems to have had that too but at least Mongrel looks more active.) It looks like they used the Sysdeo source code and forked it since Sysdeo isn’t getting updates anymore.Last year, I tried Mongrel and fell back to Sysdeo. This year, Mongrel stuck. I’m happy with it.
Ecl Emma Code coverage
PMD and FindBugs Static analysis. For PMD, I had to use the update site. An install “happened” through Eclipse Marketplace, but I didn’t any of the PMD settings I was expecting. Using the update site gave me what I expected
Subversive To access Subversion repositories
Groovy/Grails Tool Suite (didn’t install) Groovy project/editor and console. At this time only the Kepler version is available which conflicts with other plugins I’ve installed. I’ll use the command line (or fall back to Kepler) for the time being
Eclipse Memory Analyzer For finding memory leaks. Last year this was only available via an update site. Now it is in Eclipse Marketplace.
Freemarker IDE Freemarker syntax highlighting and macro assistance.  Note that it is listed under the JBoss Tool Project. You pick that plugin and then unselect everything except “Freemarker IDE”
Python Python plugin/perspective (had to download one for Eclipse 3.6)
Code Recommenders I think this one is new for Luna. It’s supposed to be better than autocomplete. So far it is a nice toy. I do like that it prompts you when you use autocomplete to make it the default, enable subword matches, etc. Making it easy to see what is going on.

I have faster internet (FIOS) since last year so the downloading was faster. However, finding the right plugins took longer this time. And I still find it odd that Git is included and Subversion is not. Licenses I guess.

What excites me

  1. Java 8 support! This blog post shows the quick fixes and the like that are available. They did a really good job. The integration is very intuitive and “just works”
  2. eGit has come a long way. It even supports cherry picking now. I think I’ll still mostly use command line, but it is nice to have a visual option.
  3. Drag and drop to change order of the list of perspectives in the toolbar.

What frustrates me

  1. Nothing. I’m really happy with Luna

how to use cells as tab name variables in excel

June 19th, 2014 by Jeanne Boyarsky

I have a co-worker who is an Excel wizard. He set up a system for automatically gathering data using references to other tables. I’ve learned a lot from him like how to use lookup tables, filters, reference other files, etc. Microsoft lists out the syntax for referring to other sheets.

There was one one instance where we needed the tab name to vary based on another cell. We’ve been doing this by hand each time we add a new tab. It’s not hard, but it is boring and tedious. Being a good computer programmer, I want the computer to do tedious for me. The problem is that it doesn’t take long enough to update it by hand so I can never justify looking into it.

I recently installed Office on my Windows 8 VM because I needed to see how something looked in real Word. (vs Open Office.) Since I now have Excel, I decided to try it out. I got it working much faster than I thought.

Just like programming, I did iterations to build up to it.

Iteration 1 – sum another tab

I created file1.xlsx with two tabs: tab1 and tab2. In each, I added some numbers to the first column of each. I then wrote the formula to add them up:

=SUM([file1.xlsx]tab1!$A:$A)

Explaining what this means:

  • [file1.xlsx] – refer to another file
  • tab1 – refer to this tab in that file
  • !$A;$A – all columns in column A. The $ means to always use column A even if I copy paste the formula into multiple rows.

Iteration 2 – try to use a formula based on a String

=SUM(INDIRECT(“[file1.xlsx]tab1!$A:$A”))

  • INDIRECT – the indirect function lets you pass text to refer to an Excel reference

Iteration 3 - append strings to build the expression

=SUM(INDIRECT(“[file1.xlsx]tab”& A3 &”!$A:$A”))

  • & – concatenate strings

fixing JForum XSS error in PM module with quotes

May 24th, 2014 by Jeanne Boyarsky

A member reported a XSS vulnerability in stock JForum 2.1.9. We confirmed it was a vulnerability/exposure on CodeRanch as well and fixed our fork. Luckily, it was an easy fix unlike the CSRF problems last year.

In addition to saying how to fix the issue in this post, I’m going to outline some of the other techniques JForum uses to defeat XSS.  For the actual (two character) fix, scroll down to “the fix.”

What is XSS?

XSS (Cross site scripting) is a security attack. OWASP describes in well on their XSS page. In brief, XSS injects code into a web page that runs on the target computer. The injected script code can do anything that the web page can do. Which means it can use JavaScript to steal your cookies, mount other attacks, etc. Scary stuff!

  • Reflected XSS – A reflected XSS attack targets specific users but is not stored in the database of the server with the issue. You might see a reflected XSS attack if you click on a link that takes you to the page. Others going to the page normally wouldn’t see the issue.
  • Persistent XSS – A persistent XSS attack gets the attack code stored in the database of the server with the issue. It could still target a specific user (in the case of the private message issue reported here.) Or it could target all users – even non logged in users – if the same attack was made in a post instead of a private message.  I was able to reproduce this problem in posts as well.

Both types of XSS attack are bad and up to the website to prevent. So how does Jforum 2.1.X protect against XSS attacks?

Approach #1 – Use Freemarker HTML escape sequence

JForum uses Freemarker as the view technology. Freemarker allows you to specify that all HTML should be escaped. This means attacks that reply on outputting HTML characters like < (tags) or ” (attributes) will be prevented.  Instead the raw characters of &lt; and &quot; will be output instead. Which the browser will not run. As an example of this technique, the code writes:


${post.subject?default("")?html}

Approach #2 – Escape characters in Java

Approach #1 is very powerful, but it has a limitation. Forum posts typically contain HTML code. For example, you write code in a special format, bold posts, etc. JForum uses Java code to do a search and replace on the special characters in text before adding the HTML formatting. Since the Freemarker view has to be able to render the HTML formatting, it can’t use approach #1. See an example of just one of these transformations:

ViewCommon.replaceAll(text, "<", "&lt;");

This approach is not foolproof because it relies on a blacklist of “not allowed” characters and hackers are creative. But it is really hard to come up with a whitelist of allowed characters in forum posts. And worse, the characters used in attacks are ones that are used in normal writing.

Approach #3 – Limit raw HTML

While JForum does allow HTML in posts, it only allows a limited set of tags and attributes. This one does use a whitelist with code like:


private static Set welcomeTags;

private static Set welcomeAttributes;

Approach #4 – Use BB code instead of HTML

The forum also allows use of BB (bulletin board) codes. This lets you write [b] instead of <b>. If the user isn’t entering HTML, the chance of a problem is lower.

The actual problem here

The XSS vulnerability reported was caused by the interaction between approach #2 and approach #4.

Approach #2 guarantees the quotes are safe with


ViewCommon.replaceAll(tmp, "\"", "&quot;");

Approach #4 contains the following BB mapping code in bb_config.xml


<!-- COLOR -->

<match name="color" removeQuotes="true">

<regex>(?s)(?i)\[color=['"]?(.*?[^'"])['"]?\](.*?)\[/color\]</regex>

<replace>

<![CDATA[

<font color='$1'>$2</font>

]]>

</replace>

</match>

This is a problem because the replace uses single quotes instead of double quotes. The system doesn’t escape single quotes. Allowing all manners of code to be injected in the color attribute.

The fix

Luckily, there is an easy fix. Just change this one line of code in bb_config.xml to:


<font color="$1">$2</font>

I’ve tested and this does in fact solve the problem.

For more learning about XSS

If you want to learn more about XSS, I recommend reading the OWASP cheat sheet.  In particular, notice that you need to escape the code differently depending on whether you are looking at HTML or JavaScript injection. In our case, it was HTML injection because the injection was occurring as a textual HTML attribute. If it was in <script> tag or JavaScript event handler, we’d need to call a JavaScript encoding library. Also, you can learn about DOM based XSS attacks.