API and restricing DB access via DA

[BWH]

Hi

I want to offer clients on my box access to a database but don't want to give complete access so I was going to write an API.

I wanted to restrict it to only users with a certain type of account and also make sure that it was only being used by clients on the local machine.

Is there some way I can tap into DA's database and verify their account or is this even necassary?

I'm assuming I can allow them to use the API by having an include on all there pages that will use it. Correct? If so what would the path look like? Perhaps a fully qualified path including drive etc? Also if I provided a fully qualified path is there any way they could then use that to access the file and find out the DB name and password etc?

Any and all help appreciated.

Thanks

BWH

 

[ballyn]

I'm unclear as to what you actually want to do, here... Are you saying you want to give certain users access to a "shared" database, or are you just talking about mysql databases in general?

If it's the latter, you can restrict users access to mysql by setting their mysql databases to 0. This will effectively keep them from using databases as all. In regards to the local machine, you can just modify the my.cnf file to skip_networking, in which case the mysql server will only listen on the local socket.

As to the API, you're actually talking about two things, I think... a "plugin" that will present additional options in the DA panel and custom scripts that leverage the DA API to complete some tasks. This is all non-trivial and I'd suggest looking at the plugin docs to get some ideas.

If you'll give a little more information as to what you're specifically trying to do, it will be easier to give you some concrete examples.

 

[BWH]

Hi

Thanks for the response.

Well I don't want to restrict users to not have any access to mysql so that's not really an option.

I want to allow them to utlize one particular database via PHP but not be able to alter the data or easily export it or recreate it.

I think writing my own functions to access the database would be the best solution and offering these to clients (kind of like an API). I'll need to be able to ensure that they are authorized as in they have a certain account and that they are accessing from the localserver. I'll take a look at the api documentation I think.

UPDATE*
I've just looked at the API documentation and still not quite clear.

I am thinking of a scenario where lets say user1 has an account on the local machine and writes code to access my restricted database. He will have a set of functions that I supply (my API) that will interface with my private script that will access the database and return the results.

I need a way to allow him to include the file with my private functions in a way that will not allow him to actually view the file and therefore get access to the database.

I'm thinking a simple include would work but not sure of the path? Perhaps the normal '/home/my_private_files/....'type thing would sufice? Would having this information as to where the file was enable him to download it and access it though? I don't want that.

Also from my private scripts I will need to confirm that he has access to the DB so will need to have him pass his DA username and password and then verify it with DA's API (not sure how to do this). Also I would like to confirm he's accessing it from localhost but I guess this would be easy enough.

**end of update

Thanks

BWH

 

[gpfault]

Hi

Thanks for the response.

Well I don't want to restrict users to not have any access to mysql so that's not really an option.

I want to allow them to utlize one particular database via PHP but not be able to alter the data or easily export it or recreate it.

BWH

Assigning a unique username and password for each individual user should restrict them to the database that you grant them priveleges to.

I need a way to allow him to include the file with my private functions in a way that will not allow him to actually view the file and therefore get access to the database.

BWH [/B]

If you do not allow the user shell access and put your PHP script in your home directory. ie. somewhere below the public_html directory and then call this file from your (API) then a user would only be able to access your functions in the PHP file via your API functions I think.

Also from my private scripts I will need to confirm that he has access to the DB so will need to have him pass his DA username and password and then verify it with DA's API (not sure how to do this). Also I would like to confirm he's accessing it from localhost but I guess this would be easy enough.

BWH [/B]

You can do anything with the DA API that you can through the control panel. It would be very easy to create a login page to log into DA using the API. After a succesful login you could then use the DA API methods to verify the usertype of the user. Via the CMD_API_SHOW_USER_CONFIG DA API method.

I would suggest taking a look at the PHP and Java communications classes also.

 

[BWH]

Thanks for that. I'm definitely closer now

I've done some testing with the api and I've figured out a way to verify that a user passing the script a username and domain is verifiable.

I'm using the 'socks' wrapper but it occurs to me that if I'm not actually goint to be doing the check on the client side but rather on the server end is this necassary (would it even work?).

I'm also thinking it would be stupid to check every single time a user tried to access the functions via my API (not to mention a complete waste of resoures. Does anybody have a better alternative. Maybe a temporary file that says their authorized. And have the file expire after a certain amount of time.

I'm getting confused again...time for another coffee...

Lux

 

[gpfault]

Thanks for that. I'm definitely closer now

I'm also thinking it would be stupid to check every single time a user tried to access the functions via my API (not to mention a complete waste of resoures. Does anybody have a better alternative. Maybe a temporary file that says their authorized. And have the file expire after a certain amount of time.

I'm getting confused again...time for another coffee...

Lux

If your using the DA API why not save the session ID after a successful login and then use that session ID to make successive calls to the DA API? As long as the session does not timeout of course.

 

[ballyn]

Originally posted by gpfault
If you do not allow the user shell access and put your PHP script in your home directory. ie. somewhere below the public_html directory and then call this file from your (API) then a user would only be able to access your functions in the PHP file via your API functions I think.

Not strictly true... if the php script is readable by the web server, the user can probably read the contents of it (including passwords, etc.) unless you've done a thorough web server hardening.

 

[gpfault]

Not strictly true... if the php script is readable by the web server, the user can probably read the contents of it (including passwords, etc.) unless you've done a thorough web server hardening.

Okay. So any ideas how to do it?

Also there would be no need to store the username or passwords in plain sight in the PHP Script. Me personally I would never write code that would store sensitive data in plain sight, but that's just me.

If the same username and password for the logged in DA user were also used for their database account having the user log into DA first would be the authentication verification for the database access. Hence no sensitive data stored in plain sight anywhere. Then the PHP script would simply be the logic for accessing the database and making queries.

I am working on something similar using Java. I am working on creating an install script for billing software I am developing. The whole idea is that an admin enters their host information, the port DA is listening on, and their DA username and password. If the login to DA was successful and the usertype of the user is reseller or admin the script then attempts to create a MySQL database for that user if one is available. The script makes several calls to the DA API. The user does not have to enter their username and password each time. They only need to have one successful login and my script then saves the session ID to make successive calls to DA's API.