Michael Tokar

Calling all author/developers

Michael Tokar talks about Atlassian
March 5, 2009 3:04 PM

As an Atlassian community developer, do you have some valuable hints for other developers? Have you been frustrated because you could dramatically improve a page in the Atlassian documentation with one quick change or addition? Have you contributed copious comments to the documentation, and wondered when the technical writers will ever get round to incorporating them into the page?

Now's your chance! We're inviting community developers to contribute to the Atlassian documentation. Details are on the Atlassian News blog.

Michael Tokar

As you may recall, in March this year, Atlassian publically announced the commencement of the 20% Time Experiment. Since then, we have been keeping you up to date how it works, and what people have been doing.

Dmitry Baranovskiy, a Developer on the Confluence team, has been spending his 20% time on a JavaScript library for creating vector graphics. In August, Dmitry released Raphaël -- the first 20% project unrelated to an Atlassian product to be released to the public. At the 2008 Web Directions South conference held last week in Sydney, Dmitry delivered a presentation, related to his work, and was interviewed by SitePoint's Andrew Tetlaw on the beginnings and details of the library.

Here's an excerpt from the article:

SitePoint: Right, I thought my first question should be: why did you write Raphaël? What inspired you to write it?

I was doing a FedEx project. Internally at Atlassian, we have FedEx Days when you are given the time to present a project you've been working on. [...] So I thought I'd do something the programmers might not know anything about, and because I've had experience with SVG before, it made sense to work with SVG. But, as a front end developer, I'm concerned about creating something that only works in Firefox, so I wanted to create a bridge for VML on IE. My original project was to create a charting application, like a simple line chart. I quickly knocked it up in a day and a half from scratch, showed it, but it didn't win anything. It didn't impress people.

SP: Not even a little bit?

Oh, maybe a little bit, but not in general. So I left it for a while. Then we started our 20% projects (just like Google). I decided to pick up this project and extend it a little bit. I got rid of the charting part and turned it into a generic drawing library. Just a bridge between SVG and VML to enable me to do more cool stuff without worrying about browser compatibility.

So at the next FedEx Day, I used this library to create a Skitch-like application. You could take a picture and add things like arrows and ellipses. It even saved the image, but obviously that's not the hardest part.

Then I started working more on this 20% project. To be honest, I spent more than one day a week: I worked with my laptop on the train -- one hour to work and one hour back -- two days a week in general, for about a month. Then I decided that it was good enough to release, because it's better to do so before another developer releases the same thing. So, I released it in the middle of August.

I was stunned by the feedback. I didn't expect it, to be honest, because I wrote about it on my blog and I usually get about 20 hits per day; but after it was released and made it to the front page of Delicious and Reddit, I got about 8,000 hits per day. It chewed through my bandwidth and I had to create a new domain. It actually started costing me money!

To find out more about technical challenges Dmitry faced, like cross-browser compatibility, you can read the full interview. And if you're super keen, you can also follow Dmitry's personal blog to get the latest on what he's up to.

I expect that as 20% time continues to give our developers an outlet for innovation outside of the realm of Atlassian's existing products, more projects like Raphaël will make their way into the wild. As a relatively young Atlassian, this excites me greatly, as it's yet another reminder of how cool this place is to work at, and gives me instant bragging rights in any tech-related conversations that could occur in a social context (believe me, it happens!). Stay tuned for more updates!

Michael Tokar

Beware of Hash Cookies

Michael Tokar talks about JIRA
April 2, 2008 12:57 AM

During my latest stint as the JIRA Developer on Support, I came across an issue where a customer reported that the Remember Me functionality of JIRA wasn't working - but only for some users. In his instance, he had two users: wmlalai and lagonil - for now, let's call them B1 and B2. For B1, the Remember Me functionality worked as expected; for B2, not so.


Curious to the cause of this problem, I loaded up the customer's data in a local instance, and sure enough I was able to reproduce it. Monitoring the cookies within the browser to make sure they were being saved correctly, I noticed that upon the first login, the cookie was present in the browser for both users. When I closed the browser and restarted it, the cookie again was still there. But, when I navigated to JIRA, B2's cookie was being deleted. This was accompanied by an exception in JIRA's logs:


2008-03-07 15:46:32,470 http-8090-Processor2 DEBUG [atlassian.seraph.cookie.EncryptedCookieEncoder] Invalid password cookie submitted, trying insecure
java.lang.RuntimeException: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher
at com.atlassian.seraph.util.EncryptionUtils.decrypt(EncryptionUtils.java:77)
at com.atlassian.seraph.cookie.EncryptedCookieEncoder.decodePasswordCookie(EncryptedCookieEncoder.java:43)
at com.atlassian.seraph.auth.DefaultAuthenticator.decodeCookie(DefaultAuthenticator.java:393)
at com.atlassian.seraph.auth.DefaultAuthenticator.getUserFromCookie(DefaultAuthenticator.java:245)
at com.atlassian.seraph.auth.DefaultAuthenticator.getUser(DefaultAuthenticator.java:221)


Why would the cookie be the wrong length? I set a breakpoint in the DefaultAuthenticator.getUserFromCookie() method in Seraph, where the cookie is retrieved and decoded. When attempting to log in with B2, I observed the following value for the seraph.os.cookie:

lLaNPRBsPajwpMtCaoXPpImn


as compared to the actual value stored in the cookie in the browser:

lLaNPRBsPajwpMtCaoXPpImn>Ca7ic

i.e., when retrieving the cookie value from the request, it was being truncated at the '>' character.


Who stole (part of) the cookie from the cookie jar? I sniffed the network traffic to ensure the browser was sending the full value, and it was, so this led me to believe that the application server was the fiend. After a bit of searching, I found that others had been the victim of Tomcat's cruel appetite. What confused me more was Apache's response:

That is because those characters are illegal in version 0 cookies (as per the spec). You need to use version 1 cookies.

I had read the specs they were referring to: "Version 0" and "Version 1", and neither made mention of illegal characters in cookie values other than semi-colon, comma and whitespace. Regardless, I tried their suggested solution of switching to "Version 1" cookies (by using the setVersion() method on the Cookie object when constructing it), and it did work. Note however that, when I tested the issue on Orion and Resin, they did not experience this problem, even though the cookies did have the "illegal" characters in them, AND the Cookie objects were "Version 0". Go figure.


Why do we use these characters in our cookies anyway? Interestingly, this problem only appeared after the release of JIRA 3.12, when updates were made to Seraph code to increase the security of the seraph.os.cookie, by taking the hash of the username and password and encrypting it a little. And sometimes, this hash happens to contain those characters. What's cool is that it seems to be reproducible, so if you fire up your own instance of JIRA running on Tomcat, and create a user named lagonil, you should get the same problem. We're hoping to resolve this issue very soon; you can track it here.


So let that be a lesson to you, kids - if you're ever going to use hash cookies, make sure you know what's in them!

Michael Tokar

As part of the upcoming 3.12 release of JIRA and 2.7 release of Confluence, a neat little feature will be added that allows the two applications to communicate in a trusted way, such that it is possible for Confluence to request information from JIRA on behalf of the currently logged-in user, but without having to re-authenticate the user on the JIRA end. Sounds intriguing? Read on!

The Problem

Confluence has a nifty macro called the JIRA Issues Macro that allows users to embed issues into a page straight from JIRA. While the macro works well, it is not entirely secure as you have to store JIRA user credentials right there in the macro. The reasons we require the user credentials are clear. Firstly, your JIRA instance might not be public, and enabling an anonymous account to access your issues is not an option. Secondly, you might have security restrictions on your issues, and so you don't want to allow someone to leak issue data from your "Top Secret" project by using the JIRA Issues Macro.

The Solution

(click for more...)

Continue reading " Trusted communication between JIRA and Confluence" »