According to the Apple In App Purchase Programming Guide:
The App Store creates a separate transaction each time it renews a subscription. When your application restores previous purchases, Store Kit delivers each transaction to your application.
Let's imagine my app subscription is client-side-only (no server component). The simplest way to verify that subsequent renewals have been billed seems to be restoring previous purchases every month.
However, this pops up the user's iTunes password prompt every time you call restoreCompletedTransactions which seems like bad user experience. Is the only recourse to use the server receipt verification code (along with the new "shared secret")?
The App Store calls the paymentQueue and posts a transaction each time it auto-renews. The transaction is posted with transaction.transactionState==SKPaymentTransactionStateRestored.
The issue is that unfortunately this gets posted only to one device. A second device does not get the posting. Therefore, to detect the auto-renewal, or rather to detect the lack of an autorenewal and deny any device a continuing subscription, you have to do a restoreCompletedTransaction or "http post a 64-bit encoded JSON containing the last transaction". If the fomer, the user needs to give their password; and as you point out, that's intrusive. If the latter, lots of additional coding is required. So, my question in answering your question is...why doesn't StoreKit have a command:
(does not exist) - [[SKPaymentQueue defaultQueue] restoreAttachedTransactions:(NSArray *)transactions];
This command would flow just like a restoreCompletedTransactions but it would only restore the attached transactions and, most importantly, it would not require log-in by the user. It has the same security protection as the "http post a 64-bit encoded JSON containing the last transaction" and it allows the entire In App Purchase process to be done in StoreKit rather than requiring web posting code.
If this makes sense to you, please suggest how to get this to Apple....thanks.
If you have no server component, the only place you can store this information is in a local file/database/config
The restoreCompletedTransactions option is there for when there is something wrong with your local database, you should put a button somewhere on your advanced settings panel to restore all previous transactions.
So, you will have to trust the data you store locally. Normally, this is safe as you cannot change your local filesystem (unless you jailbreak). If you don't want to trust your users like that, you can optionally encrypt it...
Related
So for the login, since it doesn't really make anything new in the database but rather just returns if we've logged in, and possibly some user data, should it be a command or query?
And as for the register, since it creates a new user, should it be a command then? What if i want to return the users data or a jwt?
Should i run my commands and once the client receives a response run a query right after them?
As with most design related questions, I’d answer this one with ‘it depends’. I have seen both solutions implemented in different situations.
The main question you’d need to ask is whether you consider a user logging in as a state change of the system or not. Note that whether it changes state in de database isn’t relevant. The system is more than the database.
Log in as a command
For some systems, it’s important to know which users had been logged in and when, from where, etc. One example I had seen was a medical system that needed to record which doctor logged in when and where, and which medical records had been accessed. Also, logging in on one machine would stop tbe session on another. A reliable trace of these actions was essential to the application. As such, log in was implemented as a command which generated events that were stored in the Event Store. Projections kept the current logged in state for each user.
Log in as a query
Most systems I have seen, however, simple beed to know whether any given credentials can ve mapped to a user account. If that is the case, a token is generated containing the ‘proof’ of authentication. The system itself doesn’t really care who is logged in. It’s just that each request needs to be validated by checking the ‘proof’. In this case, logging in is a query.
I am trying to implement a hardware busy light to show my Microsoft Teams presence so that my family to not enter the room I have the office while I am in a meeting. I am looking to implement something similar to:
https://www.eliostruyf.com/diy-building-busy-light-show-microsoft-teams-presence
https://blog.jongallant.com/2014/12/beakn-v0-1-diy-lync-status-light/ (older acticle - similar idea).
The only problem I have with this setup is that I cannot get the MS Teams status.
The best way to go is by using MS Graph Presence API but my problem is that this is a company account and I don't have (and there is no way I could have) and app in the main subscription granted with the required scope: Presence.Read.
So I tried different ideas but none worked in the end:
check local running processes
check if MS Teams exposes any local API
check if there is a CLI available
This seems a simple idea, I mean, I see the status right there now while I am typing this message, I could as well do an app that gets a screenshot of the taskbar and extract the status from the icon, but is that really the only option I have?
I think I found something interesting for you.
Go to
C:\Users\user\AppData\Roaming\Microsoft\Teams
you'll find a file called logs.txt
In this file you see if your current state changed
(current state: Available -> DoNotDisturb)
I would write a script with php or VB (depends on your skills) that read that logs.txt file like every minute and check for the last "current state" line.
What those posts are doing (certainly the first one, I didn't check the 2nd one) is calling the Microsoft Graph, which has a "presence" endpoint to get a user's status. There's actually even a specific "/me" endpoint, to get your own personal preference (less access rights needed). See more about this here: https://learn.microsoft.com/en-us/graph/api/presence-get?view=graph-rest-1.0&tabs=http
In order for this to work, as you've mentioned, you do need to have an Azure AD App registration. However, importantly, this will only require "delegated" permission (i.e. only permission from the single user, you, to access just data for that single user, you). As a result, you can use "delegated" and not "Application" permissions, which means that it does -not- require Admin consent for the tenant.
It -does- require and Azure Add Application though, at the risk of stating the obvious. While you don't have tenant admin rights, you need to see if you have Azure rights, just to create an application (you might have this anyway as a developer in your org). If you don't even have this, you can sign up for an M365 Developer account, and use that tenant. Importantly - the application does't have to be in the same tenant. If it's not, it's just a simple multi-tenant app, like any 3rd party Azure AD-backed application is.
the last couple of days I implemented the autodiscovery/auth flow for UCWA against Skype for Business Online and AzureAD. When I'm done and having the URL to the application directory (+ the OAuth2 Credentials) I save those into our internal system. So later on I want to create online meetings with this data. The URL to the applications directory looks like this: https:\/\/webpoolam42e10.infra.lync.com\/ucwa\/oauth\/v1\/applications\/101331226048\/onlineMeetings\/myOnlineMeetings
If I do this within the first minutes of retrieving the data it works just fine. But later on it seems, that the application directory is gone. I'm getting this response:
body":"{\"code\":\"NotFound\",\"
subcode\":\"ApplicationNotFound\",\"message\":\"An error occurred. Please retry. If the problem persists, contact your support team.\"}
Status Code is 404.
Later on I even tend to get 401 errors that mean unauthorized.
I suspect the application server going away and only being temporarily available. I got a refresh token and a valid access token, so this wont be a problem. I've got no clue what is going on there and wasnt able to find help in the docs. So maybe one of you got any advice - I'd be really thankful!
Side-Info:
I'm doing all this in PHP and I only have user-interaction at the initial authentication. I save the refresh token and all other things I need, so that my server-side application can use the authorization in long term.
Reporting here part of my reply to another question:
Keeping a UCWA App always online:
If you need to achieve that, you need to understand and implement correctly the concepts explained here me Dashboard, especially at Reporting activity section:
call reportMyActivity every 4 minutes max.
maintain an active P-GET with the Events Channel
handle possible timeouts on the Events Channel
handle possible DELETE events (on the Events Channel) the server can send for the application, for which you'll have to regenerate your app Application dashboard
reporting app's activity, and keeping a valid open P-GET with Events Channel are both very important!
I have been following your project for quite some time now and am intrigued by the functionality of gunDB where it doesn't require a database in between and keeps security in check.
However, I've got some questions about GunDB which I've been thinking about for quite some time now before I can give Gun a go with a project I'm currently working on. In this project it is necessary that data is safe but should also be shareable once a group has been setup. The project is a mobile app project and ata is mostly stored on the device in a SQLite database.
I have been looking into Gun as it allows for better usage of the app in sense of collaboration. The questions I have, however, are:
User authentication
How is user authentication handled through private keys? So how can a user "register" with, for example, a username and password to login to the service.
For authentication I am currently using Firebase where it is possible to use username/password authentication and I would like to know how Gun approaches this case and how it's implemented.
Data storage
In the documentation and on the website it's stated that data is stored locally with every client and can be stored on a "node" or server using either a local hard drive or the Amazon S3 storage option.
What I am curious about is what data is actually stored at the client? Is this only the data he/she has access to or is this a copy of the whole dataset where the client can only access whatever he/she is granted to have access to?
Maintaining your data
When I've got a production system running with a lot of data, how will I be able to manage my data flows and/or help out my clients with issues they have in the system?
In other words, how can I make sure I can keep up with the system if I want to throw in an update and/or service my clients with data issues.
My main concern is the ability to synchronize their local storage correctly.
Those are all my questions for now.
Thank you very much in advance for providing some clarity on these subjects.
Best regards,
(Answered by Mark Nadal on Github: https://github.com/amark/gun/issues/398#issuecomment-320418285)
#sleever great to hear from you! Thanks for finally jumping into the discussion! :D
User Authentication,
this is currently in alpha. If you haven't already seen these links, check them out:
https://github.com/amark/gun/wiki/auth
http://gun.js.org/explainers/data/security.html
https://github.com/amark/gun/blob/master/sea.js#L23-L43
https://github.com/BrockAtkinson/login-riot-gun
If you have already, would love to either (A) get you to alpha test and help push things forward or (B) hear any specific questions you have about it. This thread is also a more at length discussion about alternative security API ideas: #321 .
Data storage.
Browser peers by default store the data that they subscribe to, not the full data set. You could ask it to store everything, but the browser wouldn't like that. Meanwhile NodeJS peers, especially if hooked up to S3 or others, would store all data and act as a backup.
Does this make data insecure? No, encryption should keep it secure, even if anybody/everybody stores it, the encryption makes it safe. (See [insert link to (1)] for more information).
Maintenance.
You would service your customers by deploying an update to your app code. It would not be ideal for your customers if you could meddle with their data directly. If they wanted you to do that, my recommendation would be that they change their password, give the new password to you, and you login and make any necessary changes. Why? Because if you have admin access to their data, their privacy is fundamentally violated.
I have built a social network/dating type application on the AppEngine and am currently in the process of adding a chat built on top of the Channel API. However, the problem that I have is that users may reload or navigate to new pages while the chat is going on (as they can in Facebook). This means that the server doesn't easily know if it should generate a new channel ID token for a given client, or if a given client has already been assigned a channel token.
It would be extremely useful if there were a way to check (server side) if a particular client already has a channel open. For example, if I assign a client "Jack" a channel ID of "Jack-Jan-21-2010", then I would like to be able to check on the server side if there is already a channel open associated with the ID "Jack-Jan-21-2010". This can be (sort of) tracked on the client side by watching for an onerror() and onclose() callback, but I can't see anything server-side that allows me to just check if a channel associated with a given ID is already open.
Does anyone know an intelligent way to check (server side) if a channel has already been opened, while using the AppEngine Channel API?
Part 1: Solving your problem
See Part 2 below if you really need to track client connections, but I'm not sure from your question if what you're asking for will solve your problem.
Let me see if I can echo your problem back: you're writing a chat app, but it's for a site which isn't fully AJAX (in the way that, say, gmail is); the site contains page navigation where you may need to re-set up your channel after the user clicks on a link to another page. When the user navigates, the new page is rendered, and you want to avoid getting a new token at that point; you want to reuse the existing token and channel with the same client-id.
If that's correct, I have two alternate solutions, one easy but with not-great user experience, one trickier but with a much smoother end result.
Preserve the token in a cookie. When you re-render your page, just use the token from the cookie instead of calling channel.create_channel again. When the token expires you'll get an onerror callback just like if the user had stayed on the original page; at this point, call channel.create_channel again. The problem with this is that re-connection can be slow (up to 10 seconds or more in bad cases) because of the nature of Comet connections.
Wrap your entire site that's not chat-related in an iframe. Put your channel creation code and UI in the outer iframe. This way you don't have to re-connect every time the user navigates. This avoids the downtime on navigation. Note that orkut uses this technique, with floating divs, as a small amount of Firebug investigation will reveal.
Part 2: Your feature request
If it turns out I'm misunderstanding and you really do need to track client connections:
There's not a built-in way to check if a client is connected to a channel identified by a client-id now.
However, I am working right now on adding "presence" (in the chat sense) so that your app can register to get a post when a client connects to or disconnects from a channel created with a given client id. You also might be able to "probe" presence, to query whether a given client id is connected or not (still working on the details of this part).
Note that this won't be token-based, but rather client-id based.
I don't have a definite release date for this yet but as I said I'm actively working on it right now.
In the meantime, you could use a heartbeat HTTP request from your client back to your app that says, "hey, I'm still here" every minute or so. You'll need to have some sort of task that runs every, say, 2 minutes and marks any clients that haven't checked in as inactive, and you'll need to store this data someplace.