Weird Bug in Chrome


I would like to tell a story about the newest thing I found related web development. We are currently building an integrated system for promotions and coupons related. The system consists of an Android client, a RESTFul API Server module, and a Content Management System (CMS) module. We use Jboss Wildfly 8 as our Application server, running on top the Java 8. We love Java 8’s functional capability, but I will save the details on the other post.

So the problem started after we are doing deployment into our production environment. Some users send bug reports about the problem in login process. After doing some thorough investigation, we found that we missed redirect tag used in Shiro authentication. Adding those missing tags,compiled new binary and done! Our modules are updated in production server.

Our users then perform their usual activities. The login problem apparently has been addressed with our latest fix, so we continued the development process. After a couple of minutes, a new bug report came in. And the bug is very weird. Some users using Google Chrome browser, experiencing some oddities interacting with our CMS. Several users report that they need to click submit button twice before they can login. The problem did not stop there, they said that our system kicked them out after just clicking some menu.

Our first approach is examining our server’s log, to find root cause of this problem. After doing some testing, we found that the server was performing just fine. Our authentication system responds in the correct manner. Based on our experiences, this could means one thing, the problem is on the client’s (browser) side. We then prepared several browser in different conditions, trying to reproduce the weird bug. After doing some tests, we find that only Google Chrome browser has this problem. Any other browser does not have this problem, which is weird, since Chrome has a good reputation related with web technology standards.

Since we have not experienced this problem before, we immediately went back into our first hunch, that the problem is mostly located in the server side. We did quick comparison our current production environment configuration with our development and staging environment, to find differences that could lead to this problem. We found that the only differences between our environment is that our production use nginx’s virtual host heavily. Again, this kind of approach deserves another blog post. So, we splitted our development team into two, the one with backend specialties will investigate our current nginx configuration, whilst our frontend gurus will perform debugging in the browser side.

This scenario was effective, our backend team can easily confirm that our nginx is not having any faulty configuration that cause that problem. So, we can put our focus into frontend debugging. As usual, some queries sent to Google leads us into several StackOverflows discussions, but nothing giving us clear answer about this problem. We fired up the firebug toolbar, and examined what interactions actually happens.

I have to admit, we approached this problem in not efficient way, since by using Firebug, we easily figured out why our user has to click Submit button twice. We found that Chrome is trying to load a favicon file, which does not exist in our newest build. We immediately put our favicon into assets folder and put appropriate code to load it. One engineer is curious and query google with favicon and login keyword leads into interesting StackOverflow discussion at http://stackoverflow.com/questions/8880592/chrome-and-jsessionid. We then went to that discussion in details and found an answer. Finally, somebody had a problem like us in the past and solved it!.

Apparently, Chrome and other WebKit-based browser use different approach in handling pages with redirect. Chrome creates two separate JSESSIONID cookies, first time is when our login form appeared, and one after successful login. Since the content of JSESSIONID has been updated, any further request marked as invalid and system forces user to login again. Following the lead, then we examined our code and put our favicon into proper place. We build new version, deployed them and the problem was gone.

This problem was hard and weird. We spent hours in confusion, but in the end of the day, we went home with new knowledge. This information will be very useful in the future, to help us build a better application.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s