69giapmyata
commented
10 years ago Good points! Let my try to wrap some of them up from my perspective.
I have no opinion on the db name - TUSHKA can add his opinion here.
Connecting to the database server from the same machine localhost can be used to identify the server. additionally 127.0.0.1, which is the local IP address on every machine is usable.
Connecting from outside world to the website is completely the same as connecting to any other website e.g. our squad website. If there is a public DNS name for the domain a common URL having a name e.g. www.BosWar.com could be used. If not a public IP address (not 192,168.x.x or 10.x.x.x) can be used to connect to it.
The next question is a misunderstanding from your side. The host question in the form is not referring to the user/website combination but to the website/dbserver combination. Imagine the database server is not hosted on the same machine the website is hosted, something different than localhost would have to go into this field e.g. an IP address PORT combination. Though having said this I think 99% of the users will have the website and MySQL database server hosted on the same machine. Localhost will work most of the times.
The Boswar layout is based on two groups of SQL users: A user having a wider set of privileges. This user is setup in the connect_db.php file and used to establish the connection to the core database (I call it boswar_db) An SQL user having reduced user rights on the database used for manipulating the campaign database information. This user is stored into the campaign_settings table during the creation of a new campaign database. It is not used for the main (boswar_db) connection at all. Having one user out of the second group or multiple users is up to the 'customer'. We implemented the opportunity to use the same, second user group, user over and over again or create a new SQL user with each new database. This user has NO entry in the users table nor in the campaign_users table. As already said the only place in the database you find evidence of him is the campaign_settings table. The other place this user is showing up is in the SQL users repository of the MySQL server. By adding a new campaign to the same user we add the required rights to the user stored on the MySQL servers user repository. By dropping a database we revoke the rights to keep the database nice and clean.
I do not completely understand the additional lines you wrote regarding user levels but maybe my explanation clarified the difference between an application user and a database user the way we use them.
The last item regarding the connection file is absolutely correct. The way we are using it right now would be a security issue in the wilderness of the www. We kept is like this as it is easier to collaborative work on the same website through GitHub as the folder structure can be easily defined by a root folder called Boswar and the file one level above. The final solution should definitely point two directories up. That way we can introduce several versions of the application on the same web server having names like Boswar_v.1.0, Boswar_v.2.5,... and still pointing to the connect files securely. TUSHKA had a point here in this post #70
69giaptushka
From my abortive test this morning I did have some reflections. Only able to see a couple of screens I inevitably focus my attention on them.
I am also now testing from one computer to another now so not just testing in localhost.
As discussed last night we have the unique abbrev.
the database name also must be unique, short and no spaces. Why are they not the same?
anything that can reduce user confusion and possibility of error reduces maintenance.
Next the DB host.
If I understand right if I have webserver on the same system that I am testing my browser I will enter localhost and maby :port.
If I am on another computer and connecting to the server across network or internet I will enter either the url or the ip address and maby :port.
Now in real usage most users will be connecting to a server from distance. The server will know it's ip/url. So we will be able to store the variable ip/url/localhost in the boswar database and will not need to enter this parameter on campaign creation?
Next New campaign user/existing one.
In new campaign user it states "campaign DB user".
We have two levels of user and several types. Some are standard and come with a new database, some are created.
To my logic an application user and application administrator should only see and administrate application users.
A database user is created by the database administrator, typically during software installation.
At work, with our ERP applicatiion "baan" we will have thousands of application users "john-23", "purchase-2" etc. Among them will be a small number of super users "Super-1" etc.
However, on a small system we may have only one user "baan-1" that connects to and writes to the database. On a bigger system we will parralellise so there may be "baan-1", "baan-2","baan-n" writing to the database but never "john-23". We actualy do pass through to the database the fact that "john-23" is the originator of the write, so that we can audit later but this is data and stored in a table or logfile. With the security level required by Boswar this is not needed.
So currently I am not sure in our user control when we are talking about boswar users and mysql users. Could we clarify?
Next, when I hit the boswar server from a separate machine I can see directly into htdocs. Since we have moved index.php and the rest one level down into website I think our connect_db that is used sits in htdocs instead of above. I think this is a security risk? Our requires need to jump 2 levels up?
There you go, idle hands generate work