New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use with Cognito? #380
Comments
Hi @paolavness. Evaporate does not rely on aws sdk, you can check the source code yourself. And you probably have to implement the authentication yourself. You can do that in |
All users of EvaporateJS are required to understanding AWS signing principle, be they V2 or V4. The URL must be signed per the AWS documentation. If you already have an authenticated user, then you probably need to use that information to determine if you return a signed URL or not, but you cannot avoid signing the URL. This is how AWS manages security and upload consistency. |
2nd EDIT: SolutionBased the below working solution for EvaporateJS 2.x on this this helpful post. Thank you Drew!
1st EDIT: Not to worry I've found something.Mmmmmm I figured as much... that I'd need to figure it myself. @jakubzitny could you possibly give a footprint out of what the final @bikeath1337 currently using cognito, https, v4 and authorizations headers, uploads via the aws sdk's S3.upload() do not require signage - and perhaps I'm mixing things up here. the sdk does takes care of quite a bit of behind the scenes goodies. |
@paolavness if you open an issue on an open source project, and then edit your own reply reporting "i've found something".... It's common courtesy to those volunteers involved in the project to report what you actually found; whether it is still an issue and, appropriately close the ticket, if the issue has been resolved. @paolavness to reply to your mention about The volunteers for this project also provided an out of the box JavaScript implementation and sample HTML which you can use to experiment in a development sandbox. |
@bikeath1337 I was about to post my solution here for other cognito users... Only to see my previous comment deleted. I'm stunned in the censorship of what felt like positive + constructive feedback re your style. Not sure what else to say other than it feels like a good idea to talk about this in person. |
The purpose of this project is to improve it, not create issues about what you consider to be my personal style. If you have a pull request that can implement or improve for Cognito users, we're all for that contribution, but you should keep personal assessments personal and private. |
Yeah, posted my solution for this issue above. |
@paolavness Have you experienced any time out issues after 1h? I'm getting the following error <?xml version="1.0" encoding="UTF-8"?>
<Error>
<Code>ExpiredToken</Code>
<Message>The provided token has expired.</Message>
<Token-0>AgoGb3JpZ2luEIn//////////wEaDmFwLXNvdXRoZWFzdC0yIo.............xrbSDEai+M+ZvczUXcRhKOGvH0BhvPh5hNEcKjy10jf+hGzg4YYW+ph1CTfsaTE9ZM48XJtdDVsT4gc1dcxqFUo7sdwcDqmF8P/kQSCgqRiin1KHigMMntgdEF</Token-0>
<RequestId>61CB27C6E74C2F52</RequestId>
<HostId>1iJU52GeSyaX8aH6RfZAw9/HSB4gvme/4Asu5G...........SpjBa0Vm8o4oSOJGnfb187eRFpo20=</HostId>
</Error> |
@mordka Yes, its the sts tokens - they expire by default after an hour. I experienced the issue both with the S3 ManagedUpload and EvaporateJS. You need to manually refresh the cognitoUser My final solution worked for S3's managedUpload. I have not tried it yet with evaporateJs tho. Would love to hear if you get it working with evaporateJS. |
@paolavness Thanks for quick response. The thing is, I'm familiar with this and I do refresh both cognito JWT tokens and STS temporary credentials every 50 minutes - this works well for regular IAM signed requests to API Gateway. This doesn't work for S3 uploads with EvaporateJS. It's critical problem and I'm looking into this for longer time. This could be the signer issue. I will answer here once I manage to fix it. |
@mordka Its a pleasure, i know how frustrating this can be. Are you using EvaporateJS requests with API Gateway? You need to pass the updated AWS.config.credentials to EvaporateJS after they have been refreshed. If you dont, requests will continue with the outdated ones. If you revert to S3's ManagedUpload, I uncovered a a bug in it in which, unlike other requests, the |
@paolavness thanks for help, I found that credentials (aws, session, secret) spread in code all over the place. So to update it everywhere we need to overwrite the following places:
The code:
|
@mordka thanks for adding this here. We're looking at re-implementing evaporatejs in our production environment and I am wondering the above solution continued to work for you - in a production environment? Thanks, |
Hi @paolavness, yes it still works great. |
Hey many thanks to @paolavness and @mordka. You helped me save a lot of frustration implementing Token Authentication with evaporate. One small addition, with the version of evaporate that I'm using (2.1.4) it was necessary to adjust mordka's code slightly to check if the awsRequest object is defined. Seems like this object is only defined on still outstanding parts. My implementation looked like this:
|
@paolavness i am your code snippet with amplify , but i always get a signature mismatch. Instead of using aws-sdk i am using crypto.js for hashing, any help would be appreciated.
|
@paolavness I also have a signature mismatch. i am using crypto-js for hashing, any help would be appreciated. import * as Evaporate from 'evaporate';
import * as crypto from "crypto-js";
Evaporate.create({
aws_key: <ACCESS_KEY>,
bucket: 'my-bucket',
awsRegion: 'eu-west',
computeContentMd5: true,
cryptoMd5Method: data => crypto.algo.MD5.create().update(String.fromCharCode.apply(null, new Uint32Array(data))).finalize().toString(crypto.enc.Base64),
cryptoHexEncodedHash256: (data) => crypto.algo.SHA256.create().update(data as string).finalize().toString(crypto.enc.Hex),
logging: true,
maxConcurrentParts: 5,
customAuthMethod: (signParams: object, signHeaders: object, stringToSign: string, signatureDateTime: string, canonicalRequest: string): Promise<string> => {
const stringToSignDecoded = decodeURIComponent(stringToSign)
const requestScope = stringToSignDecoded.split("\n")[2];
const [date, region, service, signatureType] = requestScope.split("/");
const round1 = crypto.HmacSHA256(`AWS4${signParams['secret_key']}`, date);
const round2 = crypto.HmacSHA256(round1, region);
const round3 = crypto.HmacSHA256(round2, service);
const round4 = crypto.HmacSHA256(round3, signatureType);
const final = crypto.HmacSHA256(round4, stringToSignDecoded);
return Promise.resolve(final.toString(crypto.enc.Hex));
},
signParams: { secretKey: <SECRET_KEY> },
partSize: 1024 * 1024 * 6
}).then((evaporate) => {
evaporate.add({
name: 'my-key',
file: file, // file from <input type="file" />
xAmzHeadersCommon: { 'x-amz-security-token': <SECURITY_TOKEN> },
xAmzHeadersAtInitiate: { 'x-amz-security-token': <SECURITY_TOKEN> },
}).then(() => console.log('complete'));
},
(error) => console.error(error)
); result
|
paolavness commentedAug 22, 2017
Hi there,
I am migrating our app from using AWS SDK's multipart uploader (with transfer acceleration and v4 signing ) to Evaporate.js
Two questions - does Evaporate rely on the aws sdk in any way?
And we're using Cognito to auth all our users. Additionally, our bucket policy is setup to only allow access from all auth'd users.
I am wondering if there is a way to utilize this fact, rather than requiring the step of
signUrl
orcustomAuthMethod
? On one hand, feels like a step backward to have to to include anaws_key
and signage for an already authenticated user. On the other hand I am hoping Evaporate will be more robust and flexible that the sdk's multipart uploader.Thank you, looking forward to hearing from you,
Paola
The text was updated successfully, but these errors were encountered: