Best way to support multiple users safely?

I'm noticing that building a WebCore app may not be as simple as building a Windows app. A Windows app runs inside of a user-specific environment that you can assume is protected from other users simply by how Windows works. (Users login, and whatever they have access to is whatever they have access to, and nobody else usually does.)

You can tell Windows that a given app can be installed "for all users" or just the given user, but I have not run into issues in treating them differently since most people don't share their computer with others and would not install stuff "for all users" if they do.

But by their nature, WebCore apps are accessible by everybody!

I'm not totally clear if the user's state data is supposed to be loaded up and managed entirely in the browser at run-time, but saving it the same way you do in a Windows app on the server side won't work for multiple users.

So what's the best way to manage user-specific state data in a WebCore app that's simple, easy to use, and safe enough that you don't need to worry about hacking or cross-access of data?

I've got the WebCore book, but I don't recall reading anything about this topic in there.

Where is your data? When on the client, the browser takes care of isolation and cross application data access is not possible.
When your data is server side, you implement server side a login with authentication & authorization and communicate a user token along all further communication to the backend to identify the user for which data will be stored.

Hmmm ... I feel like you just rephrased my question. Or maybe I wasn't very clear.

"In the browser" does not equal "on the client", right?

So if I'm using a web app built in WebCore and I move between machines, and I want my "user state" to follow me, then it can NOT live "on the client", correct?

This is distinct from switching browsers on the same client machine, because then the data CAN live "on the client" if saved outside of the browser's footprint -- eg., in a generally accessible file or db rather than, say, in cookies.

The file itself could live in Dropbox or something similar, offloading the authentication and related stuff to that service.

You guys offer you myCloudData service, and there are similar platforms that could be used as well. They offer a more structured data-centric approach than something like Dropbox.

Other than that, what's the simplest way to set up the authentication and everything needed to access my data "in the browser" if I want to be able to access it from different machines? (From the server side, using WebCore)

What I'm trying to get at is this ... WebCore doesn't really need anything but a web server to run. If it's going to use DropBox or some other hosted service for data storage, then nothing else is needed.

But if it's going to do something equivalent to, say, using an INI file on the server side, what sort of support on the server will it need to do that? Is it easier to just use an existing hosted service? Or set up something directly? It seems to me like there ought to be a drop-in component that implements something simple like this. Is there?

(I know all of these approaches are possible ... but from a practical standpoint, how might you decide which way to go?)

Yes, for long time Delphi users, all that Web stuff is very confusing. I feel your pain because I went through the same...

Web Core in the first place is a tool to provide a "thin" (Delphi speak) front end app, which is loaded from a web server and displayed in a browser. As with a thin Delphi app, you in almost all cases need a backend server, that provides most of the application logik. Typically, on the server side you use something like PHP to provide the application logic or any data persistence layer, like e.g. accessing a database. You normally do not and mostly cannot access a DB directly from the client browser app. This has nothing to do with Web Core. Instead, you use a communication mechanism between the browser and your backend server, which typically is based on HTTP request/response pairs. See my other post to you with regards to this topic.

So, in order to track a user and his data, as Bruno already explained, your server program (e.g. an application written in PHP on the web server that is) provides a JSON based API to login the user with username/password. Your server should answer with an access token, that is from now on valid for so long to acces the other API functions. One parameter to all other API functions will the be that access token. The other API functions then e.g. can provide the data persistence layer (google for "CRUD" for more info on that) you need.

Now, based on how the Login API function is implemented, when another user on another machine in another browser logs in with the same credentials, based on your logic needed you either respond with the already existing access token for that user such that the two logical users share the same logical session on the server, or you respond with a fresh access token sucgh that the second person/browser works in its own session.

There is nothing from TMS Web Core that supports you in implementing the server side, except for a product called XData, for which Web Core has components to directly communicate with.

Also you might want to get familiar with browser based local storage on top of just cookies, namely the local storage area and the IndexedDB. See the manual for further infos on that.

Hope that helps to get you started.

1 Like

Thanks. It's odd ... I understand what you're saying, but my brain isn't quite grokking it yet. I'll there there.

Wrong book! :smiley:
See TMSSoftware Hands-On With Delphi #1. It shows a very simple and understandable way of implementing server authentication that can be used from either desktop or browser.

Maybe Dr. @Holger_Flick should copy some of this from one book to the other on future editions. :wink:

1 Like

I asked a selected group of Delphi friends and the majority spoke that a reference to another book is better than repeating the same content in each book. The upside is I do not bother programmers with stuff they already know, downside is you might have to pick up an earlier version.

That's why I got both, and now Hands-On #2 is on it's way thanks to Bruno and their team ! :upside_down_face:

1 Like

Well, I personally disagree in this case. I'd say that unless it's a huge bunch of stuff, if it's directly related, then it belongs with the stuff it's related to, duplicated or not. (I don't know how much is there.)

If it was hypertext, then no, as hypertext is designed for this purpose.

We're not building reference libraries here ... we're building software apps. I prefer completeness over redundancy, because what happens is I have to put my programming work on hold to perform a "library building" task that's measured in DAYS when that's not what I'm getting paid to do. Worse, it costs me money in the process! In contrast, redundancy costs are measured in seconds with no additional out-of-pocket costs.

How would you like to buy a car that doesn't come with tires because ... you know ... tires are found in a tire store, so why ship them with the car? Just tell customers where to go buy them so YOU can save on materials and shipping costs.

It seems like a Good Idea, but it's not in the best interest of the customer who expects to get a complete product (or discussion of relevant topics, in this case).

I'am just learning WEB Core + XData. Last week looked thru all videos from's Introduction to TMS WEB Core. Got basic understanding what's goes on when Web Core is used.

Have earlier got book TMS WEB Core. And with it also was left out answers to questions how to handle security with WEB Core apps.

But today received from Amazon Hands-On 1 and 2 books. Been browsing them and noticed that in book 1 is security questions what i have, been answered. And soon realised that these three books + video course are "serie", there's no same things replicated in another. And i like this approach. It's frustrating to read books where same things are mentioned.

With fast browsing book 1, i realised that there's explained almost all what you need when making basic business app. User access, authentication, encryption, PDF reporting, server side custom services etc.

Waiting book Hands-On number 3 to published, going to buy it whatever subject it has :slight_smile:


I am currently working on book 3 with focus on VCL grids and practical examples to use these grids with text data, XData and FireDAC. The XData examples will have VCL, FMX, and Web Clients even though the VCL grids are not supported on all the platforms. I realize there are grids for the other platform as well, but VCL grids fill a book already ;-)


Great news!

Launch pre-order!

1 Like

I think a great resource would be a book or just a reference document that shows building a WebCore app in two parts: one shows building a form with some not totally trivial logic, and the other would show how to go through and change its appearance with CSS tags.

I tell people I'm like a home builder -- I'll deliver something with white walls, neutral carpet and floor coverings, and all of the "eye candy" and colors is up to them. I really don't do anything with CSS. Selecting a visual template or theme is about as far as I'll go. I'm not even sure if WebCore has that ability. (Do the Delphi styles work with it?)

I have a fairly non-trivial app I built as an exercise that I'd be happy to let somebody use if they'd like to document the "look and feel" side.

In my mind, I'd use a guide like this to give to someone else (a web UI person) to show them how to go about creating the CSS tags needed to make it look a particular way.

I'd also use it so I know what properties I need to provide on different components to allow them to add whatever CSS tags are needed.

If there is a component, the basic rule is that if you want to have it customized via CSS, you might have to provide ClassName properties for as many HTML elements (or groups of HTML elements) there are in the control.
For example in a table control, there is the group of header cells and normal cells, so as a minimum to ClassName properties to offer the ability to customize through CSS.

This has gone a bit off-topic, but let me ask this about supporting users ...

For a web app, if you need to save/restore the state of the app, then you can use the equivalent of INI files (ie., anything that gets you that) without regard to the user.

If you need to maintain the state of different users, then you need to implement a way to support user-based sessions where the users need to identify themselves, possibly by logging-in or some other kind of authentication. Cookies can be used to extend a session for a time.

Alternatively, you could pull the session info from a surrounding context, like a plugin or addon for Wordpress, or a connection to some other service (eg., how Zapier or IFTTT work). This is also how Windows works, because apps execute within the currently logged-in user's context; so Win apps typically don't need to worry about it or at least bother the user.

Are there any other options?

Ok, I got Holger's book (I guess it's the first Hand's On book) and have been going through it. It's exactly what I needed. There's way more material in it than I expected for this topic, and it def. would not be a minor addition to another book. I think a more relevant title would have helped. Maybe "The Complete Guide to Web Authentication in Delphi Using TMS Tools". :)

If I had one thing to nit-pick about, it would be that I'd like to see some diagrams that show all of the different pieces and dataflows. I'm a visual thinker when it comes to that kind of thing. Otherwise, it's an excellent resource.