Iglu webhook response code

For engineers Tracking SDKs
1

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

2

Could you possibly post the URL and payload for the request that you are getting a 403 for?

3

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

4

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).

5

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

6

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…

7

Alex, rereading what you said this is not what I did, will test now
Thanks
Fred

8

Hi @Alex,
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
//Fred

9

Great idea @fwahlqvist - ticket created:

https://github.com/snowplow/snowplow/issues/2996