Hacker News Reader

Comment by S3ForMe | Hacker News Reader

Current design was build by developers, not designers and will be renewed once the professional design is ready. We put all our efforts on backend and storage subsystem development and completely forgot about our temporary public website. Site images were taken from various public stock image services, I hope we didn't violate any rights by using these images.

View on HN

Like I asked, can you let me know the stock image services you used? I really like that cloud that Salesforce uses and would love to be able to use it myself.

Also, if you go to http://rest.s3for.me/ (the URL you use to calculate uptime) the error message in the document tree says 'The AWS Access Key Id you provided does not exist in our records'.

You mentioned S3 stands for Storage Should be Simple, what does AWS stand for in your company? Unfortunately cloud software isn't my forte, I would love to know what that acronym stands for.

My naivete leads me to believe that your status check is hosted with Amazon, and that your uptime checker would in fact be checking Amazon's uptime but I am surely mistaken.

I'll ask guy who made this design about stock images service.

We use this URL to monitor service uptime: http://rest.s3for.me/check/test.html

AWS stand nothing for our company, we don't use this acronym, but for Amazon it stands for "Amazon Web Services".

Here is our public status check: http://host-tracker.com/website-uptime-statistics/11891746/l...

Another curious coincidence: http://rest.s3for.me/check/test.html returns x-amz-request-id and x-amz-id-2 headers.

  HTTP/1.1 200 OK
  Date: Sat, 07 Sep 2013 20:37:05 GMT
  Server: Apache
  x-amz-request-id: 1378586225522b8e71190b5
  x-amz-id-2: storage1-1.s3for.me
  ETag: "444bcb3a3fcf8389296c49467f27e1d6"
  Last-Modified: Mon, 31 Dec 2012 20:09:52 +0000
  Content-Length: 2
  Content-Type: text/html
  
  ok

These headers are part of S3 implementation an we left them to avoid any possible problems with S3 clients. Some clients are very strict on protocol validation and refused to work in some cases. The purpose of these headers are to track all requests and be able to find any problems with any particular request. You must include them when contacting support with problems with some request. This is true both for Amazon and S3For.Me

If you go here: http://rest.s3for.me/check/

Why is your key id called 'AWSAccessKeyId', why does your error message say 'AWS Access Key Id does not exist in our records' why is your error message identical to the letter of what S3 would return. Surely the error message text isn't required for protocol validation.

This looks like you just took an open source S3 REST API clone (there are many) and stuck it on a Hetzner server without bothering to change any variable names.

To me there are a lot of questions, the most obvious tell is that I highly doubt Salesforce would use a stock image as the logo for their cloud database solution considering the level of investment they made in it.

'AWSAccessKeyId' is part of XML Schema and can not be changed. You are right regarding AWS text in error messages, I removed it, thank you for noticing this.

This was the first thought - to take an open source S3 REST API clone, install it on Hetzner servers and work this way, but it is not the case. Any of the available solutions fit to us for different reasons. All core software is build by our team. We use Open Source software a lot, but the core of S3For.Me was developed from the first to the last line by our team.

I've checked Salesforce site and do not see anything similar to our logo. It will be replaced in the nearest future anyway.

Reply on news.ycombinator.com