Hey All,
Slightly strange error and wanted to check my understanding, currently using cloud front collector and iglu webhook, although my schema is validated and i can process the data correctly i am getting a 403 each time I make a get request to the adapter. This currently works fine but about to integrate with a 3rd party that will not repost info if they get to many 403’s, guessing i have some settings wrong in my cloud front but unsure where?
Many thanks
Fred
Could you possibly post the URL and payload for the request that you are getting a 403 for?
Hi @mike, the get request starts with
"https://XXXX.cloudfront.net/com.snowplowanalytics.iglu/v1?schema=…"
and the response is
<?xml version="1.0" encoding="UTF-8"?>
<Error>
<Code>AccessDenied</Code>
<Message>Access Denied</Message>
<RequestId>xxxxxxxxxxxxxxx</RequestId>
<HostId>xxxxxxxxxxxxxxxxxxxxxx</HostId>
</Error>
have also tried http and including /i/ in the request
Any thoughts are welcome
Hi @fwahlqvist, this error is typically generated when Amazon attempts to serve a key from S3 that doesn’t exist (in this case the com.snowplowanalytics.iglu/* asset). I’m not sure if this will work but there’s an issue on the Github repo describing this here.
Has anyone has tried uploading a duplicate pixel cp /i /com.snowplowanalytics.iglu/v1 with that path and testing it to see if it works? (cc @alex).
Hey Mike,
After some small experimentation this is my findings if anyone else get the same issue
Cloudfront logs whatever you request, as the default setup is to serve a pixel on “/i” that is the only uri by default that will give you a 200, with that the uri would look like this
‘’’ “http://xxxxxx.cloudfront.net/i?schema=…”
However this does not work with Snowplow’s ETL process for enrichment.
If you add in a the “com.snowplowanalytics.iglu/v1/” and puts a pixel in the folder the ETL process will still show this as error as the collector URI is wrong, the uri would look like this
‘’’ “http://xxxxx.cloudfront.net/com.snowplowanalytics.iglu/v1?schema…”
Using the correct uri looking like this
‘’’ “http://xxxxxx.cloudfront.net/com.snowplowanalytics.iglu/v1?schema…”
the ETL enrichment workshowever you will get a 403 on each request and thats not ideal
The 3 theoretical options I can see is
A) Amend snowplow ETL process to work with I pixel (either in root folder or subfolders).
B) In AWS change the setup so a pixel will be served from the subfolder “com.snowplowanalytics.iglu/v1/” even when calling subfolder root
C) In AWS see if its possible to change the default behaviour to respond with a 200 on “com.snowplowanalytics.iglu/v1/”
A last alternative is to de-scope the iglu web hook and say its not compatible with cloudfront collector.
@mike and @alex would be great if you could add any builds, comments or thoughts
Thanks
Fred
Hi Fred,
I didn’t quite understand this:
I think you want to create a folder called com.snowplowanalytics.iglu and then put a pixel in that folder called v1 - is that what you did? I can’t see why a curl on the command line to that path would give a 403…
Alex, rereading what you said this is not what I did, will test now
Thanks
Fred