5 ms·

It's worse for companies that have shipped mobile apps with the API embedded in the client. Web apps can at least try an alternative or disable the affected fea

It's worse for companies that have shipped mobile apps with the API embedded in the client. Web apps can at least try an alternative or disable the affected features until they work around this mess..

maxxxxx 8y ago
This confirms my belief that I don't want to ship anything that uses directly a third party API. Instead always go through your own server which then calls the API so at least you have a chance to replace that.
- cinquemb 8y ago
  When I was developing mobile apps, this is what we did. Too many times something changes and trying to update the code in the mobile app is way more of a pain than updating the server.
- chatmasta 8y ago
  That works for a lot of cases, but for many tracking APIs you want the request to come from the end user, so the tracking service can get their IP and network metadata. That would certainly apply to a fraud detection API. Tbh that has always frustrated me though. I should be able to pipe those requests and just add an X-Forwarded-For header.
  - 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 ago
      That's basically a proxy or MITM, no?
      - lolc 8y ago
        Damn 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 ago
        Yeah, 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 ago
        But 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 ago
        The 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.

maxxxxx 8y ago

This confirms my belief that I don't want to ship anything that uses directly a third party API. Instead always go through your own server which then calls the API so at least you have a chance to replace that.

cinquemb 8y ago
When I was developing mobile apps, this is what we did. Too many times something changes and trying to update the code in the mobile app is way more of a pain than updating the server.
chatmasta 8y ago
That works for a lot of cases, but for many tracking APIs you want the request to come from the end user, so the tracking service can get their IP and network metadata. That would certainly apply to a fraud detection API. Tbh that has always frustrated me though. I should be able to pipe those requests and just add an X-Forwarded-For header.
- 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 ago
    That's basically a proxy or MITM, no?
    - lolc 8y ago
      Damn 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 ago
      Yeah, 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 ago
        But 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 ago
        The 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.