headless connections?

When the demos connect, a separate browser window is opened that you must manually log into. If it's my back-end service that's connecting to myCloudData, there's nobody watching for it to login.

How can an app connect without human intervention?


After a one-time authentication you can save the retrieved access token.
With a valid access token you can access the myCloudData service without needing to login and authenticate.

Is there an example of the code needed to do that?

My use-case is simple: I'm building a web app using WEB Core and I need to save user-specific state data -- stuff that would otherwise go into an INI file or the Windows Registry. But users can run web apps from any device they have handy, so you can't save that data on the device; it has to be accessible from a common place.

Fortunately or unfortunately, it does not need to be directly accessible by users.

In my situation, users will connect to my back-end, and it will do the authentication and verify that they're registered, paid-up members, handle billing, payments, and all that stuff. So my back-end will be the only "user" accessing this data on behalf of my members.

Anybody building a web app needs something like this. But I'm guessing they build the membership DB on the same server as their back-end, so it's not a problem. I want to keep them separate for now because I'm building my MVP and I don't want to have to reinvent the wheel just to get it going.

There are membership management services available; the problem is they either: (1) require all of the fields to be accessible via their UI, which is like saying someone gets to see everything in the Windows Registry just because that's how it was designed; or (2) you have to create a separate embedded DB (eg, myCloudData .net) to track this stuff indepently but have it tied (via a "foreign key" of some kind) to the service that's managing all of the rest of the membership data.

Or (3) do it all yourself from scratch -- which is what I'm trying to avoid right now.

Do you have any particular suggestions as to how to implement a bunch of INI files or something like the Windows Registry on myCloudData that my back-end can use without having to risk getting disconnected or out-of-sync with my membership service? (I can use a common key like their email address or phone# plus some 'salt' that's hashed.)

Assuming you are using TTMSFNCCloudMyCloudData in combination with TMS WEB Core you can use SaveTokens and LoadTokens to persist the access token in the browser local storage.

procedure TForm1.FormCreate(Sender: TObject);

procedure TForm1.TMSFNCCloudMyCloudData1Connected(Sender: TObject);

Alternatively you can get/set the current access token through the Authentication.AccessToken property and persist it manually in a preferred location.


You're explaining how to solve a totally different problem than I'm asking about.

The web client only talks to the XData service.

The XData service is talking to a bunch of different back-end services, including possibly myCloudData.

There is no browser running on the XData service, and nobody to login if there was. Ever.

I could implement INI files directly on the XData side since it's running in Windows. I'd rather keep the data in a separate data store, preferably wherever the user's profile data is being saved. But this seems to be unlikely, so that's what I'm looking at myCloudData for.

This is what I've been trying to say about forcing a UI to sit on top of an otherwise embedded DB. My application needs a "headless" DB with a REST API instead of an IP:port# socket interface.

You can retrieve the access token in a separate app with user interaction once. Save the token and use it in your server application without the need for user interaction.

How do I get it and save it for use in another app?

Why is there both a key and a 'secret' key if all you ever use is the key and a token?

In TTMSFNCCloudMyCloudData, for example, the access token can be retrieved from the AccessToken property after authentication:


The secret key is required for desktop applications.

1 Like

Great to know. Thanks. I'll give that a try.

You might consider adding the ability to get a token for embedded use from the UI rather than the way you describe. It seems a lot more straightforward.