Menu
▾
▴
firebird-devel
|
From: Jim <hak...@gm...> - 2011-04-13 06:31:24
|
Hi all, I've been thinking about a feature request that might be of use for us lowly non-Firebird developers, hopefully in the 3.0 timeframe ;) ======================================================================== What: automatically keep track of databases once accessed on a server and present that in a system view/table. ======================================================================== Why: developers/end users can more easily choose and connect to a database on a Firebird server, even point and click. Hopefully better SQL standard conformance. See pros below. ======================================================================== Pros: - Ease of use for end users: -- Their applications can be modified to provide point and click GUI connection options: avoids typos, extra documentation, looking up aliases, and bothering IT staff. - Ease of use for developers: -- In house apps that keep track of databases can be converted -- Firebird.Net driver can add schema support, e.g. for support of the SharpDevelop database plugin and better support for Visual Studio. -- As mentioned above, developers can use adapted drivers in GUI/RAD environments to connect to a database by visually selecting it. Avoids typos, extra documentation, and looking up aliases. - Easily usable from applications even without driver support (just query RDB$DATABASES if you already have a valid connection, e.g. to employee.fdb) - Hopefully better conformance with SQL standard; if nothing else, good from a PR/marketing perspective Cons: - Increased code complexity/maintenance - Security issue: leakage of information on databases present on system. - Security issue: denial of service attacks with valid credentials by bruteforcing database aliases has increased impact (due to more code executing). Remediation: turn of DatabaseAutoRegistration in fb.conf; needs to be documented in manual/release notes ======================================================================== Assumptions/requirements: - Firebird process has write access to firebird.conf. Should be documented in manual/release notes. See below for troubleshooting. Phase 1: must have for this feature to be usable: 1.1 Parameter in firebird.conf called something like AutoRegistration, default false, to control this feature. 1.2 If Firebird process has no write access to firebird.conf, log error in regular error log. 1.3 System view/table like RDB$DATABASES that returns the list of alias entries (not the actual file path). This allows devs/end users to query this to get an overview of databases on the server. 1.4 If a DROP DATABASE command is committed, delete the entry in aliases.conf and RDB$DATABASES. For performance reasons, maybe don't delete the aliases.conf entry and rely on auto clean up (see below) 1.5 If a CREATE DATABASE command is committed, add the entry to aliases.conf and RDB$DATABASES. Phase 2: should have for this feature to be easily usable: 2.1 Auto clean up of databases that have been deleted: also covers OS level deletion of files if server is not running: 2.1.1 When a connection attempt to a database failed, set a boolean field RDB$DATABASES.ACCESSFAILED, and the date it first as RDB$DATABASES.ACCESSFAILEDDATE 2.1.2 On succesful connection, clear those fields 2.1.3 Have firebird.conf parameter AutoRegistrationAutoDeleteDelay or similar; values in days, hours or minutes. If set to 0, don't use this feature. Suggest default 7 days to allow dba's time to fix access problems. 2.1.4 Whenever connection attempt is made again, if RDB$DATABASES.ACCESSFAILED is true, check if time interval exceeds AutoRegistrationAutoDeleteDelay, and delete row from RDB$DATABASES. Phase 3: nice to have: 3.1 Not only record database name from aliases, but also things the engine reads on connection (e.g. page size, charset,...), possibly file location (possibly only accessible to server SYSDBA for security) 3.2 Only return those databases that current (end) user that connects to the db has open (or connect or whatever it's called) privileges for. ======================================================================== Links to possibly relevant issues in tracker: - CORE-737 SQL INFORMATION_SCHEMA support; only references SQL standard. - CORE-738 SQL Schemas support. Not very much info. - CORE-1422 aliases.conf registration feature request (subset of this one) See also: description of way to get database info, reference to SQL2003 INFORMATION_SCHEMA: http://www.alberton.info/firebird_sql_meta_info.html ======================================================================== Suggestions for things to do/check: - Verify SQL standard regarding schemata for the items to return in RDB$DATABASES. I don't have the standard, so I can only infer what's in it from websites - Verify with driver developers (.Net, JDBC, ODBC, Python, ...) what they'd like to see supported. I suppose this thread covers that... - Look at competition/open source colleagues on what is in their solution (Interbase, PostgreSQL, Oracle, MS SQL Server) and align with them as much as possible - Contact Embarcadero to notify of change, ask they do the same: win win situation as tools that support both Firebird and Interbase will likely more quickly implement this if both servers support (at least a subset of) the same functionality. ======================================================================== I'd like your feedback on this idea before creating a tracker item. thanks, -- Regards, jb |
|
From: Dmitry Y. <fir...@ya...> - 2011-04-13 07:17:48
|
13.04.2011 10:31, Jim wrote: > > - Ease of use for end users: > -- Their applications can be modified to provide point and click GUI > connection options: avoids typos, extra documentation, looking up > aliases, and bothering IT staff. Even if this proposal would ever be implemented, I'd suppose it would limit the access to the databases list by SYSDBA only (for security reasons). And I'm afraid this is going to break the main benefit, as regular applications should never be using SYSBDA permissions. Dmitry |
|
From: Alex P. <pes...@ma...> - 2011-04-13 07:40:04
|
On 04/13/11 10:31, Jim wrote: I will comment this mainly from security POV. > Why: developers/end users can more easily choose and connect to a > database on a Firebird server, even point and click. Point and click should be implemented by client, not by server. > Cons: > - Increased code complexity/maintenance Not too much... > - Security issue: leakage of information on databases present on system. This is very serious issue. Knowing what particular databases are present makes it easier to attack them. > - Security issue: denial of service attacks with valid credentials by > bruteforcing database aliases has increased impact (due to more code > executing). Remediation: turn of DatabaseAutoRegistration in fb.conf; > needs to be documented in manual/release notes > With valid credentials one can have much more efficient attacks on server. > ======================================================================== > > Assumptions/requirements: > - Firebird process has write access to firebird.conf. Should be > documented in manual/release notes. See below for troubleshooting. Write access from daemon to it's configuration files is very bad from security POV. |
|
From: Geoff W. <ge...@te...> - 2011-04-13 08:03:16
|
>> Why: developers/end users can more easily choose and connect >> to a database on a Firebird server, even point and click. > Point and click should be implemented by client, not by server. I cannot speak for the original author, but it seems to me the one BIG advantage of offering aliases.conf via a system table (even if limited to RDB$ADMIN) is the ability to let Firebird take care of the network connection/transfer aspects. That is: At the moment maintenance of aliases.conf (and Firebird.conf) must necessarily take place outside Firebird. If access were offered via system tables then Firebird is able to use existing authentication and connection facilities that the developer can take advantage of to then offer point and click to administrative users. That is: a developer need only learn one API to maintain their server, regardless of what operating system the server runs on. This is quite a big plus from a developer's perspective: one interface and set of instructions to offer the user, however installed. Certainly access to such a feature would need to be very carefully controlled. The current system of offering no access at all is quite secure - or at least secure from the point of view of Firebird, what the implementers may end up doing to work around the limitation (eg: sharing the program folder so remote administrators can access the files) is something quite different, but from Firebird's perspective that is SEP (Someone Else's Problem). So I can see the advantages of the suggestion. -- Geoff Worboys Telesis Computing |
|
From: Alex P. <pes...@ma...> - 2011-04-13 09:17:09
|
On 04/13/11 12:02, Geoff Worboys wrote: >>> Why: developers/end users can more easily choose and connect >>> to a database on a Firebird server, even point and click. >> Point and click should be implemented by client, not by server. > I cannot speak for the original author, but it seems to me the > one BIG advantage of offering aliases.conf via a system table > (even if limited to RDB$ADMIN) is the ability to let Firebird > take care of the network connection/transfer aspects. > > That is: At the moment maintenance of aliases.conf (and > Firebird.conf) must necessarily take place outside Firebird. Yes, and this is like all secure daemons work. Have you ever seen something like DNS server, which changes it's configuration itself? Or HTTP server, doing such tricks? File sharing daemon like samba can change own configuration if it's conf file is shared, but for me this means badly administered site. (And even in this case one can't make changes active, i.e. restart samba). Why should database access server modify his configuration? > If access were offered via system tables then Firebird is able > to use existing authentication and connection facilities that > the developer can take advantage of to then offer point and > click to administrative users. That is: a developer need only > learn one API to maintain their server, regardless of what > operating system the server runs on. This is quite a big plus > from a developer's perspective: one interface and set of > instructions to offer the user, however installed. > > Certainly access to such a feature would need to be very > carefully controlled. The current system of offering no > access at all is quite secure - or at least secure from the > point of view of Firebird, what the implementers may end up > doing to work around the limitation (eg: sharing the program > folder so remote administrators can access the files) is > something quite different, but from Firebird's perspective > that is SEP (Someone Else's Problem). > > So I can see the advantages of the suggestion. To have all mentioned facilities one needs another tool - additional service to manage server operation. And such tools exist - see for example fbDataGuard. |
|
From: Geoff W. <ge...@te...> - 2011-04-13 09:45:58
|
Alex Peshkoff wrote: > Yes, and this is like all secure daemons work. Have you ever > seen something like DNS server, which changes it's configuration > itself? Or HTTP server, doing such tricks? File sharing daemon > like samba can change own configuration if it's conf file is > shared, but for me this means badly administered site. (And > even in this case one can't make changes active, i.e. restart > samba). Why should database access server modify his > configuration? Because he can? More seriously. Yes I know there are important security considerations BUT I thought perhaps people were overlooking what I see as the biggest potential advantage of the request. Just because it is a risk does not take away the potential for advantage. You have to weigh the two and decide whether the risk is worth the cost ... or not. ... > To have all mentioned facilities one needs another tool - > additional service to manage server operation. And such tools > exist - see for example fbDataGuard. Yep, or the developer can write their own. New APIs new source, new requirements, greater complication. Extra tools also have their cost (from the perspective of the developer) and are not, necessarily, inherently more secure. The solution proposed would (or could be) be more simple (for a developer using Firebird) than finding and implementing something completely separate. It may even be more secure that some possibilities. I can certainly see why people are wary of leaping to adopt the idea, but I think the request is worth of serious discussion, rather than immediate discard because there is some risk. -- Geoff Worboys Telesis Computing |
|
From: Dimitry S. <sd...@ib...> - 2011-04-13 10:05:36
|
13.04.2011 11:45, Geoff Worboys wrote: > More seriously. Yes I know there are important security > considerations BUT I thought perhaps people were overlooking > what I see as the biggest potential advantage of the request. > Just because it is a risk does not take away the potential > for advantage. And what this advantage is? End-user application are usually written to work with certain DB. Connection to any different DB will crash them. And even if DB structure by coincidence fits an expected one, results of user's work can be unexpected. Say, I have two similar DB on server: production one and development one. User in application sees two databases and have the choice - which database to connect to. In the best case I would expect complaints "I have been working hard for two days, but all data are lost". So, such registration is useless for end users. Developers already have all their databases registered in IBExpert/Flame Robin/etc. Besides, their databases can be on different servers. So this feature is useless for them too. -- SY, SD. |
|
From: Jim <hak...@gm...> - 2011-04-13 10:33:56
|
On 13-4-2011 12:04, Dimitry Sibiryakov wrote: > 13.04.2011 11:45, Geoff Worboys wrote: >> More seriously. Yes I know there are important security >> considerations BUT I thought perhaps people were overlooking >> what I see as the biggest potential advantage of the request. >> Just because it is a risk does not take away the potential >> for advantage. > > And what this advantage is? > End-user application are usually written to work with certain DB. Connection to any > different DB will crash them. And even if DB structure by coincidence fits an expected > one, results of user's work can be unexpected. > Say, I have two similar DB on server: production one and development one. User in > application sees two databases and have the choice - which database to connect to. In the > best case I would expect complaints "I have been working hard for two days, but all data > are lost". > So, such registration is useless for end users. > Developers already have all their databases registered in IBExpert/Flame Robin/etc. > Besides, their databases can be on different servers. > So this feature is useless for them too. > Dimitry, Geoff, thanks for your input. In my view, the big advantage for me as a developer would be to use IDEs, ORM generators, report generators, etc more easily if there is GUI support, e.g. such as implemented in Visual Studio for SQL Server. I agree that connecting to the wrong DB can be disastrous. It would still be up to the application showing a connection choice GUI to deal with this (e.g. checking database, maybe db version identifier in a certain table). The advantage is that you can more easily decouple serverside database name (and path!) from your end users. Your clients won't have to add alias lines themselves; your installer won't have to do that either. Renaming a database on the server side is less problematic. As for dbs being on different servers: I suppose asking for Bonjour/Rendezvous support would be out of the question ;) More seriously, it is possible to do a port scan on port 3050 on all IPs in a subnet, if that is what it takes to discover default Firebird/Interbase servers. I do understand the objections, but I think this feature makes Firebird a bit more newbie-friendly and increases the "you don't have to think about it, it just works" factor. -- Regards, jb |
|
From: Dimitry S. <sd...@ib...> - 2011-04-13 11:05:52
|
13.04.2011 12:33, Jim wrote: > I do understand the objections, but I think this feature makes Firebird > a bit more newbie-friendly and increases the "you don't have to think > about it, it just works" factor. Currently Firebird already has low entry threshold and it compromised Firebird's reputation. I'm afraid that making it even more newbie-friendly is a bad idea. -- SY, SD. |
|
From: Geoff W. <ge...@te...> - 2011-04-13 11:40:45
|
Dimitry Sibiryakov wrote:
> 13.04.2011 11:45, Geoff Worboys wrote:
>> More seriously. Yes I know there are important security
>> considerations BUT I thought perhaps people were overlooking
>> what I see as the biggest potential advantage of the request.
>> Just because it is a risk does not take away the potential
>> for advantage.
> And what this advantage is?
> End-user application are usually written to work with
> certain DB. Connection to any different DB will crash them.
> ...
Hmmm... I find it hard to believe that I am the only person to
use Firebird more widely than that. For my application there
are various databases, each identified by a common table (which
if it does not exist means it's not one of "our" databases).
These databases include things such as various archives etc,
storage separated for practical reasons. The details are all
maintained in a central administrative database using an
"manager" application that the user-administrator MUST run on
the Firebird server because that application keeps the admin
database and the aliases.conf file in sync. (End-user apps
access the admin database to find the list of databases that
are available for specific functions.)
This works quite well, but something like the request would
solve a few problems.
. at the moment the manager app MUST be run on the
server computer to get access to aliases.conf
. as a result of this the server must currently be
Windows (at least until I get around to writing
a Linux variation)
. the database administrator must be given operating
system administrative access to that computer (in
order to maintain the data file in the program
directory)
As you can see I already have an adequate solution for my
purposes, so I am not going to argue too hard for this request.
However I do think the solution could be better if I were not
tied in this way to a Windows server ... and anyway, this gives
you at least one example of why someone may want to let their
users maintain aliases.conf via some controlled interface.
--
Geoff Worboys
Telesis Computing
|
|
From: Jim <hak...@gm...> - 2011-04-13 10:25:01
|
On 13-4-2011 9:39, Alex Peshkoff wrote: > On 04/13/11 10:31, Jim wrote: > > I will comment this mainly from security POV. Ok, thanks. > >> Why: developers/end users can more easily choose and connect to a >> database on a Firebird server, even point and click. > > Point and click should be implemented by client, not by server. Agreed. I meant that a point & click interface on the client side can be implemented more easily this way. Otherwise you'd have to write a serverside daemon that scans for all fdb files or something, bringing other risks. > >> - Security issue: leakage of information on databases present on system. > > This is very serious issue. Knowing what particular databases are > present makes it easier to attack them. Yes, that is true. That's why I suggested turning the feature off by default and documenting this. As I envision the feature, though, you would have to have valid credentials to the server first.... (On the other hand, brute forcing an 8 character password and a mostly unchanged SYSDBA username isn't too hard; you could add some common database names (e.g. employee, data, application name/default name for certain applications) and try to brute force that too. But that discussion is another one. I don't intend to start a flame war about how my feature is insecure but it's already insecure, so... ;) In other words, yes it is a risk. > >> - Security issue: denial of service attacks with valid credentials by >> bruteforcing database aliases has increased impact (due to more code >> executing). Remediation: turn of DatabaseAutoRegistration in fb.conf; >> needs to be documented in manual/release notes >> > > With valid credentials one can have much more efficient attacks on server. See above. > >> ======================================================================== >> >> Assumptions/requirements: >> - Firebird process has write access to firebird.conf. Should be >> documented in manual/release notes. See below for troubleshooting. > > Write access from daemon to it's configuration files is very bad from > security POV. Oooops, big mistake on my part. I meant aliases.conf of course. Still, I see your point that this is not as secure as not allowing access. I suppose the extra risks for aliases would be: - If you gain unauthorized access to the server process in some way: -- Denial of service because you can delete aliases. -- Impersonation attacks because you could change aliases. Would require access to the filesystem on the server. -- Exploiting race conditions or other weaknesses that corrupt aliases.conf resulting in denial of service. Of course it's a tradeoff. If you want to be more conservative, you could mandate that aliases.conf should not be touched. In this way, you lose dynamic registration, and have the administrator manage the list of databases shown in RDB$DATABASES. This actually is a simpler solution that might be practical in an enterpise environment. Thanks for the valuable feedback, -- Regards, jb |
|
From: Vlad K. <hv...@us...> - 2011-04-13 10:34:36
|
> In this way, you lose dynamic registration, and have the administrator
> manage the list of databases shown in RDB$DATABASES.
In what database ?
Regards,
Vlad
|
|
From: Mark R. <Ava...@gm...> - 2011-04-13 10:41:54
|
> > In this way, you lose dynamic registration, and have the administrator > > manage the list of databases shown in RDB$DATABASES. > > In what database ? I'd suggest: aliases.fdb ;) -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone |
|
From: Jim <hak...@gm...> - 2011-04-13 10:49:20
|
On 13-4-2011 12:34, Vlad Khorsun wrote: >> In this way, you lose dynamic registration, and have the administrator >> manage the list of databases shown in RDB$DATABASES. > > In what database ? > > Regards, > Vlad Hi Vlad, You mean in what database does RDB$DATABASES reside? You got the weak point in my original argument, which I had overlooked. Yes, you would need to connect to the server with valid credentials, and retrieve this table. I had thought to supply RDB$DATABASES in all regular databases as it is generated by the database engine anyway. However, how do you know with what database to connect in the first place - Firebird won't allow you to connect without a database at the moment. Chicken & egg problem. Right now, I see 3 ways to solve this: 1. Just insist users connect to an existing database, same as now. A bit stupid; you might misuse employees.fdb for this but it would still be inelegant. 2. Allow connections for these serverwide maintenance/query tasks without a database specified. Needs code changes, obviously. 3. Use a default database, e.g. specified in aliases.conf, equivalent to SQL Server/Sybase master. Maybe even use a security database for this (note: I know nothing about security implications regarding this option)? Downside: any user with an existing database called this will have to change their db name. If you mean "where does the admin keep track of the list of databases that will be shown in RDB$DATABASES": this list will still be generated by Firebird by reading aliases.conf, so the admin will maintain aliases.conf just like he is doing now. -- Regards, jb |
|
From: Kjell R. <kje...@da...> - 2011-04-13 10:55:58
|
Den 2011-04-13 12:34 skrev Vlad Khorsun såhär: >> In this way, you lose dynamic registration, and have the administrator >> manage the list of databases shown in RDB$DATABASES. > > In what database ? This obvious question has two possible answers as I see it: 1. All. Any database you're connected to contains the data Jim suggests in its rdb$databases "virtual table" (view?). 2. None. This whole thing is better suited for an API than a system table/view. And possibly a third answer: 3. Some other system wide database. The security database would be an option, but it seems a bit odd. So, the suggested aliases.fdb might be an option. But, all things considered, I feel that the feature is too complicated and has too many security implications to be worth it. If anything, I might suggest that the alias config that's already present could be augmented with a flag for each alias specifying if it should be available for browsing or not (default = no). Those marked as available for browsing could be accessible via an API function for that specific purpose. Kjell -- -------------------------------------- Kjell Rilbe DataDIA AB E-post: kj...@da... Telefon: 08-761 06 55 Mobil: 0733-44 24 64 |
|
From: Alex P. <pes...@ma...> - 2011-04-13 11:13:19
|
On 04/13/11 14:55, Kjell Rilbe wrote: > But, all things considered, I feel that the feature is too complicated > and has too many security implications to be worth it. If anything, I > might suggest that the alias config that's already present could be > augmented with a flag for each alias specifying if it should be > available for browsing or not (default = no). Those marked as available > for browsing could be accessible via an API function for that specific > purpose. > This is quite reasonable option. |
|
From: Jim <hak...@gm...> - 2011-04-13 11:25:26
|
On 13-4-2011 13:13, Alex Peshkoff wrote: > On 04/13/11 14:55, Kjell Rilbe wrote: >> But, all things considered, I feel that the feature is too complicated >> and has too many security implications to be worth it. If anything, I >> might suggest that the alias config that's already present could be >> augmented with a flag for each alias specifying if it should be >> available for browsing or not (default = no). Those marked as available >> for browsing could be accessible via an API function for that specific >> purpose. >> > > This is quite reasonable option. Would be fine for me, too, but I suppose you'd have about the same security risk compared to a virtual table/view: you could set permissions on a virtual table/view too I suppose, and couple that to Kjell's idea for flags in aliases.conf. Regardless, I would appreciate a reasonable way to get this info. If having this in an API would be easier/more elegant than a system view, that's fine with me. In any case, Kjell's suggestion to extend aliases.conf would be quite clear, and allow granular administration as well! This will remove the need to have an extra option in firebird.conf. -- Regards, jb |
|
From: Dmitry Y. <fir...@ya...> - 2011-04-13 11:28:05
|
13.04.2011 15:13, Alex Peshkoff wrote: > >> But, all things considered, I feel that the feature is too complicated >> and has too many security implications to be worth it. If anything, I >> might suggest that the alias config that's already present could be >> augmented with a flag for each alias specifying if it should be >> available for browsing or not (default = no). Those marked as available >> for browsing could be accessible via an API function for that specific >> purpose. > > This is quite reasonable option. Agreed. The question about location of the database list remains open, however. Dmitry |
|
From: Kjell R. <kje...@da...> - 2011-04-13 11:35:10
|
Den 2011-04-13 13:28 skrev Dmitry Yemanov såhär: > 13.04.2011 15:13, Alex Peshkoff wrote: >> >>> But, all things considered, I feel that the feature is too complicated >>> and has too many security implications to be worth it. If anything, I >>> might suggest that the alias config that's already present could be >>> augmented with a flag for each alias specifying if it should be >>> available for browsing or not (default = no). Those marked as available >>> for browsing could be accessible via an API function for that specific >>> purpose. >> >> This is quite reasonable option. > > Agreed. The question about location of the database list remains open, > however. In what way? It is present in aliases.conf and I presume the server will either read this file on each attempt to connect to an alias, or cache the alias list somewhere in memory. Either way, the API function to retrieve browsing-marked aliases would fetch the list in exactly the same way as the connect function. I see no reason to do it any other way, unless you want to expose it in a system view (e.g. rdb$databases) in all databases as suggested by Jim a few minutes ago. But I'm against that - it makes it more complicated than it has to be. How is this feature related to upcoming support for schemas? I expect there's a potential overlap... Kjell -- -------------------------------------- Kjell Rilbe DataDIA AB E-post: kj...@da... Telefon: 08-761 06 55 Mobil: 0733-44 24 64 |
|
From: Dmitry Y. <fir...@ya...> - 2011-04-13 11:44:40
|
13.04.2011 15:34, Kjell Rilbe wrote: >> Agreed. The question about location of the database list remains open, >> however. > > In what way? It is present in aliases.conf and I presume the server will > either read this file on each attempt to connect to an alias, or cache > the alias list somewhere in memory. I meant the "virtual" location, i.e. the way to retrieve the list: services API vs some virtual table. If the latter, where it's going to reside. > How is this feature related to upcoming support for schemas? I expect > there's a potential overlap... I fail to see an overlap. Schemas are per-database, so you have access to them once connected. Dmitry |
|
From: Thomas S. <ts...@ib...> - 2011-04-13 11:49:54
|
>>> Agreed. The question about location of the database list remains open, >>> however. >> >> In what way? It is present in aliases.conf and I presume the server will >> either read this file on each attempt to connect to an alias, or cache >> the alias list somewhere in memory. > > I meant the "virtual" location, i.e. the way to retrieve the list: > services API vs some virtual table. If the latter, where it's going to > reside. In InterBase 7.5 and up, it's a table called DB_ALIAS in the security database. Regards, Thomas |
|
From: Alex P. <pes...@ma...> - 2011-04-13 11:39:51
|
On 04/13/11 15:28, Dmitry Yemanov wrote: > 13.04.2011 15:13, Alex Peshkoff wrote: >>> But, all things considered, I feel that the feature is too complicated >>> and has too many security implications to be worth it. If anything, I >>> might suggest that the alias config that's already present could be >>> augmented with a flag for each alias specifying if it should be >>> available for browsing or not (default = no). Those marked as available >>> for browsing could be accessible via an API function for that specific >>> purpose. >> This is quite reasonable option. > Agreed. The question about location of the database list remains open, > however. > Services API? |
|
From: Dimitry S. <sd...@ib...> - 2011-04-13 11:46:58
|
13.04.2011 13:39, Alex Peshkoff wrote: >> Agreed. The question about location of the database list remains open, >> however. >> > > Services API? MON$DATABASES?.. -- SY, SD. |
|
From: Dmitry Y. <fir...@ya...> - 2011-04-13 11:48:16
|
13.04.2011 15:39, Alex Peshkoff wrote: > Services API? This would get my vote. I'm just unsure how much happy users are going to be with this solution. Dmitry |
|
From: Kjell R. <kje...@da...> - 2011-04-13 11:53:45
|
Den 2011-04-13 13:48 skrev Dmitry Yemanov såhär: > 13.04.2011 15:39, Alex Peshkoff wrote: > >> Services API? > > This would get my vote. I'm just unsure how much happy users are going > to be with this solution. If client component sets expose the API in an easy-to-use manner, I assume most users will be quite happy with it. Is the services API usually exposed in such component sets? Kjell -- -------------------------------------- Kjell Rilbe DataDIA AB E-post: kj...@da... Telefon: 08-761 06 55 Mobil: 0733-44 24 64 |
Thanks for helping keep SourceForge clean.
X