Geek Life....
photography, programming, site design, networking, computers, linux, windows, mac os x, application reviews...
photography, programming, site design, networking, computers, linux, windows, mac os x, application reviews...
19
cross browser, css, css level, css reset, jquery, programming
For the last year or so, I’ve solved browser specific CSS issues using a lightweight jQuery plug-in by Jon Hobbs-Smith named BrowserDetect.js. This solution allows us to target specific browsers, and browser versions via CSS selectors injected into the Body class.
Lately though, I’ve noticed a few bugs creeping into some of my work where a specific browser version gives slightly differing results across the three main platforms, Mac, Win, Linux. So I spent some time both refining browserDetect.js and have added functionality that allows me to target the platform as well.
As it sits right now, you can target a fairly granular range of variables compared to the original:
And here’s what the body tag CSS selectors looks like in Firefox 8 on my Mac:
<body class="Firefox Firefox8 FirefoxMac Firefox8Mac Mac">
Download the code: css-level.js
03
My old boss pointed out to me a long time ago, that VI was something I should really get down and dirty with. I was an EMACS user at that time and I really had no interest in learning something new when I had lots of work piling up already.
That being said though, he added a very good point. VI is on all Linux distributions by default and being proficient with it means I can sit at pretty much any terminal and get the job done.
And so I learned VI.
Recently I’ve noticed a new fad evolving around the Interwebs. It would seem that pimping out VIM with plug-ins is the latest trend for aspiring developers whom believe the tools and add-ons they use make them more elite than those whom do not. But while some do argue what editor is best, I’m getting work done in trusty old VI. Could you imagine having to explain to a new boss or client that you can’t do work on their machines until you download and install a hoard of plug-ins? Could you imagine a junior employee fumbling with installing things on to a production machine?
There are many full-fledged IDE packages for your workstation available these days, which allow for live editing of files across ftp, ssh and the likes. This way you can have all of your toys installed there and not have to worry about tainting your clients servers :)
:wq
19
API, development, paypal, programming, web design, wikileaks
Wikileaks stumbled on to the world stage earlier this year with the release of thousands of internal cables belonging to the US Government. Since then, the story has exploded full force into what could very well be mistaken for a new Tom Clancy novel.
Fallout from Julian Assange’s being taken into custody resulted in the Internet backlash, and highly organized Distributed Denial of Service attacks against corporate entities which chose not to support Wikileaks. As a result, Visa, Mastercard, and Paypal service were all affected.
Has your work been affected by this.
Last week we discovered a recent problem with a site I build by hand. It is a full online catalog with a UPS shipping system and Paypal checkout system. After receiving an email from a purchaser the vendor passed it to the development team to try to discover what happened.
As it turns out, the web server logs show that the two users whom were double billed were:
Now, being a bit experienced in transaction-based systems, I developed the back end to expire the page immediately and revert to the home page after a successful sale. This page records the successful paypal result, writes the invoice in both HTML and PDF versions, and notifies the client and vendor of the transaction so that goods may be shipped. This page was designed to ensure that it can only ever display once per successful transaction.
So what went wrong?
Well. Turns out that these transactions took place December 5th. On this day, Paypal was under considerable stress from the Wikileaks related DDOS attack and thus the site was painfully slow. There are two steps during the Paypal Express Checkout procedure which requires the user flipping between the vendor site and the Paypal API system. Two points of failure. My code was designed to kill a session should a user try to refresh a page in such a position as to resend the transaction requests. This should have killed any chance that a duplicate should ever take place right?
Wrong. The problem is that once I send confirmation to the PayPal API, they record the transaction on their side and they DO NOT confirm whether or not they were able to send back final confirmation to the vendor site. This means that although the transaction took place, the vendor site sat waiting for a response so it could generate the invoice and finalize the sale, a response that never came in a timely manner thus prompting the users to re-checkout after a few minutes.
Personally, I would have their API kill the transaction if their success code back to the vendor never reaches its destination… but that’s just me. There really is no way to fix this from our side, however I can add some bells that correlate calls to the API with return codes from the API so as to determine if they are ever odd.
17
apache, database, evil, exploit, Google, logs, passwords, PHP, programming, Security, vulnerability, web design
Okay so this post isn’t exactly about Google being Evil as much as it is about bad programming habits. This is about how a programming error led to Google automated systems being a little mischievous.
A couple of weeks ago I was asked to look into a problem where a site’s database would empty every so often. The products and news would have to be re-entered. This problem brought to light several items that I thought were noteworthy for a post.
08
![]()
CAPTCHA – Completely Automated Public Turing test to tell Computers and Humans Apart.
All current CAPTCHA implementations are doomed to fail due to the persistence of developers to place the onus on client side technologies for validation. Whether you show the answer to the challenge (albeit after making recognition difficult), or have users spin a photo until it is upright, you are still giving the end-point everything they need to pass the test.
It’s time to rethink CAPTCHA, and move the means of protection server side where it can not be manipulated.