Yes, I think I will do it with an additional table on the db server, for the moment (I have no time to implement parsing etc...)
The problem is, like you stated, to mantain that table up to date with changes in system tables. The best solution would be a trigger for this, but we haven't them at the moment in MySQL. Since any other solution will expose the client app to the possibility it has invalid information, I will have to handle access denied etc... but this is the less. I will have to pray system administrators to do user management exclusivly through a special application provided by me, which will keep the *table* updated. If administrators will use MySQL to store other databases than mine, my solution will be quite poor. On Tue, 23 Dec 2003 16:02:19 -0330 "jamie murray" <[EMAIL PROTECTED]> wrote: > Plinio, > Hence my suggestion for use of a flat file. The file can be located on the > db server middle tier wherever it doesnt matter. > The important part is that you control what goes in the file and its done > ahead of time not when an enduser presses a button. > What about creating tables the users can view loaded with the system table > information your users need to see(same as flat file just do it with table > in the database). > It would be much better if you could get the information together and then > let endusers view it as opposed > to firing two statements and going through a bunch of parsing etc ... like > you stated below everytime they press a button. > The route your taking will be slower,more resource intensive and more > complicated. > > > > > ----- Original Message ----- > From: "Plinio Conti" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, December 23, 2003 11:58 AM > Subject: Re: Quering user privileges > > > > To be honest, the fact I can't get it with only one query but I have to > do: > > > > 1) SELECT CURRENT_USER(); > > > > 2) SHOW GRANTS FOR valueExtractedByPreviousQuery; > > > > is a little thing compared with work remaing to get usefull information: > > I have to parse the strings returned by query 2, handle the wildcards, > handle "ALL PRIVILEGES", comparing db-level privileges with table-level ones > and with column-level ones, etc... > > > > I probably will do all that, only I wonder there is not a more simple > solution. > > > > I mean, it looks a so common issue that I imagine there is better solution > but I can't figure which. > > > > User authenticates, and client app wants to know what that user is allowed > to do, so the app can show to its user the correct user interface (for > example editing disabled if user can't write, etc..) > > > > > > > > > > -- > > MySQL General Mailing List > > For list archives: http://lists.mysql.com/mysql > > To unsubscribe: > http://lists.mysql.com/[EMAIL PROTECTED] > > > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
