New authentication system was a success

Ever since redesigning the authentication system, the registrations has increased to a hundred percent of those who entered a URL to claim.

Previously, the users had to really struggle to understand how to proceed. (Probably because users generally reject to read instructions. If there's a button, they just press it without reading what it really entails.)

So, great!

Retrospective on bugs

Faults are bound to happen, as bugs are bound to be introduced. Developing MyFlickr involves modern techniques for preventing bugs such as TDD, but I want a better way to prevent issues in the long run.

A simple and powerful main strategy for handling bugs is a process that evolves to prevent bugs of a similar kind to reccur. Just fixing a bug kan be harmful in that it stops the process from evolving to limit future opportunities for similar bugs to get introduced. The development and maintenance process should periodically or continuously evaluate the root causes of the problems so far.

So, to start with MyFlickr
MyFlickr has had four faults so far that has impacted live usage:

• 3pp library using non-thread safe XmlParser having an object re-use check causing sporadic race-conditions; (Fixed with patch for the library)
  
• Null-pointer exception when saving site settings with no prior custom CSS setting.
• Problems when registering towards Flickr because authentication tokens where not reset for unregistered users. Could have been handled by 3PP, incorrectly assumed to be so.
• 
  

XXX users get bad error message

XXX users would probably like a record of problems.
XXX issue tracking should be used to record problems that have occured.
XXX alarm log file

Temporary Google index drop-out

Strangely enough, MyFlickr.org temporarily disappeared completely from the Google index. Traffic, which was at a steady low level dropped to nothing and exact phrases from the site was not to be found in the index.

I can only keep wondering whether Myflickr was banned for mentioning too many buzzwords on one single page with no images, or because myflickr has an infinite number of sub domains, or something else? Anyways, to the search robots, myflickr no longer has an inifinte number of sub domains, since the robots.txt now forbid the robots to access unregistered sub domains.

Which brings us to development. Nothing fancy has happened with the code, other than polishing and minor improvements here and there. Also, the server (a quad core, quad scsi disk, dual power compaq server) has surpassed an uptime of 100 days again. I used to reboot it once in a while for some reasons, but there is no problems with it whatsoever.

Better Flickr authentication procedure

Enhacement
Today, a new authentication system is released!
Even though the way of authentication was clearly stated everyone that tried failed to use the authentication system. That's a very good proof of a non intuitive system so the authentication modules have been rewritten to work in a more intuitive way. Now the user just have to click a button on his site, answer yes at Flickr.com and that's it!

Technical details
Flickr's login system is limited in that it provides no context when authenticating in the Web mode. Clearly, this is OK for most Flickr applications with a single URL, but since myFlickr authenticates from many different URL:s there's a big problem. MyFlickr now hosts a new server at service.myflick.org which the user gets redirected to after authenticating with Flickr, but since Flickr doesn't provide any hint as to what session the user had with MyFlickr before authenticating, this has to be saved in a cookie in the browser. Since cookies can't be used across domains, the user has to be redirected to service.myflickr.org before being redirected again to Flickr.com. That's many redirects but the user sees only the question on his URL to start the process and the question on Flickr.com to authenticate.

Here's what happens when a user authenticates
The solution is not super elegant but works seamlessly when cookies are enabled, and doesn't require any state at all on the servers. If cookies are disabled, the user has to fill in the server address one extra time.

1. The user visits user.myflickr.org, which presents a start button
2. When the user clicks the start button, user.myflickr.org replies with a redirect to service.myflickr.org/?next=user.myflickr.org
3. The user gets the page at service.myflickr.org which saves user.myflickr.org in a cookie in the browser and redirect to Flickr.com to authenticate with the MyFlickr application
4. The user's browser saves the cookie and goes to Flickr.com where he can decide to authenticate with MyFlickr.
5. If the user accepts MyFlickr to get permission to the user's photos, Flickr redirects the user to a URL which is configured in MyFlickr's API preferences together with a "frob". The Frob is a string that MyFlickr must use to get the user's security token.
6. The User's browser goes to service.myflickr.org. Now with the frob from Flickr in the request URL, and hopefully with a cookie with the address of the album he is trying to authenticate with. (As created in step 3)
7. If the server at service.myflickr.org gets the cookie, it can redirect the user together with the frob to the authenticating server, otherwise the server has to ask the user to fill in a form and provide this information again. This is where Flickr.com has severe limitations in the API. (see below)
8. The user's browser gets redirected back to the domain he tried to claim or authenticate with, together with a frob in the address.
9. When MyFlickr at the proper address gets the user back with the frob, it sends the frob back to flickr and shold get the user's security token back. The security token can finally together with MyFlickr's secret keys be used to access the user's photos.
10. The user configures his site which goes live immediately!

It's a complex procedure with four redirects, but it looks simple to the user. So nothing can possibly go wrong! ;)



Technorati Tags: flickr, authentication, programming

Strange problem in Wicket

Here's a fun bug in Wicket I stumbled on while implementing a new way to authenticate the user which is much easier to understand.

This is a page to resolve the intended authentication target URL when the authenticating user is blocking Cookies.
The application has mounted a page at AuthService, which may set a resolve page as render page. When using WebPage.setResponsePage() from on override of prepareForRender(), the returned content is exactly two HTML pages.

When moving the call to setResponsePage into the constructor of the original page, the problem is solved in the browswer, but nothing in the WicketTester works.

Custom CSS

New features

• Added custom CSS;
• Added possibility to hide from robots (search engines) with robots.txt.

Now you can customize the CSS for your site to customize it completely.
If you don't want your site searchable you can edit the preferences to hide your site from robots. This means that your site will be ignored by search engines such as Google.

Fixed bug in FlickrJ

Bug Fix in library
There is a known bug in FlickrJ, which is a library that MyFlickr uses to communicate with Flickr. Basically, the bug appears when two threads tries to parse a Flickr XML response at the same time.
This happened quite often for MyFlickr, probably more than other users since MyFlickr is hosted on a quad-cpu server with slow cpu:s.

The bug has been fixed for myflickr and a patch has been submitted to the flickrj group at sourceforge.


Feature improvement

• Improved traceability for Google Analytics, by adding user segments and virtual page names for redirected pages. This means that the statistics will make sense even for interactive pages.
• Removed known exceptions from application log.
• Minor improvements to download page.