4 ms·
This is not my area of experience, but is it feasible to capture all raw tracking data from the client devices and then just pass it on to the API?
by nmg 8y ago
This is not my area of experience, but is it feasible to capture all raw tracking data from the client devices and then just pass it on to the API?
- jdironman 8y agoThat's basically a proxy or MITM, no?
- lolc 8y agoDamn right I'm the man in the middle if I'm the SSL-offloader. It actually strengthens security because there's one less party to trust for the client.
- reading-at-work 8y agoYeah, but it sounds like it would satisfy the concern of being able to replace the 3rd party API internally without the mobile apps having to change.
- throw_away2 8y agoBut it will have the cost of 2x API bandwidth (vs 0) and another point of failure that you are responsible for. A DNS CNAME probably wouldn't work if you had to go over SSL. Maybe a 30x redirector (still have the SPoF, but simpler and much less bandwidth)? Except in the past, I've found that most clients react poorly to redirects for anything other than GETs. Is there any indirection that would avoid having to walk the traffic over my own network?
- chatmasta 8y agoThe way I would implement it is as a “proxy” on my own network, eg trackingservice.myapp.com, that is just a web server listening and forwarding requests (technically a MITM). Override the request method of the client SDK to hit my endpoint instead of the tracking service. Obviously you then pay the bandwidth, but it’s likely negligible compared to your app traffic. As a bonus you’ll probably circumvent adblockers. If you want to avoid traffic forwarding, but keep flexibility over the endpoint, you can override the init of the sdk to first query your server for which endpoint to use. That way if the third party service goes down, you just need to change the config on the server.