Can I get the team_id for a user using app store connect api? I have looked https://developer.apple.com/documentation/appstoreconnectapi/users but don't see anything. I don't necessarily need it for a specific user but the team id related to that particular app.
The App Store Connect ID works via issuer-id and no longer exposes old / legacy identification like team_id or portal_team_id similar to how fastlane uses it via web authentication: https://github.com/fastlane/fastlane/blob/48151291f2c4949c3b1b9919ba2cc81a7cc33293/spaceship/lib/spaceship/portal/spaceship.rb#L42
An ASC API key is only ever valid for one team, therefore in the API logic it should also not have access to that information.
Related
I'm pretty newbie in iOS development but I'm trying to figure out how to organize the authentication. I need the authentication because of 2 reasons:
In-app purchases
User can add his or her own data into common database.
I supposed that as soon as user downloaded my app he or she will be easier to use the Apple id to authenticate but I have no idea if it's possible to use Apple id in this situation and how to organize this authentication on my server.
For information: I'm going to use Node.js as a backend with MongoDB, hosted on Windows Azure portal.
The workflow is:
User downloads and runs my app
User uses it (without any authentication so far)
If user wants to add his new data and share it the data should be
sent to the server and user must enter some credentials.
User enters Apple id credentials (and user name under he wants to
share data?) and sends his data to the server.
Further if he wants to do app-in purchase he uses the same
credentials.
If it's even possible? If I can't use Apple credentials to send data to my server, if it's possible to use other credentials (my email, or OAuth) to make app-in purchase? I don't like to idea to make user enter different credentials twice.
Thanks!
I am creating an iOS app for internal use. We have a Google Domain. As part of the functionality of the app, I want to be able to search for all users in that domain. This can already be done in Gmail, the Apple Mail app, and others.
I found that you can use the Admin SDK for users.list to do exactly what I want to do. I created a Client ID for the iOS app and authorized my app to perform users.list.
However, now I get a permissions error for users who sign in with OAuth2:
I found that you can create a service account to make API requests on your behalf if you delegate it to have the authority. I'm not sure if this is what I want to do since this seems more like something for a secure server to do rather than an app. I'm also not sure how this integrates with a user (from our domain) who signs in with OAuth being able to list our users.
Is it possible to list/search the users in a Google domain purely through OAuth / frontend app?
Aside from caching your own list, I think there are two ways to give users the ability to list all users:
A. Undocumented call to this GAL API:
https://www.google.com/m8/feeds/gal/your-domain-goes-here/full?alt=json (source). You can test this in the Google OAuth Playground by selecting the scope for the Contacts V3 API or using the string https://www.google.com/m8/feeds/.
B. In the Admin console, create an "all users" group. Assign to a newly created Admin Role. Grant the admin role "read" in Privileges > Admin API Privileges > Users > Read (checked).
I am currently uniquely identifying a user by storing the FacebookID of that user. I recently read around and I saw that this is incorrect usage and that Facebook ID's can change for some reason, all in all that I shouldn't use them. Is this true? If so, is a AWS Cognito ID that is derived when a new facebook user signs in and authenticates themselves a viable way to uniquely identify a user? If not, How would I uniquely link a facebook account, with apparently no variable that is stable enough to store, with a unique identifier to store in my database?
Check the following statement (from the official documentation: https://developers.facebook.com/docs/apps/upgrading):
No matter what version they originally used to sign up for your app, the ID will remain the same for people who have already logged into your app. This change is backwards-compatible for anyone who has logged into your app at any point in the past.
So, you can use the Facebook ID to uniquely identify your users.
However, depending on your use case and the way you plan to manage security, you should consider a few more things. The purpose of AWS Cognito ID is not to be communicated between users, it is kept between your app and Cognito. So if you want users to communicate using their accounts (sending text messages for example), the Facebook ID is more suited for that. Nevertheless, I am experiencing this problem when trying to achieve fine-grained access control using DynamoDB.
As Hatim said, the Cognito identity id is not meant to be shared between users.
That being said, once an identity id has a login associated to it, it could only change on merging with another authenticated id. Unless you're doing that, which it doesn't sound like you are, it would be a stable way to identify your users. You could use the identity id as the identifier in your database, as long as it isn't exposed.
If you're using DynamoDB, as this blog post explains, doing it this way allows you to configure your IAM roles to make access to this data more secure.
Currently I have configured Quickbooks online API functionality for single user. which gets customers/bill information from quickbooks online using OAuth. It is working perfect.
I want to do the same functionality for multiple users.
Now there are many user's of quickbooks who have their own quickbooks online accounts and all these users are present in my custom application.
Is it possible to setup API functionality using keithe palmar's dev kit for different users to have API access? which things needs to be configured to make it run?
Is it possible to setup API functionality using keithe palmar's dev kit for different users to have API access?
Yes.
which things needs to be configured to make it run?
There is a variable $the_tenant that needs to be unique to each separate QuickBooks Online company you want to connect.
If you're building a multi-tenant type SaaS app, then you probably have a unique identifier for each of YOUR tenants already. So, set $the_tenant to your unique tenant ID value.
Done. That's all you have to do.
Relevant code:
// The tenant that user is accessing within your own app
$the_tenant = 12345;
https://github.com/consolibyte/quickbooks-php/blob/master/docs/partner_platform/example_app_ipp_v3/config.php#L57
All of the OAuth stuff is stored/based on that $the_tenant variable, so just make sure it's set to your unique tenant ID, and you're good to go. Note that you'll have to connect each individual QuickBooks company separately.
Keychain access groups and application groups are both segregated using the app's team id.
Named pasteboards are also sandboxed using the team id.
Kerberos SSO seems to work well, but opening the KDC to the internet is a security hazard so it can only really be used together with a VPN.
The Shared Web Credentials API works well between native apps, but has intrusive popups showing up every time you attempt to access or even just check for the existence of credentials.
libdispatch can send messages to arbitrary apps, but the payload is limited to 64 bits and the recipient app must be currently running.
No unique device identifier that could be used to derive a key for a cloud-based encrypted KVS can ever be shared between apps not on the same team id.
…is there any way to share credentials (or any data, for that matter) between applications signed with different team ids, on recent versions of iOS? Apple doesn't allow migrating IAP, Passbook, etc to new team ids and it's blocking my team from implementing SSO between apps with historical team ids (M&As, etc).
You can open the app with deeplink that will reopen the other app with the infos you want to pass along. That's good for login but can be cumbersome if you want to pass a lot of infos back and forth.