I'd like to hear some thoughts on ways of charging for saving data, but not the app

Web apps are generally stateless. I have built a nice little card game of sorts that I'm starting to add some personalization features to. But if I save everybody's config and session details, I need a back-end DB of some kind to put their data in that's secure and only accessible by them. It's mostly historical data from each session -- the game, the cards that were dealt, notes and outcomes for each session, and only for the game's "owner". This isn't like Twich where people might be watching your games. It's more personal stuff.

Obviously, without a bunch of support for logins, authentication and such, there's no way of managing individual sessions.

What I'd like to do is offer the generic app where anybody can play it, but nothing can be saved. Alternatively, they can pay a small monthly fee (eg., $5/mo) to allow their data to be saved somewhere. I also might want to include the abliity to print out some nice reports if you have a subscription as well.

One way is to add a login and back-end DB and all that stuff. But I was thinking an alternative might be to simply allow access to files saved in a personal cloud account, like Dropbox or Google Files. That way I don't need to do as much to integrate it other than enabling them to access their own back-end storage accounts from the app. But I'm not sure if that means "if you're in for a penny then you're in for a pound" in terms of security stuff.

FYI: Most of want needs to be saved would simply be text, either notes or JSON packets. I don't need a bunch of structured data or ways to query it.

Is there a simple way to manage things so I don't need to extend the app to do all of the login and auth stuff, but maybe just access a remote DB that they can use to access their cloud account data? I mean ... can I let something else handle that without having to fully integrate security into my app?

It depends I think largely on what your motivations are.

  1. If you're looking to generate revenue and using these extra reports and cloud saving as a feature worthy of a subscription, then you're going to likely want to go the login model as that affords you a number of other key capabilities, like tracking users and payments, and is generally an acceptable route to take.
  2. If you just want to give them an option to save, for free, using localStorage is acceptable, as is the option to download/upload their data. Sounds like there isn't much in terms of size or complexity, so this could be an easy thing to implement.
  3. If you're looking for a way to implement a DB to store the data and would rather the user provide the DB than you, well, there are things like iCloud storage and others, but for 99% of people this is all handled by apps (native apps usually) behind the scenes and they aren't any the wiser for it. For the 1% that know enough about cloud databases to provide you with suitable login credentials to those databases, well, divide that number of people by the number of cloud databases available, and then take the number you're willing to support for such a mechanism. It's likely to be an astonishingly small number.
  4. If you're looking to find a cheaper/simpler way to host a database that your TMS WEB Core app can use, then it seems like the new StellarDS service might be of interest.

How far down the path you go as far as login credentials and authentication is ultimately up to you. If you're asking them to pay then I think there's a reasonable expectation of a proper login sort of thing to safeguard an account. It might not be data that ultimately needs the highest levels of security, but it should be still treated as if it was valuable - or people wouldn't ever pay for it.

I'd consider a small PHP script on the server that you POST the data to store to, using a simple TWebHttpRequest in your web app. The PHP script just stores the data in a local json file. Let me know if you wish me to further elaborate on this.

I do this for saving state data for my apps, but I don't see how it solves the problem I'm looking at since the app would need to maintain a membership list and do auth and verification and all of that stuff anyway.