On 9/30, in the last 3 minutes of the market close, for some mysterious reasons Google stock price tanked while the rest of the market was going up especially after the 9%+ slide of NASDAQ yesterday, thanks to the bailout fallout. Being busy at work (no seriously), I missed out the opportunity to grab the stock at those lower prices. Ofcourse, it turned out that this is a big mistake and so NASDAQ is going to cancel many of those orders, so it wouldn’t really matter if I wasn’t busy at work :).
Anyway, the problem I want to mention is, companies like Yahoo! still are showing $322.99, almost 11 hours later inspite NASDAQ’s correction. So, I used one of the stock quotes web services that I am aware of and tried out online the stock quote for Google (thanks to Visual Web Service which provides online forms interface to submit web services with http binding). Here is what I got as the response.
Stock Quote Web Service
So, essentially, if one popular web service goes wrong, all the business processes that make use of the web service would go wrong. The point is not to advocate that SOA is not good or anything, but just to point out that changing to SOA from traditional architectures will not solve certain types of problems.
Now, it beats me how NASDAQ’s system would let it go through even if the error originated at a different market center.
You can’t call a system secure unless it’s really secure. Any application that does validation on the client side of the browser can’t afford to bypass it on the server side because someone can always programatically post invalid data. Long back when the app servers and http sessions were just coming up, a few e-commerce applications implemented shopping carts and item pricing using html form hidden variables and got hacked.
Anyway, I am trying to understand the security aspect of using Amazon S3, Amazon’s Simple Storage Service. When a system stores a resource locally, it has the control over serving the resource by authenticating the user. However, when using Amazon S3, this is usually not the case. That is, the very reason most people want to use Amazon S3 is for scalability. This can be achieved only if the url points directly to the Amazon S3 servers itself rather than pointing to your own server. If the url is routed through your own server, then you can do a server-side fetching of the resource stored in Amazon S3 after authenticating the user and then send it. But that defeats the purpose completely since your server becomes a bottleneck. Also, in that case, why store it in S3 and not locally?
Amazon S3 offers query-string authentication mechanism. This passes 3 additional URL parameters, your Amazon Web Services Access Key, Expiration and the Signature which is encrypted string of the resource url and a few other details. This guarantees that a resource is not accessible unless the signature is available, but the moment the url is given to one, and anyone else with an access to the url (which can happen in various ways) can also access the resource. So, essentially there is no user level security. The expiration field (which is also part of the signature, encrypted and safe) offers some level of defense, but still may not be good enough for certain class of secure applications.
So, it’s important to understand the limitations of using an OnDemand Service for powering up your applications. Amazon S3 as a personal backup drive is no brainer. Similarly, using it for completely public access also is no issue. Just those applications that require a tight security based on user (and not just based on the resource itself), can’t make use of S3. This issue is not specific to Amazon S3. Any service, with simple operations as those available in Amazon S3 WebServices will have this issue.