amplify-js: AWS Pinpoint failure due to invalid CORS header 'Access-Control-Allow-Origin' missing.

After chatting with an AWS support representative, he determined that the problem was due to the configuration created by Amplify and not part of Pinpoint. I’ll update this comment with more information when I receive an update on the specific misconfiguration.

Update:

Official response from the AWS support rep advised me to follow this starting tutorial: https://aws-amplify.github.io/docs/js/start.

Given the trouble getting started with the project, we have decided to move away from Pinpoint and thus I am unable to confirm or deny if the tutorial above resolved the problem.

Same issue here. The only way I was able to get this working was to edit the policy for each Groups IAM role that was created by Amplify to include:

`

     {
       "Action": [
            "mobiletargeting:PutEvents",
            "mobiletargeting:UpdateEndpoint",
            "mobiletargeting:GetUserEndpoints"
        ],
        "Resource": [
            "arn:aws:mobiletargeting:*:<INSERT_AWS_ACCOUNT_ID>:apps/<INSERT_AWS_MOBILE_ANALYTICS_ID_HERE>*"
        ],
        "Effect": "Allow"
    }

`

I just copied the Resource from the authRole created by Amplify. Again, I had to update the policy for each group in my app. Without doing this any user that logs in that is associated with a group without this policy receives the CORS policy: No ‘Access-Control-Allow-Origin’ and various 403 errors. I’m pretty new to Amplify so I have no idea if this is the right way to resolve this, but it did work. I’m not sure if this will get overwritten by Amplify the next time I push any changes. I’d love some input on that if anyone knows or if there is a better way to go about this. Hope this helps someone.

I just ran into the same issue with @djonk. But I think I have a resolution, inspired by @danielblignaut 's strategy to update the UserGroup Role with proper permissions https://github.com/aws-amplify/amplify-js/issues/5058#issuecomment-598647367 (different issue, but similar root cause).

Reproducible issue:

• I’ve got an Amplify project with Cognito User Pools for authentication, allowing for unauthenticated logins (which presumably creates the Identity Pool with unauthenticated access - which I verified through Cognito console)
• I added a Cognito Group “Admin” through Amplify CLI
• I added Analytics to the amplify project through Amplify CLI

When running the project:

• I created a user that is not part of the Cognito User Group When I login with a user that does NOT belong to a Cognito User Group, the analytics events fire properly with no CORS issue.

• I created a second user and manually added this user to the Cognito User Group through the Cognito console When I login with a user that DOES belong to a Cognito User Group, the analytics events are blocked with a CORS issue.

The problem:

• When a user is added to a User Group, they have a different role attached. This could potentially cause issues with other AWS services you’re trying to run, like S3 permissions for Storage (e.g. https://github.com/aws-amplify/amplify-js/issues/5058 )

I resolved this by:

1. Adding a userPool dependency to analytics (so I can access the userPoolId, which is needed to get the UserGroup Role name).

• In backend-config.json, update the analytics resource to include a dependsOn block. You can copy/paste the dependency from another resource (like userPoolGroups), but you just need the attribute: UserPoolId
• Run amplify env checkout <envName> to update your environment

1. In the analytics CFT, add the userPoolId as a parameter:

• In parameters:

"auth<userPoolResourceName>UserPoolId": {
            "Type": "String",
            "Default": "auth<userPoolResourceName>UserPoolId"
        },

1. In the analytics CFT, create a new resource (you can copy/paste “CognitoAuthPolicy” and tweak it).

        "CognitoAuthUserGroupPolicy": {
            "Type": "AWS::IAM::Policy",
            "Properties": {
                "PolicyName": {
                    "Ref": "authPolicyName"
                },
                "Roles": [
                    {
                        "Fn::Sub": [
                            "${userPoolId}-<GroupName>GroupRole",
                            {
                                "userPoolId": {
                                    "Ref": "auth<userPoolResourceName>UserPoolId"
                                }
                            }
                        ]
                    }
                ],
                "PolicyDocument": {
                    "Version": "2012-10-17",
                    "Statement": [
...

That seems to resolve the CORS issue for me for user that are added to a Cognito User Group.

Alternatively (I haven’t tried this, and I don’t know what risks there are either), in the userPoolGroups CFT, you could potentially update it from assuming the UserGroups Role to using the normal authRole.

I had the same issue described by @christopherdiehl and the responses herein did not help me at all. However, reverting to my default mode of thinking it through for myself instead of just following instructions did help. I had followed the instructions given for integrating analytics into web apps given in the Pinpoint console:

https://console.aws.amazon.com/pinpoint/home/#/apps/<project_id>/settings/webAnalytics (replace <project_id> with your project id)

These instructions emphasize allowing permission for unauthenticated identities, but since my app authenticates with Cognito, I actually had to edit the IAM policy document for authenticated identities. It took me an embarrassingly long time to figure this out, since the instructions were very clear about which IAM policy to edit.

I believe it is an oversight to not mention this, since many (most?) developers of web apps will require some form of user authentication for their apps. Indeed, the main focus of creating analytics campaigns requires authenticated users. So I would recommend that the integration steps for webAnalytics be updated to add a section explaining this. Basically, to fix CORS blocking PutEvents, I copied the IAM role policy JSON for unathenticated users into the IAM role policy for authenticated users. Now it works. Perhaps @powerful23 could raise this with the service team? 😃

Hello @manueliglesias, I didn’t see any solutions posted there other than a user stating their configuration was wrong.

I’ve gone through the setup tutorial a few times, and keep getting the same error each time. Would love any additional help you could provide.

@mohanrao cool. Sorry didn’t notice that star symbol. In fact in the doc the policy is like

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "mobiletargeting:UpdateEndpoint",
                "mobiletargeting:PutEvents"
            ],
            "Resource": [
                "arn:aws:mobiletargeting:*:${accountID}:apps/${appId}*"
            ]
        }
    ]
}

Which is ${appId}*

Also seeing a lot of CORS error messages on my console with similar setup:

The value of the ‘Access-Control-Allow-Origin’ header in the response must not be the wildcard ‘*’ when the request’s credentials mode is ‘include’. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

That being said… my events are being recorded in Pinpoint, just appears to be calls to the various /sso/login endpoints in AWS, e.g. https://cognito-identity.us-west-2.amazonaws.com/sso/login and https://pinpoint.us-west-2.amazonaws.com/sso/login