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

21–30 of 31 posts

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

#21

Post by davidjgraph »

sha90 wrote: post #18
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...

In the flow picture at the bottom, the STS looks like a server to me. What I'm saying is the auth flow still seems to require a server to act as an indirection to the real auth server. But if Amazon provide that part for us, great.

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

#22

Post by recuter »

jeffbarr wrote: post #17
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?

Well lets say I have a TokenFactory running somewhere (my servers, AppEngine, whatever) and my app is called Shminstegram - when my users login and get a token that's good for say 1 hour, I probably don't want them uploading 10,000 photos in that time period. That's probably a bot.

Now I could manage this myself with a background task that crunches S3 logs at its own pace and when it notices abuse it reports it to my TokenFactory so next time that user asks for a fresh token they get denied... but it would be great if S3 was a tad smarter about such things on its own. :)

Does that sort of make sense? In other words a token should have finer grained permissions than just time. Maybe... "Accept this token for the next 24 hour, or 200 POSTs, which ever comes first, and no more than 20 POSTs in the last hour." That sort of thing.

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

#24

Post by ozten »

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.

This would be great. Firebase is somewhat of a competitor and offers this feature.

https://www.firebase.com/docs/security/simple-login-persona....

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

#25

Post by martingordon »

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…

Thanks for the link to EvaporateJS. The recent price changes at Ink Filepicker make it untenable for our small needs and this looks like a great alternative.

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

#26

Post by sha90 »

davidjgraph wrote: post #21
sha90 wrote: post #18

Earlier quoted context omitted.

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...

In the flow picture at the bottom, the STS looks like a server to me. What I'm saying is the auth flow still seems to require a server to act as an indirection to the real auth server. But if Amazon provide that part for us, great.

It's not just Amazon providing this-- there is Login With Amazon, but there is also Facebook and Google that act as identity providers. Unless I'm mistaken, this is how Google's storage APIs work too, by using OAuth/OpenID to get an access token that can then be exchanged for keys.

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

#27

Post by sha90 »

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…

The SDK handles retries on failed requests. There is a little bit of extra legwork to actually do the slicing of a Blob, but you should be able to call createMultipartUpload(), uploadPart() x N, followed by completeMultipartUpload(). The SDK will make sure that each individual part gets retried on failures. That said, it would be nice to have a helper for that process.

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

#28

Post by jeffbarr »

sha90 wrote: post #26
davidjgraph wrote: post #21

Earlier quoted context omitted.

In the flow picture at the bottom, the STS looks like a server to me. What I'm saying is the auth flow still seems to require a server to act as an indirection to the real auth server. But if Amazon provide that part for us, great.

It's not just Amazon providing this-- there is Login With Amazon, but there is also Facebook and Google that act as identity providers. Unless I'm mistaken, this is how Google's storage APIs work too, by using OAuth/OpenID to get an access token that can then be exchanged for keys.

Here's a sample that will let you authenticate using Facebook and then upload content to S3:

http://aws.amazon.com/developers/getting-started/browser/

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

#29

Post by Chupachupski »

recuter wrote: post #22
jeffbarr wrote: post #17

Earlier quoted context omitted.

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

Well lets say I have a TokenFactory running somewhere (my servers, AppEngine, whatever) and my app is called Shminstegram - when my users login and get a token that's good for say 1 hour, I probably don't want them uploading 10,000 photos in that time period. That's probably a bot. Now I could manage this myself with a background task that crunches S3 logs at its own pace and when it notices abuse it reports it to my…

In this context bandwidth throttling is also a consideration - perhaps a per token or per bucket max object size?

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

#30

Post by recuter »

Chupachupski wrote: post #29
recuter wrote: post #22

Earlier quoted context omitted.

Well lets say I have a TokenFactory running somewhere (my servers, AppEngine, whatever) and my app is called Shminstegram - when my users login and get a token that's good for say 1 hour, I probably don't want them uploading 10,000 photos in that time period. That's probably a bot. Now I could manage this myself with a background task that crunches S3 logs at its own pace and when it notices abuse it reports it to my…

In this context bandwidth throttling is also a consideration - perhaps a per token or per bucket max object size?

You can limit objects by size with the existing ACL's already. But you can't specify how many objects overall a user may upload in some time frame, or their accumlated size.

So you can have a token for: upload as many objects as you want of size less than 1MB in the next 1 hour.

You can't have a token for: upload no more than 1000 objects of size less than 1MB, in the next 1 hour and cut them off after 200MB Total.

Post reply on HN