Small company, limited funds, we will be upgrading our server from Windows 7 Pro to Windows Server 2016. The site has been using Classic ASP connected to an Access (mdb) database, my understanding is that Server 2016 does not support ASP. I have been asked to convert it to using JavaScript since that will not require any additional expense. Before I tell them I can do this I have some questions regarding security.
- Is it possible for JavaScript to read/write to an Access database?
- Can this be done in a manner that it "cannot" be hacked?
- Would I just need to set permissions on the server?
- Can it be setup so that site visitors can read the database without being able to write to it?
- That users on the server can read and write to the database?
- What string would I use to connect to the database?
- Would the same string be used in pages running on the server that could write to the database?
Switching to a different database is not an option, the company uses an application they wrote themselves that uses Access. I can do the code conversion from ASP to JavaScript but I want to make sure it will be secure before I waste my time. If it is not possible, any suggestions?
I have not tried anything yet, I want to know if it is even possible. If so, what string to use to connect.
2
Answers
I don’t want to sound condescending at all, but to offer a fair warning.. what you’re trying to undertake might end up being a bigger project than you can handle by yourself or with a small team.
That being said, here’s how you go about it.
Separate your frontend from your backend, this makes it "harder" for users to interact with your database.
To do this create an express.js app and communicate exclusively via rest-api, additionaly build a jsonwebtoken Authentication flow on top of it to control access to that api.
Only that node.js backend should be able to communicate with your database.
Try for example https://www.npmjs.com/package/mdb-reader to interact with your existing database
Hopefully that gives you a bit of a head-start. Its definitely achievable but be sure to take it in small steps "We’ll rebuild the whole thing" is usually a one-way ticket to burnoutland…
No, not really. You can have/write/enjoy JavaScript code that runs in the browser, but it will have to call so called “web methods”. So, JavaScript don’t read or write anything, but it can of course call the web site to get some data to display in the browser.
Now, this is somewhat confusing. I assume you have a working site now. It not clear if the site just displays some information, or the site requires a logon?
So, it not clear what kind of permissions you are talking about. Are you talking about what a logged-on web user can do? Do you even have logons for the web user’s now?
Or are you talking about server permissions that you used in the past, and now for the site to use the Access database? From your questions, it sounds like the existing web site does not use the Access database. However, other questions suggest it does.
We assume here that an existing web site is up and running, and is using that Access database. If that is not the case, then of course the narrative changes.
Web sites tend to all work that way. In fact, in near all cases I can think of, a web site that displays data NEVER translates into users being able to edit such data. (so, answer = no, web sites don’t work like Access bound forms).
So, web pages don’t out of the blue allow editing of data, or changing of data.
Hence any such ability of the web site has to be part of the code and design of the given web page in question.
Thus, as a general rule any content on a web page can’t be changed by user’s viewing the site. Any editing of data requires software and specific code written to allow as such.
Users on the company internal network can continue to use that shared mdb file in some shared folder.
So, what the web site does in regards to updating data is 100% different then say internal company users updating such data. It not clear if your existing Access application is split or not (but, that’s a big detail one should have provided here).
Do you mean for the web site software, or the Access client-side software on each internal company’s computer?
As noted, if the site connects to the mdb file, then that connection will look the same as it does now — maybe a path name change, but it will work and look the same as it does now.
It’s not clear what data provider the site is using, but often these REALLY old sites used ado, and NOT ado.net. Thus, the connection string would actually be the same one you use in ADO code you have in VBA if the database was split. But again, more details are required here.
Well, the connection string from the web server is to the mdb file is going to be whatever the connection string is. So, it not clear why the above 2 questions. You either have a valid connection to the mdb file, or you do not from that web site.
As noted, I recommend is you keep the so-called Access “front end” as you have now, but migrate the data out of the application to SQL server.
That way:
Your existing Access code and application can continue to be used.
Your web site can also use the same data, just that now both Access and the WEB site are using SQL server for the database.
The only confusing part is that it’s not clear how much the web site does now in terms of updating that data, or is that a future goal?
In other words, does the web site now update data, or just display data from that same shared mdb file?
It really comes down to how much the web site does now. If the site does little and is only a few web pages then perhaps that part of the project is updated to a newer version of asp.net.
And if the site now does NOT write data, and if the site now does NOT have user logons? Then almost for sure if the goal is to allow public users to logon, then you want to update that site to something newer.
No matter what choices you make here? You can and should migrate the Access data to SQL server. Note how I stated JUST the data.
Thus, you can keep the existing Access application, VBA code, forms and reports etc. will continue to work as before.
The end result is you using a web server friendly database, and you also have a far more reliable access setup.
So, in most cases, the Access data can be migrated to SQL server, and you can keep/salvage/use about 98% of the existing Access VBA code, forms etc. Thus, Access can use what are called linked tables to SQL.
Your questions seem to suggest the web site now does not update data, and that may well be a future goal.
After all, no need for customers to phone up the business, some employee fires up the Access application, and reads off the screen to the customer what information they need to know. Why not have customers logon to the web site and view that information that is being generated for the customers from that Access application anyway?
Why phone an employee here? Let customers do that on their own, and they can do that 24/7.
At the end of the day, this is not really a valid SO question, and is beyond the realm of this forum.
However, I would not scrimp or ignore or mess around with web-based security unless you have professional help and expertise in this area.
The web is a very nasty place, and I suggest professional help for any public facing web site that works against internal company data.
This type of project is not to be half baked when it comes to correctly securing data.