Scratching my head - weird IP address behavior on iOS


#1

Greetings,

I just started using snowplow recently. So if this turns out to be a dumb error on my part, apologies.

In the beginning, I embedded the following as part of kicking the tire process:

[subject setIpAddress: @"33.33.33.33"];

But after a few days I forgot about it and moved on with some other development. Now I am back testing this snowplowdemo app and to my surprise, the url keeps containing ip=33.33.33.33 despite the fact I have deleted this line from the code. Where could the app keep an old copy of the made-up ip address?

GET /i?aid=DemoAppId&se_la=DemoLabel&eid=94b8addf-68bb-49e1-84c4-475fd6176fa5&p=mob&co=%7B%22schema%22%3A%22iglu%3Acom.snowplowanalytics.snowplow%5C%2Fcontexts%5C%2Fjsonschema%5C%2F1-0-1%22%2C%22data%22%3A%5B%7B%22schema%22%3A%22iglu%3Acom.acme_company%5C%2Fdemo_ios%5C%2Fjsonschema%5C%2F1-0-0%22%2C%22data%22%3A%7B%22snowplow%22%3A%22demo-tracker%22%7D%7D%2C%7B%22schema%22%3A%22iglu%3Acom.snowplowanalytics.snowplow%5C%2Fmobile_context%5C%2Fjsonschema%5C%2F1-0-1%22%2C%22data%22%3A%7B%22deviceManufacturer%22%3A%22Apple%20Inc.%22%2C%22osVersion%22%3A%229.3%22%2C%22osType%22%3A%22ios%22%2C%22deviceModel%22%3A%22iPhone%22%2C%22networkType%22%3A%22wifi%22%2C%22appleIdfv%22%3A%2210668EC1-6790-4A4D-9C9E-FA069CD4CBE2%22%7D%7D%2C%7B%22schema%22%3A%22iglu%3Acom.snowplowanalytics.snowplow%5C%2Fgeolocation_context%5C%2Fjsonschema%5C%2F1-1-0%22%2C%22data%22%3A%7B%22longitude%22%3A-122.4064%2C%22latitude%22%3A37.78584%7D%7D%2C%7B%22schema%22%3A%22iglu%3Acom.snowplowanalytics.snowplow%5C%2Fclient_session%5C%2Fjsonschema%5C%2F1-0-1%22%2C%22data%22%3A%7B%22previousSessionId%22%3Anull%2C%22firstEventId%22%3A%22acad929f-ab36-4c53-b0c8-3bc1bb83f6b4%22%2C%22sessionId%22%3A%2291df8e62-01e3-457c-ba39-e1e5a6679a4a%22%2C%22userId%22%3A%22ee5d472b-4799-48d6-9866-519c01606dcc%22%2C%22sessionIndex%22%3A1%2C%22storageMechanism%22%3A%22SQLITE%22%7D%7D%5D%7D&stm=1464153617567&se_pr=DemoProperty&dtm=1461171338907&tv=ios-0.6.1&tna=DemoAppNamespace&se_ca=DemoCategory&se_va=5&ip=33.33.33.33&e=se&lang=en-US&se_ac=DemoAction&vp=1242x2208&res=1242x2208 HTTP/1.1

// BTW, I have clean’ed, rebuilt, rebooted iphone simulator and restarted my mac. nothing seems to help.

Help. Thanks.


#2

Also I added the following line in Snowplow demo ViewController.m:
[subject setDomainUserId: @“aeb1691c5a0ee5a6”];


[builder setSubject:subject];

However, when examining the payload, I can not see “duid” field.

Did I miss anything?
Please help. thanks!


#3

Hi @neo, that is indeed strange behaviour. On adding the following lines to the Subject construction in the ViewController.m file:

SPSubject *subject = [[SPSubject alloc] initWithPlatformContext:YES andGeoContext:NO];
[subject setIpAddress:@"33.33.33.33"];
[subject setDomainUserId:@"aeb1691c5a0ee5a6"];

I managed to successfully send events with both the duid and ip fields. Upon removing those extra lines and rebuilding the demo app in my emulator they were no longer present. This was done using both GET and POST requests.

There is nowhere for it to keep that fake information as the Subject information that is set is not persistently stored and is lost if the app is closed.

  • Have you made any other alterations to the Demo Application?
  • Could you share the exact changes that you have made?
  • What iOS Version is your emulator running?

Thanks,
Josh


#4

Hi Josh,
To answer your questions:

1)That’s the only two lines I added to snowplow demo:(subject has been initialized in original demo)
[subject setIpAddress:@“33.33.33.33”];
[subject setDomainUserId:@“aeb1691c5a0ee5a6”];

The other alteration is the workaround for http: I added the following to Info.plist

NSAppTransportSecurity

NSAllowsArbitraryLoads

  1. No other alterations.

  2. The simulator I am using is iPhone 6s plus, iOS 9.3.


#5

Hi Josh,
Here is what I found out: basically if I change anything in [subject set*** ],
somehow I need to change the simulator to a different device(say iphone6s to iphne4), then the change would be reflected.
any thought on that?

please help. thanks


#6

Hi @neo I have just run the same tests as before on the same emulator and I have not been able to replicate the issue. So it is really strange that this is happening to you!

What version of XCode and OSX are you running?


#7

Hi Josh,
sorry for the late reply. I am using Xcode7.3 and OS 10.11.3.

I only tested “Get” so far:
I found out if a http request failed, then the request is always been cached and sent over again.
Otherwise after successful http request on a brand new emulator, I could alway see the changes I made in the code instantly.


#8

Hi @neo,

Yep that is by design, if an event fails we keep it in a local SQLite Database and then attempt to send it until we get a 200 response code - otherwise we would lose important data!

Glad to see the changes are reflected in other events and that it is then, from what I can understand, working as normal.


#9

ok, is there any workaround to exit this loop? at least for debugging purpose


#10

how to clear out the cached event in other words?


#11

Hi @neo,

The events are all stored in a local SQLite database, to get rid of these events you can either:

  1. Uninstall and reinstall the application which would remove all application associated data.
  2. Programatically call this function: https://github.com/snowplow/snowplow-objc-tracker/blob/master/Snowplow/SPEventStore.h#L60

However you will only be able to access that function if you have manually dragged and dropped the h & m files into your code. This is because we do not expose the EventStore as a public header in our podspec.

Does that help at all?


#12

yeah, thx!


#13

Hi Josh,

I followed the instructon on “Setting up a local testing endpoint” from https://github.com/snowplow/snowplow-objc-tracker.

I noticed when I sent via Post, I don’t get to see the post body in the log when pointing to http://localhost:2525/logs, only [http:4545] 10.0.2.2:63959 => POST /com.snowplowanalytics.snowplow/tp2 shows up.

I also tried to set break point in Emitter code, which does not work well due to data pointers.

Wonder how I can view the post request header and body easily?

thanks again for your help,
neo