TLDR:
Does Google check the validity of an iOS app's bundle identifier when restricting the API key to a specific iOS app?
Or is it possible for anyone to mimic the bundle ID in order to launch an attack?
If the latter is false, why not include the API key in the iOS app?
UPDATE 1:
I'm guessing Google doesn't check for Team ID?
Apple Glossary
App ID A string that identifies one or more apps from a single team. An App ID consists of a bundle ID search string preceded by the Team ID, a 10-character string generated by Apple to uniquely identify a team.
I need some directions... (pun intended)
Say I'm building an iOS app that needs to consume the Google Directions API.
Google suggests to "proxy the web service via your server when you're using the API in a mobile app, to protect your API key".
In my project settings in Google Console (API Manager -> Credentials etc) I can restrict the API key to only iOS apps with my bundle identifier (com.example.MyApp).
Since I don't need a server, what's the worse that can happen if I include the key in the app?
The only thing I can think of right now is someone steals the API key and builds an app faking my bundle ID (or even fake the iOS host itself) and fires "unlimited requests" to bring down my service/make me pay a lot of money.
Is this possible?
And if it is, couldn't he do the same even if I hid the API key in the server? Just call my server instead of the API directly.
So what's the gain of having a server in that case?
And would the only solution to prevent this abuse be to require authentication and rate limit each user?
But couldn't then someone create "unlimited" random accounts?!
Do I use captcha?
By then the UX has become pretty awful, especially since authorisation is not even required for my app...
Is there a solution to this, or do I just choose the simplest solution (include the key in the app) and hope for the best?
Related
I am working on a functionality to send an email to user whenever a they log in to my website with a new device. For example if a user logged in to their account from iOS app, notify them that a new device login is detected. If at a later point, same user logs in from web browser, send another notification that a new device login is detected.
I came across UIDevice uniqueIdentifier deprecated - What to do now? and Is there a unique Android device ID?.
I wanted to confirm few things:
Does UIDeviceIDentifierForVendor for iOS change with iOS updates and app version updates?
A unique Device id - (UIDeviceIDentifierForVendor for iOS - https://developer.apple.com/documentation/uikit/uidevice/1620059-identifierforvendor and IMEI for android(since hardware identifier would be sufficient for our use-case) - https://developer.android.com/training/articles/user-data-ids should be sufficient for my use-case.
Is there any similar way to uniquely identify a web browser or is a persistent cookie the only option to uniquely identify a web browser - Using cookies with Android volley library?
Note: Feel free to suggest any other better way to uniquely identify user devices(if any).
I looked through different questions on stack overflow and browsed through different blogs describing Device fingerprinting and offering services to get a device fingerprint.
I'm expecting to find the best practices around uniquely identifying devices and methods used widely for uniquely identifying user devices on iOs, Android and Web browsers.
I have a few questions regarding ShopifySharp package and Shopify Custom App and Private App.
It has a warning that says:
Some of your private apps and/or admin webhook subscriptions may not work as expected because they are using deprecated API versions.
It also has say, private apps need to be updated before January 1, 2023.
To give you an idea, we created an application in C# built using ShopifySharp. It has been working for years already. It has API Key, password, and domain to connect to, to get the essential data from. It's understandable. Now here comes the confusion. I created a new app in Shopify by clicking "Create an app" in the Settings, putting the name, etc. So, it now says it's a Custom App below the app name.
It made me confused because I don't know if I'm going to replace the old Private App with the new Custom App and use its credentials.
I also don't know if those credentials I am seeing is what I am going to put in my C# application, like the API key and secret key. I don't even know the use of "Admin API access token". I am new this Shopify thingy by the way but I have been developing and updating the C# app but I was just concern on the API key and password in the Private App.
I am also seeing Webhooks subscription default to "2022-10" but I don't know what to do with it.
I already asked the ShopifySharp maintainer but I am not satisfied with the answer. All I have to do it to change the https://myshop.myshopify.com/admin/api/2020-07 to https://myshop.myshopify.com/admin/api/2022-04? Is that all?
We are unsure what exactly will happen with our existing apps that use GCM after 10.04.2019.
We have updated the server-side of our apps
We have new FCM-based versions of our Android apps.
However:
We cannot force the existing users to update their apps
Corporate clients might even continue to roll out outdated app
packages to new users
The information / documentation we found somewhat unclear to what will happen in such cases. Therefore, we decided to put our assumptions into 4 statement and we hope someone will be able to confirm them.
It will not be possible to put apps which use the GCM APIS into the Play Store after 10.04.2019
It will not be possible to generate a new GCM tokens after 10.04.2019
Existing users with existing apps which have already have a GCM token will be able to use their apps normally without being forced to update. E.g. Push notifications and related things will work for them.
A user of an existing app which never created a GCM token will not be able to create a GCM token and thus not be able to use any GCM related functions (e.g. Push notifications and related things). Such a user would need to update to the apps in order to e.g. receive push notifications.
I hope someone can confirm above assumptions.
So i'm building an app on appcelerator that uses Google Maps API to show some information on Maps (for android).. I've read all the tutorials, and instructions from Google Developers Console about requesting an API Key. As far as I know, an API Key depends on a SHA1 Fingerprint of the keystore you're using to test your app. That's just fine, I got my API Key and everything works on my Development environment.
The problem is that my boss, at the moment of testing, can't get to see the maps, I think cause his "dev_keystore" SHA1 defers from mine, so there must be an Authentication problem. (that i know right)
But what bothers me the most is that there is another app that he (or someone on his team) builded, I get that app to my development environment, runs it with his API Key, and it works... even using my dev_keystore i guess...
So my question is: is it possible to create an API Key that works on every environment, regarthless the key_store SHA1 and stuffs ? I mean, how in hell is that API Key configured that works fine on my computer, as well as in his.?
Ok, i figured out what's going on.. The default keystore that comes with titanium studio is the same for every installment of it. So the other developers might have (and the did) created an API Key for those apps with the default keystore, and that's why it is working on every environment.
I bet that when my boss tries to publish that app, it will not work at all. he'll need to create a more app-related API Key, but that's another story to tell.
I'm trying to use Instapaper's Simple API (http://www.instapaper.com/api/simple).
The API terms of use (http://www.instapaper.com/api/terms) says apps should not store user id and password, and I don't want to store them either. However, it seems that the only way to add a link to a user's Instapaper via simple API is to store the username/password (if the user does have a password).
Am I missing something?
The API terms of use state that:
Apps must not store users’ passwords. Passwords may only be collected for the xAuth token acquisition and must be discarded afterward.
Only the full API uses xAuth tokens. The above sentence doesn't apply to the simple API, since it uses Basic HTTP Authentication.
You still "must make reasonable efforts to prevent passwords from being compromised, and must not disclose passwords to any other services or individuals".
If you are using a native Mac application (like Apple’s Mail client or a third-party mail client like Airmail) there isn’t an easy way to save a link to Instapaper without first opening the link in a browser and then using one of Instapaper’s browser extensions to actually save the article.
One workaround that I’ve found to expedite this task is to write a service for OS X which uses Instapaper’s API to save links.
In order to write your own service, first open Apple’s Automator application and create a new Service. Then, drag the Run Shell Script action into the application’s main workflow area.
Make sure the service receives no input, can be used by any application, and that the shell script is set to run python.