Archive for December, 2007
December 28th, 2007
Makuchaku can dance as well…
Checkout the video… don’t concentrate too much on me as you’ll miss the best part - lol
Only one person was dancing on this stage, rest others were just doing aerobics 
– ISS Foot Lose Dance Auditions, IBM, 2007
Posted in Blog | Comments (3)
Whats up with ApnaBill.com
December 19th, 2007
In past few days I’ve seen some serious work going into ApnaBill project.
- Our marketing dude is back with us - my biggest problem (more personal than professional) got solved when he told me - “d00d, its good to be back!” - Dude, its more than good, to have _you_ back (more personally than professionally)!
- ApnaBill is now being developed under the expert guidance of our CEO
- Our designer is churning out some nice artwork! A helping hand on designing part was such a relief. This guy has some serious future ahead of him!
- Our paperwork (though a bit delayed) is on its way. We are just “_” this short of becoming a legal entity!
- My other half is picking up Rails faster than I picked it up - He’s almost finished a full module in just a matter of days!
- Above all, ApnaBill.com Open Beta Signup is nearing the magic 200 figure!
Before ending, something that keeps me on track…
When I can run, I will run,
When I can walk, I will walk,
When I can crawl, I will crawl.
But I will not stop moving forward!
These lines are obviously copied from someone’s signatures. I won’t deny that!
Posted in ApnaBill, Startups | Comments (4)
Avenger says SOS - Apache came to help!
December 18th, 2007
Moments after I crossed the Kalyani Nagar ICICI ATM on my bike - coming back home from office today evening - the bike suddenly felt very heavy & started to choke up! It felt as if fuel tank had emptied out. My Avenger has a big 15 litres petrol tank with 3 litres of reserve. I dragged the bike to the street light lit part of the road & tried moving the petrol knob to reserve… to my surprise & utter horror, it was already there!
Some a*s-h*le must have fiddled with my bike when its parked inside IBM. With even reserve finished, I had absolutely no petrol left in the tank. Dragging the bike to the nearest - 4kms away - petrol pump was the last thing on my mind! Asking an auto-wala was again out of question - going to Koregaon Park Petrol pump in the evening & coming back would have costed me atleast 100-150 bucks!
Calling on my roomy’s for help was one of the (& only) options - but point is, whom to call? Anna would have had slept (or would be getting ready to sleep), Rama would be busy with movies, Subbu dosnt has a bike, Ratish was not to be disturbed (newly weds are best when not disturbed 
)…
Did I miss out Mahesh d00d? lol
He was actually the first one on my list to call. I knew that in such a problem, he would never say no (even others would have not said no - but I didnt wanted to disturb their regular schedule either). Once on the phone, pat came his reply - “Maku, where are you right now, just gimme your location” - & a subtle smile came on my face - we had a solution to the problem!
Issues didnt ended there. Once we reached the nearest petrol pump (actually there are two of them - opposite to each other, on both sides of the road) - none of them was happy filling up petrol in a bottle (we had a crushable Bisleri bottle). To my relief, Mahesh had a PerlPet bottle in his bag which he uses everyday to drink water in office. Unhappily, he even gave up that bottle to fill petrol in it.
Point to remember - Dont ask any petrol pump station to fill up a crushable bottle - he’ll never fill it up!
Once my bike was back to normal again - I got Mahesh a Chicken Maharaja - his favourite, from McDonalds!
Today, Mahesh d00d saved my world for me!
In other words - as he put it - “Avenger says SOS - Apache came to help!”
Posted in A strong urge to blog... | Comments (9)
How to effectively deal with a redirecting Payment Gateway and prevent a possible DoS
December 16th, 2007
I am at a position where I have to think in advance that how should I be coding the interactions with our (redirecting, not API based) payment gateway. What can be the best design practice - for us (as a coder), for our website (as a product) and for the end user (usability).
Keeping everything in mind together and working towards a solution is interesting. It made me think pretty nicely to come up with a solution which satisfies all scenarios (except the ones, over which I have no control).
Scenario
Your website X uses a Payment Gateway (PG). When a user Z initiates a transaction (Tx) - a Tx ID and amount value (minimalistic variables) are sent to the payment gateway. On the shopping cart side, the product which Z is buying, is locked inside the database so that some other user should not buy the same product. If the user makes a successful Tx with PG, your shopping cart is notified of the status & everyone is happy!
Problem Statement
Issues arise when the shopping cart is dependent on timeout values from the PG. There can be two worst cases in this scenario…
- The user Z closes the browser (before completing the Tx) after he successfully opens the PG. By doing so, your shopping cart locks the product in your DB but is never able to unlock it back (because you will never receive a timeout communication from the PG) - until unless you run a separate thread or a cron job which keeps on freeing up locked products based on timeout value. If you have a large online store, doing 10000Tx simultaneously, this problem would lock 10000 of your products for the entire timeout value (in case an attacker launches an intelligent DoS on your store).
- The user Z just keeps the browser window with PG open. A timeout has to occur before it is communicated back to the shopping cart.
Solution
Note - I have not yet implemented this in any of my products - this is just a theory!
In the first scenario, open up the payment gateway as a frame inside your website - with you controlling the top header like frame & the PG controlling the other frame. Further, create a constant pingback AJAX connection to your shopping cart through the top frame. Once the AJAX connection dies, you have an almost sure shot way of knowing that the browser is no more alive, or Z’s is no longer connected. Your cart logic can then take appropriate actions of unlocking your product. - This solves problem scenario 1
The second scenario is the worst of the worsts! Browser has not been closed, and the user Z can make the Tx anytime before PG expires his Tx. What we can try here is put up a javascript clock which keeps ticking like a timer - again, we can use our top frame as thats the only part that we control when a PG is displayed. This will keep informing the user about the urgency to finish the Tx. This timer can change colors from green to yellow to red, signifying increasing priority, etc. Moreover, on the server side - one can either have a separate thread/cron-job to unlock the locked products - or - before any new access is made to the locked up DB, the cart logic an check up which all Tx’s are in a stale state & free them up. This will surely slow down the system a bit, but this would almost render the DoS attack useless. That solves problem scenario 2.
This is just my maiden attempt at Payment Gateways. If you think, I can improve my idea, feel free to add your suggestions in the comments section.
ApnaBill.com would be definitely using some (if not all) of these concepts.
Posted in ApnaBill, Rails, Startups, Technology, Web 2.0 | Comments (0)