Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developer Preview of AWS SDK for JavaScript in the Browser

aws.typepad.com

Post reply on HN
Print view View original

11–20 of 31 posts

Re: Developer Preview of AWS SDK for JavaScript in the Browser

#11

Post by tomsaffell »

My first thought: great - we can retire our in-house multi-part uploader (EvaporateJS) [0] and use AWS's. But digging into the API, it seems like most of the real work of multipart uploading (managing part failures) is not done by the SDK [1], so we'll stick with EvaporateJS. It's working pretty well for us. We've seen 22GB uploads go through (direct from browser to S3). The main issue that we know of [2] should be fairly easy to fix if anyone wants to contribute!

[0] https://github.com/TTLabs/EvaporateJS [1] http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/frames.ht... [2] https://github.com/TTLabs/EvaporateJS/issues/6

Re: Developer Preview of AWS SDK for JavaScript in the Browser

#14

Post by williamcotton »

jeffbarr wrote: post #12
_pius wrote: post #10

This is huge. Jeff, if you're still reading, are there any plans to include Persona in the Web Identity federation?

I am reading! I will ask the team about Persona.

And what about Twitter and GitHub as well? :)

Re: Developer Preview of AWS SDK for JavaScript in the Browser

#15

Post by williamcotton »

davidjgraph wrote: post #13

It's a library helping devs move to a fully client-side model.... that requires a server for auth. I must been missing the intended use case. Happy with the Google Drive and Dropbox equivalents, this isn't something that we'll be adding to that set.

What is wrong about this model?

To me, one owns a domain, and ownership and trust in that domain is a source of authority. That authority will authenticate users, provide them with a set of credentials, and those credentials can then be used to write or store data. All that this method does is allow for the rest of the logic to be anywhere... client-side or server-side.

Re: Developer Preview of AWS SDK for JavaScript in the Browser

#16

Post by davidjgraph »

williamcotton wrote: post #15
davidjgraph wrote: post #13

It's a library helping devs move to a fully client-side model.... that requires a server for auth. I must been missing the intended use case. Happy with the Google Drive and Dropbox equivalents, this isn't something that we'll be adding to that set.

What is wrong about this model? To me, one owns a domain, and ownership and trust in that domain is a source of authority. That authority will authenticate users, provide them with a set of credentials, and those credentials can then be used to write or store data. All that this method does is allow for the rest of the logic to be anywhere... client-side or server-side.

Because if you look at how Google Drive and Dropbox do it, they enable you to run fully client side and use their storage. I can serve the whole thing statically, it's far simpler architecturally and saves a ton of CPU and bandwidth costs.

From what I'm reading, you can't do this auth fully client-side.

Re: Developer Preview of AWS SDK for JavaScript in the Browser

#17

Post by jeffbarr »

recuter wrote: post #6

"Each request must be signed with your AWS credentials. .. Our web identify federation feature to authenticate the users of your application. By incorporating WIF into your application, you can use a public identity provider (Facebook, Google, or Login with Amazon) to initiate the creation of a set of temporary security credentials." http://media.amazonwebservices.com/blog/2013/iam_web_identit... I rather disagree wi…

What kind of rate limiting do you need? What are you trying to guard against?

Re: Developer Preview of AWS SDK for JavaScript in the Browser

#18

Post by sha90 »

davidjgraph wrote: post #13

It's a library helping devs move to a fully client-side model.... that requires a server for auth. I must been missing the intended use case. Happy with the Google Drive and Dropbox equivalents, this isn't something that we'll be adding to that set.

You don't need a server for auth, that's what web identity federation[1] is for.

[1] http://aws.typepad.com/aws/2013/05/aws-iam-now-supports-amaz...

Re: Developer Preview of AWS SDK for JavaScript in the Browser

#20

Post by akoumjian »

tomsaffell wrote: post #11

My first thought: great - we can retire our in-house multi-part uploader (EvaporateJS) [0] and use AWS's. But digging into the API, it seems like most of the real work of multipart uploading (managing part failures) is not done by the SDK [1], so we'll stick with EvaporateJS. It's working pretty well for us. We've seen 22GB uploads go through (direct from browser to S3). The main issue that we know of [2] should be f…

We had similar hopes, but for now we will continue to use our in-house multi part uploader. We have to sign every multi-part request server side, using an auth scheme that depends on the key and the user.

I'm not sure if it would be an improvement or not to give each of our users an IAM account that correlates to specific bucket acl which is based on user namespaces. It would lighten the load on our servers (don't need to sign each request) but now each user needs resources in IAM to be managed.

Post reply on HN