I have a paid app and want to offer it as free for a few days in the Store. But only for those who installed it during these special days I want to show ads.
How can I check if a user installed the app in a specific time range?
I thought of these solutions:
I could have a sign in previous packages and check it in this
package. if it was not available this was the first install.
I could save the date after installation since the first time.
But these won't work now.
Thanks.
You can get App receipt from the store (here is how it can look like) and parse the PurchaseDate of your product. However this will return the date when the app has been first installed, if the user has reinstalled the app, then it will return the date of the very first installation (first 'purchase' from the store).
You can also have a value in LocalSettings that will be responsible for remembering the date of first run of the app. But this doesn't mean the date of installation - user can install the app and run it after a month. Also when user reinstalls the app, you will get the new value.
You can use Windows collection API to scope your query to your particular product (app or add-on). After sending request, you will receive a response including an array item CollectionItemContractV6 which contains the parameters like acquireDate and some others which you're likely to use. Then you can unlock the feature to the user who installed your app within the correct time range.
You may follow the steps below to use this API:
Configure a Web application in Azure AD.
Associate your Azure AD client ID with your application in the
Windows Dev Center dashboard.
In your service, create Azure AD access tokens that represent your
publisher identity.
In client-side code in your Windows app, create a Windows Store ID
key that represents the identity of the current user, and pass the
Windows Store ID key back to your service.
After you have the required Azure AD access token and Windows Store
ID key, call the Windows Store collection API or purchase API from
your service.
For more details, you could check Query for products which includes both the request and response sample.
Related
I have pwa blazor .NET 5 app hosted on github. People use this app at work, installed through chrome or firefox or safari on devices. It works offline and updates cache if I change service worker.js and publish it. And all is fine. But how can I manage access for it, since it has to work offline, when some employee resign from work, how can I delete remotely this app on only his devices?
If you're stuck with the pwa offline approach (which, let's be honest, isn't great for security) then the best you can do is encrypt your local storage with a token that's masked only with blazor's built-in obfuscation.
Ideally, you would be able to at least require an externally-hosted identity login when using the app, but if you are truly offline, then obfuscation of an encryption token is the best you can do (if you are stuck with the pwa template).
If you know your users are using windows, you could augment the Pwa with a windows service that provides rotating encryption tokens via encrypted assembles, but that would assume you would be willing/able to do installs of windows services on each user machine, and it wouldn't keep the user out of the app.
Hopefully, you didn't locally store any health/financial info or social security numbers, and you encrypted the local store with an obfuscated token.
Another thing you could do is require logins with an idp server at regular intervals. This would at least keep the window of exposure smaller. You would still be able to work offline most of the time.
I would try the following
On load of app check connection to server.
Validate employee status, if active then store active status check date and next mandatory validation datetime in local storage.
If Not active, Delete data.
If not connected, check local storage for mandatory validation, if expired then force to connect to server.
PWA without local cache is useless, you can delete local cache if validation fails.
Uninstall PWA is not possible from app.
Is there are VSTS REST endpoint I can connect to in order to let a user self-serve themselves another PAT? Ideally a few days before their current one expires. I have a time sheet application that is now connecting to VSTS to get Workitem information and to update said Workitem. However, at some point (90 days, 180 days or a year later) the PAT will expire. I would rather them not have to leave the application to generate a new one and save it in my application at each interval. I would love for them to just click a button to generate it again from my app. It would be secure seeing that I would connect to the REST endpoint with their current PAT.
There isn’t official API to get Personal Access Token programmatically.
You may consider OAuth: Authorize access to REST APIs with OAuth 2.0
I have a Windows Service that is responsible for deploying desktop applications. It detects windows logons, and then should install applications into local appdata, and start menu icons in the correct place.
What is the correct way to find a given user's local app data folder? I have a session id, but no win32 user token.
OK, I solved it.
I was able to retrieve the user token given the session id by calling WTSQueryUserToken.
I was then able to present this token to SHGetKnownFolderPath, which returned the correct path for local app data.
I have a scheduled task to create to get data from a site using the webclient
class. How do I execute a database update with the data retrieved under a different windows user? I was told not to use the same account to access the site as performs the update. Should I just create a windows service that runs the web request then call a db component with authentication settings set under IIS to run under a different user? Or is there a tidier way to do this running a single exe as a scheduled task? The Scheduled task runs under a single user. Could I run the task and switch user for the update? We are using Windows authentication at the database level.
Run two Windows Services. One to get the data from the website, running under Account "A" which stores the data locally. The other Windows Service running under Account "B" picks up the locally stored data and executes the database update.
Other designs will require you to store the credentials somewhere in a config or other file - this way the Windows Services are always running under the correct account for the task they are attempting.
You clearly stated that you will have to use a Windows user to get access to the database. However, often this will not be the case when you authenticate against a web site so exactly how you solve your problem will depend on the details of that.
You should probably execute your process as the Windows user that has access to the database. Then you have to solve how to authenticate against the web site. If the site uses forms based authentication it is a bit complicated but there is an answer to the question WebClient accessing page with credentials that might help.
If you need to use the WebClient.Credentials property to authenticate against the web site you might find it easier to execute your process as the user that has access to the web site. You then need to use impersonation to access the database. A simple way to do that is to use the SimpleImpersonation NuGet package.
In most cases you will have to store the password for one of the users so your process can use it to either log in to the web site or impersonate the user. A relatively safe way to store the password is to use the Windows Data Protection API (DPAPI). The class ProtectedData can assist you in storing secrets so only a specific user on the computer can access the secret (e.g. the password).
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.