"Application developers need to update their connection strings to point to the new server, and your customers need to know the new server address as well."
I have a desktop software. This java software has the following logic:
1-User inserts username and password. He presses "login" button.The data is then sent to a web server for validation.
2-In case of success, a JSON is sent back to the java app with the database url, username, password and most importantly THE SCHEMA etc. Note that, while the server IP is normally the same, the schema changes, thats why the JSON sents the correct schema URL for the client.
3-The java app then uses information from the JSON to connect to the MySQL directly.
Thats how it works. However, Theres a problem:
When the software was installed, I had to ask the IT of a few companies to make sure the mysql address, which is typically the same, to be allowed through the firewall.
And now, we are currently in need of changing our current database from Hosting X to Hosting Y.
So basically it falls to this:
If I want to move a database from one server to another, or stand up a new server and move everything over to it, I will have to ask each IT to allow the new IP on their firewalls.
Researching, Ive come up with a solution. Im not sure its valid So thats why I came here in the first place heh.
So here's the thing.
On step 2, described above, the JSON sends the database URL like this:
Couple of things here. Unless your webapp is a database editor, you generally should not be connecting to a different database for each user. More commonly, if multiple client organizations are going to use the same webapp, you'd either create a separate webapp instance for each client and thus each webapp connects to a statically-referenced database OR you'd design your schema so that the client ID is part of the primary key (using compound keys) and keep everything in one database. The first solution tends to be more mahine overhead, but the schema is simpler and there's no danger of cross-client data leakage. The second approach is likely to be less overhead but it does complicate the database logic.
Als, it sounds like you are not using the JEE standard container-managed security system. In which case odds are extremely high you could be hacked quickly and easily, Based on a depressingly-high sample of systems that I and others here have seen. If at all possible, use JEE's own security. I've never heard of anyone breaking it. Plus it's built into the JEE API.
DNS is the phonebook of the Internet. All a CNAME does is map a fully-qualified domain name (FQDN) to a specific IPv4 and/or IPV6 address(es). You can change those target addresses at any time, although it can take some time before other users see the new address(es). If you're using a cloud provider, they'll usually also provide DNS services. Note that DNS doesn't define ports, only addresses. Port numbers use well-known port numbers or URL overrides.
It is extremely bad practice to expose a database over the open Internet. The infamous SQL Slammer attack on Microsoft SQL Server invaded innumerable Windows machines, including some that were serving as the controllers for cashpoint (ATM) machines. Plus network latency adds a LOT of overhead. If at all possible, keep the database machine on the same LAN as the webapp server(s) that it supports. Better yet, keep them talking on a VPN. Cloud providers will offer VPNs that isolate you not only from Internet attack, but also from other users in the cloud. You can even run multiple VPNs to isolate different workflows within your organization. The cloud provider will offer internal DNS for the VPN so that you can keep the same machine names and have the flexibility to adjust the network topology.
"privilege" comes from the Latin words for "private" and "law" (legal) and dates to feudal times. To "claim privilege" meant that you were above the laws that applied to the common people.
I've never won anything before. Not even a tiny ad: