I need unique id to save user purchases to my database. i dont need device id because if user change microsoft store account then device id will be same to previus.
I want to a leaderboard to most users purchases but i dont know him id if user change own device .
The best you could do would be to have their app call StoreContext.GetUserCollectionsAsync from the UWP app on the user machine, then forward these results to your services. This isn’t really all the purchase, but is all the things the user currently owns.
Or, using your UWP app again, just keep track of it immediately after the purchase succeeded. But I don’t think there is any way to look up their purchase history directly.
A more complicated solution would be to use the B2B APIs. This would allow them to query the collections service directly from their service. This is probably the closest to what you are wanting. The token that get back would be unique to the user (not device).
Related
I am using office 365 credentials to login to windows 10 machine. I have written a desktop winform application in c# where I just want to get email address and ad group assigned to that login user.
I don't want to relaunch login from desktop app. Just want to use existing user info to get email address and user groups. I am only able to get local groups assigned to that user but required AD groups too.
You must throw login challenge from your desktop app at least once to get the auth token to be able to query graph api (details in the next para) and keep the token cache so that it does not prompt the user again next time onwards. There is no other way I am aware of. You need to create a native client app in AD (or if you want to reuse some existing one, that will do too) and grant Graph API user.read permission to it. Here is an end-to-end guide for that. https://learn.microsoft.com/en-us/azure/active-directory/develop/tutorial-v2-windows-desktop (well, the example is for WPF, but Winforms would be very similar except the XAML part). If you follow this example, the login screen which will show for the first time will automatically have O365 Windows logged-in user populated (because of .WithPrompt(Prompt.SelectAccount) part in the bootstrapping) if that gives a bit of relief to you app users.
Once you get the access token, you need to query Graph API for that. Here is the programmatic way (C# based on your tag in the question) to get the user details for a logged in user (me) and to get the user groups for the user (me).
I am new in the software development world. I have built a C# application that will require to keep track of user progress on a certain task and possibly integration of payment processor. I have seen Auth0 implementation requirements and I am able to implement it on my app. But the problem is- Auth0 gives user token and basic information like names on its example app, but what should I do with these data?
To keep track of user progress, I will need to implement a way to store data on a server probably in firebase. But should I use that Auth0 information to create a new users and update their progress? I don't know how to use token to create a user on firebase or at least to keep track of within the app.
Please give me a direction on how should I create and keep track of users with Auth0 given tokens or other information? Can I use Auth0 tokens to identify the user without using a server like a firebase?
Or is there a better way of combining these? Like firebase login with user creation? But how do I add a payment processor then? How the payment processor will combine the firebase user database and can process payment to the right user?
I have no idea about this and posting on different sites gave me no answer, so posting on the best possible site for this. Any information would help.
You can use the user_id from auth0 to retrieve the relevant info from your database.
Typically, the user will log in, the token will be issued from auth0, validate the token, then use the sub claim (the auth0 user id) to store and access data in your user db. This id can act as the connection between your db and auth0's database.
I am building MVC C# webapi backend for my mobile app, which uses one's Facebook/twitter/Google account to signup. Now, I want to get friends list corresponding to individual's account who are using same app.
Well this is where my problem starts, would I have to pull request every time or will I have to manage a table for this purpose or is there some other best practice.
Any help/guidance would be appriciated
Once you create a App via the facebook app you can use FQL to get the names based on your applications id
Something like
SELECT uid, name FROM user WHERE is_app_user AND uid IN (SELECT uid2 FROM friend WHERE uid1 = me())";
You you basically use the facebook API to make a request to facebook which will return a JSONArray, you can parse out that a array to get a list of users.
Here is a very similar question
Facebook API friends who use same app android
I'm familiar with the Facebook API. Take a look at http://developers.facebook.com. First, you need to request permission from the user to access a list of his friends. Once you have that, you can query the open graph to get a friends list. Take a look at the documentation on permissions to learn how to request permissions and which permissions you need to request.
You could create a cache and store it locally. However, this data will change. If you do cache it in your own system, make sure to invalidate it regularly and refresh it. I pull the data each time I need it, and cache it just for immediate use.
I need to implement Single Sign On for two different C# Windows Forms apps
Do you know a good framework that does this ?
When a user logs in, you can also store in the Users table some unique ID of the PC (e.g. PC name, IP address, ...), on which the user is working. Every time an SSO-capable C# app starts on some PC, it can check in DB first whether the ID of the PC is present in the Users table (in the record of a logged-in user). If yes, then it can skip the login form, and e.g. show the name of the user it found as the current one.
You can set the granularity of the SSO to any level you want. For example, if a subnet address is stored in the Users table, then the users of the PCs in this subnet have to log-in only once. If the GUID of the current Windows user is stored, then logging out of Windows and logging in as a different user will require another log-in to the system.
I don't know of a framework. Here's a guidance page from Microsoft that outlines the overall strategy to use: http://msdn.microsoft.com/en-us/library/ms972971.aspx. Hopefully it can help get you started.
Am I able to get the current call history with the call number and DateTime details from the phone with the Mango API? I think it is not possible with the current one.
There is no API to retrieve Call History. This is mainly due to privacy concerns and protecting the user from nefarious applications behaving badly on the device.
You will notice that among the API is a collection of Launchers and Choosers. One of which is the PhoneNumberChooser Task. This particular task launches the Contacts application and allows the user to physically select a contact number to dial from your application. You'll notice this requires a manual interaction from the user. Many of the data retrieval APIs require manual selection from the user, once again to protect the user from applications doing bad things. For example, trolling your contact list in the background and sending that data to a web service without the user's knowledge.
Special care was given to the API's to protect the user from these types of scenarios.
If you have feedback on the need for an API to provide a Call History Chooser, submit your feedback to http://wpdev.uservoice.com.
If Marketplace screens apps for behavior, and if apps have to declare what they do, and if users have to opt in to allow an app to get access to this information, it would seem reasonable to give app developers and more importantly users the option to decide this. And if there is still fear about this, then the OS could pop up a user response screen to permit or deny the action when an app requests to do so. There are many applications that could benefit from knowing this information to save the user from having to enter information from the current call when it could be easy for them to permit an application to get the data.