On Fri, Sep 24, 2010 at 2:05 PM, tedd <tedd.sperling@xxxxxxxxx> wrote: > At 11:19 AM +0100 9/24/10, Tom Barrett wrote: >> >> On 22 September 2010 21:40, Bastien Koert <phpster@xxxxxxxxx> wrote: >> >>> Not at all. What I would suggest is that you create a separate mysql >>> user that is used exclusively by the script to do the create stuff. >>> The regular application user account should not have those privileges >>> at all. >>> >> >> I'm not actually that familiar with DB admin to that extent. I have either >> app users with lock+crud on specific databases, or root. As a an aside, >> would you know if there is a level of permissions for a user between app >> and >> root that would be 'sensibly secure' (it will be MySQL 5)? >> >> >>> Another option, if immediate response is not required, is to save this >>> data into the system for a cron script with another user account to >>> run. >>> >> >> This was sort of my first instinct. I ponder writing a small daemon/cron >> that queries a database table (client list) and does all the 'build' bits. >> The main issue with cron is that the users would want a fairly immediate >> response. Seconds is acceptable, but a 5 minute cron might be too slow. >> >> >>> Is there a reason for you not to place all the data in one DB and just >>> separate them out based on user id, to ensure they only see their own >>> data >>> >> >> For legal reasons. Each client must have separate data. I need to be able >> to >> box up all the client data (containing multiple app instances) and be 100% >> sure that I am giving them all their data and nobody else's. >> >> On 23 September 2010 18:04, tedd <tedd.sperling@xxxxxxxxx> wrote: >> >>> No, but from what you've said, I don't think the end user must have >>> privileges and the ability to create a database and tables. It sounds >>> more >>> like allowing the user to set up his own admin for acceptable users -- >>> there's a big difference. >>> >>> So, what you need to define is what the client and his users want to do. >>> From that, we can determine what they need. >> >> >> Depending on what you mean by 'the client', all the client side things are >> fine :) >> The web front-end I am working on here is for internal use only. To allow >> non-technical people to set up clients and their apps. >> >> The more I look into this, the more I am leaning towards some shell >> scripts >> for client management, invoking them by cron. Then if an immediate >> response >> is needed someone technical will have to manually run the cron job. It >> looks >> like the law of diminishing returns for me to build something really >> usable. > > The more I hear, the more confused I get. > > I still don't understand what your client is going to do? > > Cheers, > > tedd > > -- > ------- > http://sperling.com/ > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > @tedd, He wants not techie users to create new systems for their clients when they sign up. It involves creating a DB and he's wondering about security for that. The main part of the app needs the least priv's to run (select, update, insert [,delete]) while the creating the DB obviously takes more. The OP was asking how to best handle that since the he didn't want to give the main app DB user account more privs than needed. -- Bastien Cat, the other other white meat -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
