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?
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
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).
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
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
Using the correct uri looking like this
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.
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
have amended as suggested and works fine, might I suggest that the documentation is updated on the cloudfront collector to set up a second pixel for web hooks, i.e.
/I for the trackers but
/v2 if you need the igly webhook’s
many thanks for replay from you @alex and @mike