Access + rdp => E-commerce ??? (1 Viewer)

amorosik

Member
Local time
Today, 20:57
Joined
Apr 18, 2020
Messages
436
Suppose we have a computer with a Windows operating system, which has terminal services active
And suppose we also install an http to rdp gateway, for example Myrtille
And then using a web browser, it should be possible to connect to an available session on the terminal server
Do you think it would be possible to create, using a program created with Access, a system that comes close to the functionality of an e-commerce?
 
This would be a web-to-RDP-to-Access two-step linkage. I would be extremely concerned with the security implications of such a thing. Not that you couldn't ever do it, but that assuring reasonable security might be tricky, tedious, and tortuous. Access sessions since Ac2003 no longer have robust per-user object security, so you would have a LOT of gyrations involved in getting your session properly secured, analogous to what you do now for a split FE/BE database with shared BE and individual FE files. I'm not saying this couldn't be done, but I see lots of speed bumps along the way. I'll further state that folks with different experience than mine might see this differently, but this is a direction I would not choose due to those user security concerns.

One glaring issue is establishing identity, because Access and Windows still use user-level security for arbitrating permission to use files. Your HTTP session is inherently anonymous at first (probably uses an internal ID called "NetworkUser"), so until you establish an ID you don't know who is coming in. But then, true E-commerce means that your user might as well be Joe Schmuckatelli, someone that neither Windows nor Access have ever heard of before. So for that RDP session, you have to use a fictitious or default username (or stay as NetworkUser) to make permissions work. OR go through the really complex gyrations of defining the new user for your Windows session, which is not a trivial thing to do.

My concern includes how you would pass the username from the HTTP session through to the RDP session - even only as data, not for permissions. You would have at least some web-page work going on. But then in the RDP session, you have to have permissions for the FE file, but the Windows O/S (that you are using to serve your TS sessions) has probably never heard of Joe Schmuckatelli. So you have to assign a common identity, a fake name... or stay with NetworkUser. But that doesn't end the security issues.

OK, so now you have an RDP session to Access. But what if you have two users coming in at the same time? If two users come in at the same time, are they going to share the same copy of the front-end file? And unfortunately, that is the nature of RDP sessions. If they are not configured to be separate users with separate FE files, they WILL share the same physical FE file. In that case, you have NO HOPE of avoiding lock collisions, which is the start of database file corruption.

How many RDP sessions can you assign at once (=how many simultaneous users) - because you do not have infinite sessions? The number of TS simultaneous sessions is tunable with a proper license. (Without a proper license, TS supports 2 sessions.) And if sessions ARE sharing the same FE file, that is how databases get corrupted (due to Windows-level file locking not applying to Access-level structural locks). I see high potential for corrupted databases.

Would it be possible? Maybe. Would it be easy? Maybe, maybe not. Would it provide reliable service? I've got my doubts. Would it be secure? Not a chance in Hell. I see more pitfalls than a Lara Croft Tomb Raider game.
 
Do you think it would be possible to create, using a program created with Access, a system that comes close to the functionality of an e-commerce?
I guess if you have a lot of time and you only have Access as a tool, you might cobble something together but why?

I can walk to my granddaughters house but it would take me more than 24 hours assuming I could muster the stamina, but why?

I'm a great proponent of using the right tool for the job. The job becomes so much easier.
 
I guess if you have a lot of time and you only have Access as a tool, you might cobble something together but why?

I can walk to my granddaughters house but it would take me more than 24 hours assuming I could muster the stamina, but why?

I'm a great proponent of using the right tool for the job. The job becomes so much easier.

Yes, of course, we all know that there are better tools for building an e-commerce
But that's not the point

The answer to your question could be given by Christopher Columbus, or Edison, or Guiglielmo Marconi, or Christian Barnard or Elon Musk who wants to go to Mars
But why they dedicated their entire lives to achieving goals that most humans considered useless to seek?
Exploring is a term that perhaps embodies the very essence of living organisms
The curiosity to understand and solve problems is closely inherent to all intelligent beings

And I am a living and curious organism :D
 
The answer to your question could be given by Christopher Columbus, or Edison, or Guiglielmo Marconi, or Christian Barnard or Elon Musk who wants to go to Mars
No, the question would be does Columbus want to travel the world in a rowboat (Access) or use a modern sailing ship like the Santa Maria. Just because your only tool is a hammer, doesn't mean you can use it to sink screws. You should probably be looking for the best screwdriver available.

I am not trying to discourage you from discovery but e-commerce is an app where the client is unknown and has nothing but a browser. If you want him to use your RDP session, you would need to provide him with the log in credentials since he won't find your app by searching the web. There would also be a limit on the number of concurrent connections. The RDP server also needs to serve ONLY your app. It cannot provide a desktop.
 
No, the question would be does Columbus want to travel the world in a rowboat (Access) or use a modern sailing ship like the Santa Maria. Just because your only tool is a hammer, doesn't mean you can use it to sink screws. You should probably be looking for the best screwdriver available.

I am not trying to discourage you from discovery but e-commerce is an app where the client is unknown and has nothing but a browser. If you want him to use your RDP session, you would need to provide him with the log in credentials since he won't find your app by searching the web. There would also be a limit on the number of concurrent connections. The RDP server also needs to serve ONLY your app. It cannot provide a desktop.

Maybe you didn't read the post I sent properly
I indicated the use of an html-rdp gateway such as Myrtille or similar
From the user's point of view it will only be necessary to use only a web browser
No need to use the rdp protocol in any way
The problem is precisely on user authentication -> operating system
And I was asking for information and your experiences on this
 
No need to use the rdp protocol in any way

That is, I think, where you run into more problems. In my original reply I focused on the user security aspects of your implied connection, and Pat has mentioned her concerns over that facet as well. However, you should also be aware that there are issues in, for lack of a better term, "control pathways" - i.e. how you pass a user's control and data actions to the Access session. In this reply, it might at times sound like I have retreated to my first post by talking about session security - and to be honest, that IS intertwined with the point I am making here. However, this time the theme is more along operational lines - how to get data from point A to point C with an intermediary standing in between the two end points AND the two endpoints don't "speak the same language (protocol)."

Access has a graphics-oriented user interface that depends on a particular "connection" mechanism which RDP emulates (a hard-wired or virtual-connection to a Windows interactive session) but that the HTTP/HTML combo does not. Access expects you to pass things to the session like mouse-cursor position, clicks (left and right), and keystrokes. But without an interactive-session interface, Access won't get those things.

RDP works because there IS a session going on behind the scenes there. I.e. Remote Desktop Protocol supports the "session" concept and makes the connections easy. But part of the problem with HTTP is that it is designed with a different KIND of session structure - where your IMPLIED session at the server is managed in part by the HTTP client that looks at your locally stored cookies. The HTTP client has to pass in that cookie data to identify which of several equal sessions are involved at the server side. HTTP is transaction-oriented whereas RDP is session-oriented.

Although Windows was rewritten some time ago (Windows NT was the change-over point), it still has vestiges of the three default channels - IN, OUT, and CMD. Each interactive session (and technically, each batch and each network session) has a separate process (a.k.a. task or session) structure in the O/S scratchpad memory area. Yes, a task can open other channels - but it starts its existence with those three channels by default. This is a holdover from Windows in the MS-DOS era.

Actions can be performed simultaneously for each task up to the number of threads supported by your multi-core system. (My home system happens to have 8 threads, i.e. 4 dual-core CPUs.) Windows architecture was designed in the era of a single-core system that did time-sharing via time-slicing multi-task environments. The transition to multi-CPU time-sharing became trivial because of O/S-level tricks, but I won't try to open THAT can of worms right now. And it is irrelevant to this discussion.

By contrast with RDP, the HTTP server-side task linearizes inbound HTTP client transactions from multiple sources, all in the same session, which it can do because the cookie data (passed along with the actual request data) tells the server which transaction thread it is currently processing. You know how a site lets you tailor your cookie preferences? The "Necessary" cookies are the ones that manage the implied-session data.

Yes, you CAN have multi-core involvement here too, but there it doesn't matter which core does what to whom because each transaction contains its own ID. The RDP approach, however, knows the user ID because it was associated intimately with the private session when that session was first created. Private sessions don't need to verify the ID every time because only one user can use the virtual connection for the lifetime of the session. And at this point, my discussion about user security in my prior long post becomes relevant so I won't repeat that here.
 
The presence of communication via RDP is not THE obstacle to the problem to be solved
We could also get both the rdp server and the http-rdp gateway out of the way

Well, let's do it, just to understand exactly the problem and how to overcome it
Suppose we have the classic client-server setup within a LAN, and therefore pc1 acting as db-server + access-file-server, and then pc2, pc3, pc4 acting as clients
The idea is that pc2, pc3, pc4 can start an mde/accde file physically present on pc1, let's suppose that this file is called dispatcher.accde
Then, when pc2 (or pc3 or pc4...) double-clicks on the link on its desktop, the dispatcher.accde file will be transferred to pc2's RAM and launched (or interpreted in our case) on pc2
The dispatcher.accde procedure will do nothing other than request the access data from the operator in front of the PC2 keyboard/monitor
Or it will allow you to register a new user
All data will be written/read on db1 physically present on pc1
When the operator in front of monitor/keyboard PC2 enters a valid user (therefore present in db1 which is physically on PC1) then a new instance of the main.accde procedure will be started, always physically present on PC1
The main.accde procedure will allow the operator in front of pc2 to perform the requested operations

Now let's go back to the system via rdp
In the example above, the individual pc2, pc3, pc4 load into memory and execute both the dispatcher.accde and, if autenticated, the main.accde
Assuming that pc2, pc3, pc4 access separate sessions via rdp on the terminal services present on pc1
The functions indicated above should work in the same way, except that in this case the programs (dispatcher.accde and eventually main.accde) would be loaded from disk of pc1 into the ram of pc1 and started running on pc1

I understand what you mean when you illustrate the question/response operation of an http-client and an http-server, with cookies as a means of exchanging information, but I believe that the same functionality can also be obtained from one or more executables created to achieve the same purpose
I don't see a real technical problem, or at least so far I don't see one
I mean, a http-server + http-client environment is intrinsically simpler than the classic client/server program understood as the executable that runs on pc2, pc3, pc4, and database on pc1
Let's leave aside for now the more complex configurations with application servers and similar configurations, for simplicity's sake we will now reduce the problem to the executable that runs on PC2/PC3/PC4 and the database that responds on PC1
In reality it seems to me that the classic client/server environment is natively more powerful than what can be achieved only through the bare http protocol

Be careful, I'm not saying that it is better to use this system rather than the classic clinet/web server
What I mean is that it seems to me to be technically feasible
What do you say?
 
Making a copy of DB1 (from PC1) is OK. Lots of protocols can do that. But let's say PC2 uses its copy. What does it do with the updated data? (You DID say "separate sessions via RDP" in your question.)

Here is the catch. You have to EITHER say that you DON'T update PC1/DB1 with whatever is done by PC2/PC3/... OR you have to reconnect PC2 to DB1 directly for reconciliation and HOPE that PC3 hasn't done something that will cause a key violation. When you brought in RDP, you implicitly brought in a WAN - with the Access-style update path that normally is LAN-only now dependent on a WAN - which is known to be problematic. The WAN becomes an issue since WANs tend to drop things like network sessions. Since Access uses SMB which is a connection-oriented protocol under the TCP family, and since most sites disallow TCP Reconnect actions, a dropped connection is permanently dropped, no matter what state it was in when the network failed.

I'm not trying to cast ANY DOUBT WHATSOEVER on your personal ability. But as long as Access has been around, it is a significant point that nobody else has figured out a safe way to do this kind of web-based Access system in the last 20+ years. And it doesn't help that Access is NOT an Open Source program, so we cannot even see if there is a place we could jigger to change that dependence. Both SharePoint and DataVerse appear to have issues (based on other current threads in the general forum.)

Let's see if I can say this another way: In any client-server setup, the method normally chosen makes the server "authoritative" in that it ALWAYS has the "official" copy of whatever is going on, whatever you are doing. When you copy DB1 to PC2, the copy of DB1 on PC1 suddenly is no longer authoritative because IF you plan to re-merge what PC2 did into the "official" data, then for a brief time PC1/DB1` did NOT have control over the data. That loss of authoritative status means you cannot trust ANY copy of DB1 until all differences are resolved. So PC2, while it had the copy of DB1 under its control, might fill an order for 30 left-handed veeble-fetzers before it somehow re-merges with PC1/DB1. During this time, PC3 CANNOT place an order for ANY number of left-handed veeble-fetzers - because it has no authoritative source. OR it can place the order but it may be necessary to later notify the purchaser that the order cannot be filled. (Bad for business if that happens a lot...)

Access is designed to allow any number of front-end files to connect to a back-end file because nothing is data-authoritative in an FE file. In fact, with judicious use of linked tables, you can have two different BE files be authoritative - about two different things, one table in each back-end file. But Access requires one and ONLY one file to be the authoritative source for a particular table. Any solution you adapt must take into account the need for an authoritative data source. Copying the tables to another place without a clear reconciliation strategy is going to fail on theoretical grounds regardless of the most elegant implementation ever seen.
 
Making a copy of DB1 (from PC1) is OK

Let's see if I can say this another way: In any client-server setup, the method normally chosen makes the server "authoritative" in that it ALWAYS has the "official" copy of whatever is going on, whatever you are doing. When you copy DB1 to PC2, the copy of DB1 on PC1 suddenly is no longer authoritative

Where did you read that I wrote "..copy db1 to pc2.."?
Db1 remains ONLY on pc1 (suppose you have a Sql Server installed on pc1), and is read/written by pc2, pc3, pc4
No conflict can occur since the requests that pc2, pc3, pc4 send to pc1/db1 are serialized by the db-server system which maintains communication between db1 and the various clients
 
OK, I mis-read your discussion about using the LAN-style connection (first part of post #8). So that confusion is on me for not seeing it quite right.

However, when you take the next step using RDP (again in #8), there is an implication that you are doing this because you are no longer in a LAN environment. You are in a WAN environment. Because if you were still in a LAN environment you wouldn't be using RDP. This is where you run into the same problem that ALWAYS happens when you are no longer in a LAN.

What happens there is that your RDP session might drop, leaving behind a dangling session created within the virtual desktop created by RDP. By "dangling" I specifically mean that its IN, OUT, and CMD channels become disconnected. If your DB was waiting for something to happen inside a dangling session, it ain't gonna happen because - as mentioned before - a TCP Reconnect operation, though defined for the protocol, usually is disallowed because of the inherent security risk. Your dangling session cannot be cleared except by rebooting. So in effect that RDP session "kicks the can down the road" to be cleaned up later. But when it IS cleaned up - by terminating the session - you have the risk of corruption at that point.

Now, the trick is to evaluate the frequency of losing that WAN session. I cannot tell you that because it depends on hardware and distance and the number of hops in the network route.

The other danger is the difficulty of correctly configuring the RDP session so that you do not share FE files, you COPY them to individual user environments.

You ask if this can be done. Damned if I know - but I know that it will be EXTREELY difficult to base it on Access because of the inherent assumptions associated with using Access in a given environment. Like Pat's comment that you don't use a hammer to sink screws, I think you are using the wrong approach to try to make access look like an e-commerce site. This will be like Murphy's Law of Project Management, which is that the first 80% of the work takes 80% of the budget and the last 20% of the work takes the other 80% of the budget.
 
This will be like Murphy's Law of Project Management, which is that the first 80% of the work takes 80% of the budget and the last 20% of the work takes the other 80% of the budget.

This is good, I've never heard of it :ROFLMAO:
But it's true
 

Users who are viewing this thread

Back
Top Bottom