I use Firebase Analytics on a mobile app, and try to track user property by advertising identifier. But now I also use appInstanceId for app user identification.
I read the official document about tracking advertising identifier on Firebase and understand about what kind of data we can track.
But I don't understand about the difference of definition between appInstanceId.
Are these two id generated in a different way? (I think advertising identifier is device-specific, while appInstanceId is app-specific. Is it true?)
Can I track the advertising identifier itself on Firebase and check the value of it? (appInstanceId is automatically tracked, and we can export the value to BigQuery)
Yes, advertising identifier is device specific. If you have 2 apps on the same device, they will report the same advertising identifier unless the user set limit ad tracking to true on their iOS device. App instance ID is unique among apps on the same device, and it doesn't depend on the advertising identifier. On iOS, you can get it yourself using AdSupport framework. Firebase console doesn't show you the raw data of IDFA so you might want to track it using custom user property and query it using Big Query.
Related
Currently I am developing a Chrome-GMAIL extension which requires me to get the logged in user's first and last names. For experimentation, I have used the following goggle API (userinfo) and have successfully obtained the names I wanted:
https://www.googleapis.com/auth/userinfo.profile
However, using the userinfo APIs will cause a change in the OAuth2 scopes in my manifest. This change will in turn cause a permission-prompt to my existing users (if a domain wide delegation is not setup in place). Point being the idea of having more prompts in front of my user, or additional oauth scope is not really something I desire.
Currently our extensions use the following OAuth scopes and API :
Chrome's Identity API
Chrome's Storage API
GMAIL.modify
GMAIL.send
My question is, is it possible to get the first and last names using an API that is defined/allowed/provided for by any of the above scopes/permissions I listed? or is userinfo the only way to go?
Thank you very much.
Profile data like first name and last name is private data. You are corect that some Google apis give you access to some data that would normally require an extra scope. For email normally you would need to to request the email scope to get this back however the Gmail api does have an endpoint getprofile which will return the current users email address without you requesting the email scope.
However i am not aware of any apis that will give you access to the users first and last name without you requesting the profile or user.profile scope.
If you do decide to add the scope, I do recommend going though the people api rather then the userinfo endpoint as the data returned by the user info endpoint is not guaranteed to always return the name.
Looking at the Time Zone API quota limit option that says:
"Requests per 100 seconds per user"
Was trying to find a clear definition of user but to no avail.
My intuitive guess it's an IP address... yet would like to avoid unpleasant surprises.
Would be good to know what does user mean exactly. Any ideas?
I believe this is a confusion that comes from the fact that Google Maps APIs share the same developer console with Google Cloud Platform. The "Requests per 100 seconds per user" make sense in Google Cloud Platform, but I don't think they are really supported in Google Maps APIs.
If we check the documentation of Google Cloud Platform we will see the following explanation
To prevent individual users from using up your API quota, limit the number of requests per second per user for an API. Each API includes a default per-user limit, but you can modify that value as described in the previous section.
Individual users are identified by a unique string; if you're creating a server-side application (where the calling code is hosted on a server that you own) that makes requests on behalf of users, your requests must include the quotaUser parameter, as described below.
To identify a user, use the quotaUser=userID parameter. This value is for short term quota enforcement only, so you don't need to use a real user ID. You can choose any arbitrary string under forty characters long that uniquely identifies a user.
The quotaUser parameter is only used for capping requests per user per second. If you don't send the quotaUser parameter, then all calls are attributed to your server machines, in which case calls can't be capped by user.
source: https://cloud.google.com/apis/docs/capping-api-usage#limiting_requests_per_second_per_user
As far as I know none of Google Maps APIs support a quotaUser parameter, so this value doesn't make sense for Google Maps web services and as mentioned in the last paragraph Google Maps web services will attribute usage to server machines. In other words to IP addresses of your backend servers.
I hope this clarifies your doubt.
Here is what I am planning to to for keeping separate tokens for web and mobile
1.When user is logged in from web JWT token is issued and it is stored in DB table with created time stamp.
The above step is repeated for the mobile client ,so the table contains separate tokens for each client.
2.At the time of validation search for the token in table and validate if exists then it will try to verify with JWT.verify
Is it right method to do keeping separate logins using JWT??
Maybe there are other ways to do it, but your approach is totally correct. By fact I would recommend it exactly your way. What you doing, is scoping issued token for specific service, platform. It is useful not only for your use case, but also when you have multiple APIs. You can issue different tokens for each service separately.
I have two application both of them send toast notifications, I want to detect the Toast Notification from the particular application.On search I findpublic ToastNotificationHistoryChangedTrigger(string applicationId),what would be the application ID during development?
What would be the application ID during development?
Here is the MSDN documentation for the parameter:
The identifier of the app for which you want to create an instance of
the ToastNotificationHistoryChangedTrigger class.
More searching on MSDN, here is more info about application identity, which will appear in the package manifest:
<Application Id = An ASCII string between 1 and 64 characters in length.
The unique identifier of the application within the package. This
value is sometimes referred to as the package-relative app identifier
(PRAID). The ID is unique within the package but not globally. There
may be another package on the system that uses the same ID. The same
ID cannot be used more than once in the same package.
So it means both applications need to exist in the same package. I don't know how is that possible right now and I doubt that it is your case. Most likely, you have multiple packages, one for each app. In this case, you can use AppServices to communicate between the two apps.
Edit
Here explains about multiple app packages, it is supported for side loading and not the store.
You can create a multi-app package for side-loading, just not to
deploy through the store. When the user installs the package they'll
get all of the apps, and the apps will all share the same security
context, local data, etc.
I am trying to understand what is the intended use case for app auth and app users. Im basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I hope this makes sense. Any assistance would be appreciated.
Thanks.
App Auth and App Users -- which is officially called Box Platform -- is essentially a white-labeled version of Box. I think of it this way: "Box" as we know it is software-as-a-service. It offers a web app, mobile apps, and all the trimmings. Box Platform is the platform layer upon which the SaaS is built, providing API-based management of users/content/comments/collaborations/etc. With Box Platform you have a walled garden in which you can build apps that leverage all the features of the APIs, but are not otherwise "Box apps."
I'm basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
This is an appropriate use case. With Box Platform you will be the owner and administrator of a Box enterprise and all the accounts and data contained within.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I think it's generally cleanest to create unique accounts for each user as opposed to giving users a special subdirectory in the admin account. From there you can use the App Auth workflow to get an access token specific to that user.