Play.com crappy security policy

We're in 2009 and we still have web merchants able to resend you your exact password if you have forgotten it. I just tested this with Play.com a UK sells it all web site (no link to them sorry. Bad boys!) which I just used to purchase "Amazing Grace" (nice movie BTW).

Hey guys, if you don't fix this, I won't place an order again with you.

Because if I you treat my password like other data I gave you (in particular my credit card details), I can't give you my money.

Can't you do the right thing ? Some tips (at a minimum):

• store the hash of the password
  
• salt it
  
• compare salted password hashes !
  
• regenerate a new password randomly if the user has lost his password
  

Why ? Because someone (a cracker or a disgruntled employee) could fetch the customer / passwords list and as most people don't have a new password per site, use it to not only make purchases on play.com, but to access all other accounts, up to probably the customer's mail box. And from there access all his accounts.

Note to self: always test the "send me my password" function on any new web site I use.

Update: at least some other sites know what they are doing

nose, subversion and executable bits

For some reason, nose wasn't executing some of my tests. I found out that nose doesn't select test files if they have an executable bit, and that subversion was configured to create the files with the executable bit. That's a bit unfortunate as I want some python files to be executable, other not. I guess I will let them non executable by default. Worklog below

Britain apologies to Alan Turing

The official site of the UK Prime Minister's office just published Gordon Brown's apologies to Alan Turing.

Kind of them to finally recognize the contribution and inhumane treatment of this great man without who I might not have worked in IT (and might speak German as well).

Thanks Alan.

And when I think about the changes in the society in the past 60 years, I can't help to feel lucky, happy, and somewhat scared that this could regress pretty quickly... We've still a long road ahead though.

Software commit guidelines and tips

Having and following good commit guidelines is critical to ensure you're not doing cowboy coding. Here are my guidelines. I will update them as time goes. Feel free to comment.

Tips for autodeploying J2EE apps on Unix platforms

With a little bit of configuration you can have a nice autodeployment setup to save you time and remove potential errors.

For example this is something I can usually do after spending a few hours on the development infrastructure:

# from the build server, deploy the latest build for the specified project onto the 3 dev servers
deploy_build projectName trunk latest dev1 dev2 dev3

# deploy specified build for specified project
deploy_build projectName trunk build65 dev4

# deploy latest branch 2.0 onto specified server
deploy_build projectName 2.0 latest dev5

Also with a little bit more glue code those same commands can be run through your CI server interface, allowing one click deployment from the CI server GUI.

This is one way of achieving it, using standard Unix tools.

Python and testing

Here's a list of links I've found when building my python testing knowledge, categorized under Unit testing, Mocks, Articles, Web testing, Google App Engine and Code Coverage.

Hudson, maven and git on eapps.com VPS

VPS hosting from eapps.com is a reasonable compromise between cost and hosting service quality. I use it to host a hudson CI server.

This entry explains how I set it up up to a point where I can build using maven a java project hosted on a ssh protected git repository (on github). I will not go into the hudson specific stuff, the hudson wiki is usually complete & well worded. But I will spend more time on the OS specific stuff such as daemon configuration, ssh specifics, etc...