Closed Casburggraaf closed 1 month ago
It only depends on your API. For example, we use another Header called accessToken. It can also be encoded in Base64 or anything else. If you are sending a token in the correct Header and encoding, you need to make sure that you are using the correct token (access, id) and decoding this particular type of token in the API. If you still get the error, try the previous version of the container (2.x) or update the Amplify library in the API to the latest version.
Пт, 27 сент. 2024 г. в 13:21, Cas Burggraaf @.***>:
I tried using your image to authenticate an API endpoint created with Amplify. I successfully retrieved a JWT token. However, when I pass it through as a Bearer token, I encounter the following error:
Invalid key=value pair (missing equal-sign) in Authorization header (hashed with SHA-256 and encoded with Base64):
Could you help me resolve this issue?
— Reply to this email directly, view it on GitHub https://github.com/siarheidudko/aws-amplify-auth/issues/1, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIXASJWKALS2O4ZCMAQ5W2DZYUPRBAVCNFSM6AAAAABO6YCZHOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGU2TENBTHA3DSMY . You are receiving this because you are subscribed to this thread.Message ID: @.***>
The API is set up using Amplify (v1) and works fine with Postman. I added authentication to the API through the CLI, and it functions correctly in the app with the native Amplify packages. While inspecting network traffic in the simulator, I noticed that it's not using a Bearer token but instead an 'x-amz-security-token.'
I also tried using your v2 image but that didn't resolve the problem
I've done some research and it looks like you're using signed requests. I will think about how this can be implemented as part of PostMan integration, but it is not currently supported. In the near future, I will add key output for signing requests on your side, but I am not sure about the possible support for this in PostMan, since this requires significantly changing the original request.
Пт, 27 сент. 2024 г. в 13:44, Cas Burggraaf @.***>:
The API is set up using Amplify (v1) and works fine with Postman. I added authentication to the API through the CLI, and it functions correctly in the app with the native Amplify packages. While inspecting network traffic in the simulator, I noticed that it's not using a Bearer token but instead an 'x-amz-security-token.'
I also tried using your v2 image but that didn't resolve the problem
— Reply to this email directly, view it on GitHub https://github.com/siarheidudko/aws-amplify-auth/issues/1#issuecomment-2378880974, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIXASJSKK5BS6UADQ7T2STDZYUSJDAVCNFSM6AAAAABO6YCZHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZYHA4DAOJXGQ . You are receiving this because you commented.Message ID: @.***>
I got it working with your latest release. Now I just need to deploy it for the team, but that should be the easy part.
Thanks a lot! Can I buy you a coffee?
Of course, I'd love to have a coffee.
https://www.buymeacoffee.com/dudko.dev https://paypal.me/dudkodev
Вс, 29 сент. 2024 г. в 13:59, Cas Burggraaf @.***>:
I got it working with your latest release. Now I just need to deploy it for the team, but that should be the easy part.
Thanks a lot! Can I buy you a coffee?
— Reply to this email directly, view it on GitHub https://github.com/siarheidudko/aws-amplify-auth/issues/1#issuecomment-2381291607, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIXASJUI4G4FDVNW5VIEVZTZY7FOJAVCNFSM6AAAAABO6YCZHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBRGI4TCNRQG4 . You are receiving this because you commented.Message ID: @.***>
Hi @Casburggraaf, I added a special endpoint for signing requests in version 4.0.0-beta. But at the moment I don't have the opportunity to fully test it.
Nice! How does this differ from Postman's signing compatibility? ( I attached a screenshot of my config that's working) This will be helpful for requests made outside of Postman that can't run the AWS SDK.
the only thing I'm looking into that the pre-script only runs if needed because it's causing some delay
const authConfig = JSON.parse(pm.environment.get("COGNITO_AUTH_CONFIG"));
const username = pm.environment.get("COGNITO_AUTH_USER");
const password = pm.environment.get("COGNITO_AUTH_PASSWORD");
const postRequest = {
URL: "<PRIVATE>/auth",
method: "POST",
header: {
"Content-Type": "application/json",
},
body: {
mode: "raw",
raw: JSON.stringify({
username,
password,
authConfig,
tokenType: 'id',
withSessionData: true
}),
},
};
pm.sendRequest(postRequest, (error, response) => {
if (error) {
console.log("erorr");
console.log(error);
return;
}
const responseJson = response.json().data;
pm.collectionVariables.set("accessKey1",responseJson.session.accessKey);
pm.collectionVariables.set("secretAccessKey1",responseJson.session.secretAccessKey);
pm.collectionVariables.set("xAmzSecurityToken",responseJson.session.xAmzSecurityToken);
});
@Casburggraaf Probably the result should not differ from the PostMan signature, except that the signature is carried out on the container side.
If you run a pre-script on request, then your configuration option is preferable.
If you run a pre-script before each request, then it should make the configuration easier. Instead of keys for signing data, you immediately get the correct headers with the signature.
Also a small change in this version was the xAmZSecurityToken
key name changed to sessionToken
.
I tried using your image to authenticate an API endpoint created with Amplify. I successfully retrieved a JWT token. However, when I pass it through as a Bearer token, I encounter the following error:
Could you help me resolve this issue?