I am new to Cayley db. I am trying it for my applicaiton, and for my interest in graph db concepts.
I have not seen anything referring to a database user or a password for accessing to a database in Cayley documentation. Moreover, drivers on npm to connect to Cayley from Nodejs does not mention anything other than host and port.
On what level db user accounts and password protection of databases achieved in using Cayley database? Is that achieved on the persistence layers that Cayley depends upon, leveldb, bolt, mongodb?
As there is no other answer for that I am answering my own question myself.
Since Cayley persists data in a supported by Cayley db (boltdb, levelled, mongoldb) the user accounts of the db is managed by one of those dbs and so inside their own user accounts system.
On a HTTP application case which is the most common case, the HTTP server reaches the Cayley db for input/output, so, the HTTP server application code manages the authorization and authentication in access to database resources by a custom mechanism. This end is free to choose from many.
The operating system (OS) that runs Cayley db can be configured in its own way (specific to OS) to control network access to Cayley db, separately. Most of the cases Cayley runs on the same machine as the companion HTTP server application so, OS can block the network access to the Cayley db. In other cases again OS can be configured to accept network access to Cayley db only from predetermined set of IPs and in predetermined protocol, which is HTTP in that case (one reaches a Cayley instance over HTTP).
Related
I have a PHP web app (Snipe-IT) that was previously working.
We went through a security review, and the recommendation was made to enable service endpoints (Microsoft.Sql) on the application subnet so that web apps connect to databases over the Azure backbone. Everything is working fine for the other MSSQL apps, except for our Snipe-IT application, which connects to a GP_Gen5_2 MySQL instance.
The error message says:
D'oh! Looks like we can't connect to your database. Please update your database settings in your .env file. Your database says:
SQLSTATE[HY000] [9009] Client connections to Basic tier servers through Virtual Network Service Endpoints are not supported. Virtual Network Service Endpoints are supported for General Purpose and Memory Optimized severs. (SQL: select 2 + 2)
This error message doesn't match the environment configuration because the database in question is a General Purpose, 2 vCore(s), 50 GB database.
There is no networking tab on the MySQL server, but in the Connection security tab we have tried enabling access to Azure resources, allowing the full public internet (0.0.0.0 - 255.255.255.255), enabling and disabling forced SSL, but nothing changes the result.
Azure won't let us create a Private Endpoint on the MySQL database because 'the subnet contains external resources'
I am hoping there is a way to resolve this without having to rebuild both the app and database in a different App Service Environment and subnet.
Thanks
When attempting to connect to the Azure App Services (ASP.NET) MySQL database (Navigating to the Manage link) the Page info returned from PHPMyAdmin prevents me from moving forward. I cannot seem to find the location of the log for the app within Kudu and navigating to the MYSQLCONNSTR_*.ini file did not provide me with the information that I needed.
I've attempted to use the connection strings for the database for both the scm and the web app but neither work. I have also attempted to use the public-facing IP within the Kudu environment variable without any luck.
I cannot seem to find the information I need to connect to my instance of PHPMyAdmin, and am now quite lost.
The solution to my problem was here: https://stackoverflow.com/a/57545678/4212591
The free tier of the Azure Web Service does not allow for the always-on feature. Thus my inability to connect to the service.
I’m unsure on the exact location/path you are looking for that file, the connection string is stored at D:\home\data\mysql\MYSQLCONNSTR_localdb.txt.
If you wish to customize the database, username and password, after you have created a new database, add new username or update password, simply modify:
D:\home\data\mysql\MYSQLCONNSTR_localdb.ini , remove D:\home\data\mysql\MYSQLCONNSTR_localdb.txt and restart the WebApps.
Furthermore, the connection string flows to your application as an env variable MYSQLCONNSTR_localdb. The env is added to the main site process. For Kudu site, one may read the same info from D:\home\data\mysql\MYSQLCONNSTR_localdb.txt file. Beware that we are not using the default MySql port (3306). In fact, the port number may vary for each application life cycle depending on its availability at startup time. The port info is also available as an env variable WEBSITE_MYSQL_PORT to your site.
Ensure that MySQL process is running. Check in your web app application settings if there is a connection string. PHPmyadmin uses MYSQLCONNSTR_ to connect to the MySQL server. If you have a connection string in application setting change the connection string type to Custom , so you can still have the information if needed or delete it. This will force PHPmyadmin to access MYSQLCONNSTR_localdb and connect to the MySQL in-app server.
As a side note, on Azure WebApps Sandbox - Connection attempts to local addresses (e.g. localhost, 127.0.0.1) and the machine's own IP will fail, except if another process in the same sandbox has created a listening socket on the destination port.
To rule out, application code or the client library leaking TCP socket handles or burst load of requests opening too many TCP socket connections at once, scale-up Azure App Service Plan and see if that makes any difference.
One of my small python web app hosts on GAE
but I prefer to change its database to Mysql.
GAE database is too special which rely on GAE and not good for future migration.
Can python app on GAE(google app engine) access Mysql server host on VPS/dedicated server?
(of course they are not in same local network with GAE)
if sure, what need to care(firewall, port policy and all others) for Mysql server being open to web?
Sure.
Open the single port needed (3306) inside your firewall of choice.
Always install relevant security updates to the mysql server software as soon as possible.
Create a new mysql user for access from your GAE instance.
Possibly restrict access for this user to one single IP inside of mysql.
(If this is true, you can also enforce it in your firewall of choice too, which hardens the access even more.)
Grant this user as less rights as possible inside mysql.
I am facing this problem:
stackoverflow question
except my host doesn't seem to have cpanel. Since the answer given in the linked question is cpanel related it has not helped me. Is there anything I can do?
It seems you are trying to connect from a client machine located on your desk to a mySQL server instance located in a service provider's server farm. You're trying to use the ODBC "driver" for mySQL to do this, so you can look at your mySQL data with MS Access. (Right?)
You need to make sure this particular hosting service provider allows remote connections to their mySQL server instances. Some service providers, especially the lowest-cost ones, prevent these remote connections using firewalls or other network isolation techniques. (They do that because it's easier to control both security and performance when only their own web servers can connect to their mySQL servers. ) If your service provider prevents all these connections as a matter of policy, you're going to need another service provider.
If they DO allow remote connections, you may need to enable those connections for your mySQL database. That's what the "cpanel" function mentioned in the other question is about. cpanel is a popular control panel web application offered by many commercial hosting service providers to allow self-service control by their customers. If your service provider doesn't use cpanel, you'll have to find out what they do use. Even if they do use cpanel, they may still not allow remote mySQL connections.
You will also have to make sure your client machine (the one running ODBC) and user have authorization in the mySQL user database.
You would do well to put in a service ticket to your service provider asking if they do offer remote mySQL access. If they say "yes," then you can ask them for advice and help on setting it up.
Keep in mind that opening mySQL server instances for direct connection over the publicly accessible internet is not ordinarily considered a good security practice. If the data in your database is in any way private (peoples' identity information, for example) you need to be very careful indeed.
I'm new to MySQL and I'm using a desktop DB management app called "Querious" to simplify the process while I learn.
I want to work on (mainly just structure & basic population) a database that's hosted elsewhere, but the host won't allow any remote MySQL calls on their server.
What is their reasoning for restricting MySQL calls to localhost only? Is this a security or a performance concern?
This is a security concern. The idea is that if people can't remotely connect, they have to compromise the system. Not just the files that hold the database information.
You may be able to request that just add your IP address to a trusted host file, but I doubt they'll do that either.
It's fairly common practice to not allow remote DB connections
I've run into this problem with GoDaddy where they implement this by default. You can change this, however, by indicating that you want to allow remote access. If you've already created your DB, though, you can't change it, so I would recommend creating a new DB and deleting your other one.
The reason why is for security. If only your app can call your DB, you don't have to worry about other people trying to access it.
Distill,
An improperly-configured MySQL instance is dangerous, whether the user is remote or local. This could allow malicious attackers to cause crashes or remote execution of arbitrary code (i.e., owning the machine).
You can use PuTTY to create a tunnel if it's allowed by the server so that your application traffic goes through ssh and then is forwarded to the correct port on localhost.