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

[christopherdiehl]

Describe the bug
AWS Pinpoint failure due to invalid CORS header 'Access-Control-Allow-Origin' missing.
I'm trying to send events with unauthenticated identities in a React v16 app.

To Reproduce
Steps to reproduce the behavior:
1.Create new PinPoint project in AWS console

1. Add Analytics
2. Follow steps outline in https://console.aws.amazon.com/pinpoint/home/?region=us-east-1#/apps//settings/webAnalytics
3. Add window.LOG_LEVEL = 'DEBUG'; to site configured in step 3
4. See the error

Expected behavior
I expect the records to appear in Pinpoint analytics.

Screenshots
The event is retried resulting in numerous logs of the following:

AWSPinpointProvider - init clients with credentials 
<redacted object of credentials>
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://pinpoint.us-east-1.amazonaws.com/v1/apps/<redacted>/events/legacy. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).[Learn More]
[ERROR] 32:37.335 AWSPinpointProvider - record event failed.  NetworkingError: "Network Failure"

    handleRequest xhr.js:56 sentryWrapped index.js:3852 

Desktop (please complete the following information):

• OS: Ubuntu 18.04
• Browser: Chrome / Firefox
• Versions:
  
  
  
  • "@aws-amplify/analytics": "^1.2.11",
  
  
  • "@aws-amplify/auth": "^1.2.18",
  
  

Additional context
Without window.LOG_LEVEL = 'DEBUG' I receive the error discussed in: https://github.com/aws-amplify/amplify-js/issues/1759 for a

Sample code

import Analytics from '@aws-amplify/analytics';
import Auth from '@aws-amplify/auth';';

const amplifyConfig = {
  Auth: {
    identityPoolId: 'COGNITO_IDENTITY_POOL_ID',
    region: 'us-east-1'
  }
}
//Initialize Amplify
Auth.configure(amplifyConfig);

const analyticsConfig = {
  AWSPinpoint: {
        // Amazon Pinpoint App Client ID
        appId: '<redacted>',
        // Amazon service region
        region: 'us-east-1',
        mandatorySignIn: false,
  }
}

Analytics.configure(analyticsConfig)

//Record an event
Analytics.record('some-event-name');

//Record a custom event
Analytics.record({
    name: 'Album',
    attributes: { genre: 'Rock', year: '1989' }
});

[manueliglesias]

Hi @christopherdiehl

Your issue seems very similar to #448

If the solutions posted there don't help you, let us know to re-open this issue

[christopherdiehl]

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.

[StJohn3D]

Having the same problem, and like he said there is no solution posted in that other issue.

[christopherdiehl]

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.

[mihaiblaga89]

any news on this? I'm having the same issue

[mrtho1]

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

[anthony-tietjen-navex]

Any update? Is this happening to all Website Pinpoint projects? Or are we doing something out-of-the ordinary to cause this?

[powerful23]

@christopherdiehl Hi, can you check if

• Cognito Federated Identity Pool you configured in the Auth module allows unauthenticated access
• The IAM role of the unauth identities is set correctly
• Can you open the debug mode to provide more info when sending the event to pinpoint? Put window.LOG_LEVEL='DEBUG' in the code.

[mohanrao]

Hi @powerful23 ,

I am getting same error.

• Yes the federated identity pool has unauthenticated access enabled

• Unauth identies is correct set

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "mobiletargeting:PutEvents"
            ],
            "Resource": [
                "arn:aws:mobiletargeting:us-east-1:193150987319:apps/{appid}"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "mobiletargeting:UpdateEndpoint"
            ],
            "Resource": [
                "arn:aws:mobiletargeting:us-east-1:193150987319:apps/{appid}"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "mobileanalytics:PutEvents"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

• After enabling the debug log Below is the error

[ERROR] 02:58.669 AWSPinpointProvider - record event failed. NetworkingError: "Network Failure"

handleRequest xhr.js:52 wrapped build.umd.js:2357

[powerful23]

@mohanrao can you try using https in your localhost env? (for example, if you are using parcel bundler or webpack you can run their watch command with —https flag)

Also can you provide more context? Like the request and response headers sent to to the Pinpoint service which will help a lot.

Another note:
"For requests without credentials, the literal value "*" can be specified, as a wildcard; the value tells browsers to allow requesting code from any origin to access the resource. Attempting to use the wildcard with credentials will result in an error.
They may have to remove adding Access-Control-Allow-Origin headers on their client side as they are already provided server side"

[mohanrao]

I Modified the role policy as below and its working

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "mobiletargeting:PutEvents"
            ],
            "Resource": [
                "arn:aws:mobiletargeting:us-east-1:193150987319:apps/{appid}",
                "arn:aws:mobiletargeting:us-east-1:193150987319:apps/{appid/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "mobiletargeting:UpdateEndpoint"
            ],
            "Resource": [
                "arn:aws:mobiletargeting:us-east-1:193150987319:apps/{appid}"
                 "arn:aws:mobiletargeting:us-east-1:193150987319:apps/{appid/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "mobileanalytics:PutEvents"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

[powerful23]

@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}*

[powerful23]

@christopherdiehl can you check you IAM policy to see if it has the * symbol.

[Neil-Ni]

Thanks for pointing out the * sign @mohanrao ! I was thrown off by the example in Pinpoint Console. Screenshot below if anyone started out looking at Pinpoint Console like I did. The example in this Pinpoint Console page doesn't have * sign but the official document has it. I did not realize the sign until this thread. @powerful23 is it possible to add * under the Pinpoint Console example?

[powerful23]

@Neil-Ni I will raise it to the service team.

[christopherdiehl]

@powerful23

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "mobiletargeting:PutEvents"
            ],
            "Resource": [
                "arn:aws:mobiletargeting:us-east-1:<redacted>:apps/<redacted"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "mobiletargeting:UpdateEndpoint"
            ],
            "Resource": [
                "arn:aws:mobiletargeting:us-east-1:<redacted>:apps/<redacted"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "mobileanalytics:PutEvents"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because of inactivity. Please open a new issue if are still encountering problems.

[JakeyChan]

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? :)

[djonk]

@manueliglesias I'm facing a very similar issue. Amplify does not seem to correctly configure the Analytics policies for User Groups when used in conjunction. This results in the CORS issue - as the result of authentication issues.

To reproduce you can use out of the box Amplify:

• Setup Amplify and add Authentication with the use of User Groups
• Use Amplify to add Analytics

You will notice that authenticated users will not have the correct permissions on their User Groups and the request fails due to authorization issues.

[ngnathan]

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

[stephendmalloy]

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.