3 ms·

I think this happens all_the_time. Amazon has a solution for managing their access credentials that I admittedly wasn't using, but how many vendors do not? If

by rajbala 13y ago

I think this happens all_the_time. Amazon has a solution for managing their access credentials that I admittedly wasn't using, but how many vendors do not? If you're using a web services API from a 3rd party that requires developer authentication keys you may be storing those keys in the code because there's not a great alternative.

nknighthb 13y ago
The obvious and universal solution to APIs that don't have the kinds of facilities AWS does is that your app does not talk directly to the third party. You construct your own API that runs on your own servers and permits only those operations the users are supposed to be able to perform. It's not an "alternative", it's the correct solution. In fact, you still have to do a lighter-weight version of it with AWS -- you need an API to generate and hand out the restricted keys to your apps. With a few very rare exceptions, you don't use third-party APIs as a complete substitute for building your own services, you use them to make building your own services easier.
- rajbala 13y ago
  I'm not necessarily disagreeing with you, but it's not always practical and perhaps not even possible. For example the push notifications SDK from Urban Airship and app analytics SDK from Flurry depend on having credentials stored in the app. These examples are not unique to them. I don't disagree that it's wrong, but I don't know how to work around this to be candid.
  - nknighthb 13y ago
    Those are examples of AWS-like facilities. The embedded keys are not secret credentials that allow people to control your account! If you are embedding your account credentials from Urban Airship or Flurry in your app, you are badly misusing their APIs. They provide facilities for generating certificates/keys for each application.
    - rajbala 13y ago
      Urban Airship actually instructs you to create a plist file for an iOS app where you specify your production app keys. http://docs.urbanairship.com/build/ios.html http://docs.urbanairship.com/build/ios.html
      - saurik 13y ago
        The point is that these keys do not let you control the account: they only let you inject potentially-fake data; if these keys also let you register new applications, delete data, download data, or send information to third-parties, then that would be a serious problem. (In the case of Urban Airship, as opposed to Flurry, I don't know as much about the specific use case, but it would surprise me if the scenario were drastically different.
    - rajbala 13y ago
      I'm not embedding account credentials for Flurry and UA in my app. I embedding app keys and while those don't allow someone to take over my account they could certainly wreak havoc with push notifications.

by rajbala 13y ago

nknighthb 13y ago

The obvious and universal solution to APIs that don't have the kinds of facilities AWS does is that your app does not talk directly to the third party. You construct your own API that runs on your own servers and permits only those operations the users are supposed to be able to perform. It's not an "alternative", it's the correct solution. In fact, you still have to do a lighter-weight version of it with AWS -- you need an API to generate and hand out the restricted keys to your apps. With a few very rare exceptions, you don't use third-party APIs as a complete substitute for building your own services, you use them to make building your own services easier.

rajbala 13y ago
I'm not necessarily disagreeing with you, but it's not always practical and perhaps not even possible. For example the push notifications SDK from Urban Airship and app analytics SDK from Flurry depend on having credentials stored in the app. These examples are not unique to them. I don't disagree that it's wrong, but I don't know how to work around this to be candid.
- nknighthb 13y ago
  Those are examples of AWS-like facilities. The embedded keys are not secret credentials that allow people to control your account! If you are embedding your account credentials from Urban Airship or Flurry in your app, you are badly misusing their APIs. They provide facilities for generating certificates/keys for each application.
  - rajbala 13y ago
    Urban Airship actually instructs you to create a plist file for an iOS app where you specify your production app keys. http://docs.urbanairship.com/build/ios.html http://docs.urbanairship.com/build/ios.html
    - saurik 13y ago
      The point is that these keys do not let you control the account: they only let you inject potentially-fake data; if these keys also let you register new applications, delete data, download data, or send information to third-parties, then that would be a serious problem. (In the case of Urban Airship, as opposed to Flurry, I don't know as much about the specific use case, but it would surprise me if the scenario were drastically different.
  - rajbala 13y ago
    I'm not embedding account credentials for Flurry and UA in my app. I embedding app keys and while those don't allow someone to take over my account they could certainly wreak havoc with push notifications.