Alex Peshkov wrote:

>Si Carter wrote:
>
>
>
>>
>>
>>
>>
>>>-----Original Message-----
>>>It's a question of control. With coteries you can let less
>>>privileged
>>>users come in from anywhere but restrict SYSDBA (or whatever) to
>>>specific hosts or hosts strictly behind the firewall.
>>>
>>>
>>>
>>>
>>This sounds like a good idea, and certainly one which enhances an RFE I
>>added in January
>>(http://sourceforge.net/tracker/index.php?func=detail&aid=1108195&group_id=9
>>028&atid=359028). More and more web hosts are starting to allow customers
>>to use FB, imo, a block at the firewall level is not a good solution, if
>>your customers have dynamic ip at home/office and want to connect and their
>>new IP is not in the list they can't get in. Allowing FB to control this
>>would be a fantastic enhancement.
>>
>>
>>
>>
>
>May be it's time to discuss details.
>
>1. In which form should coteries be kept? To allow access from network
>192.168.3.0 known forms are at least:
>192.168.3.0/24
>192.168.3.0/255.255.255.0
>192.168.3.0
>192.168.3.
>My prefered style is 1, but it's interesting to know other people's mind.
>
>2. How should be cotteries entered? Should we add switches to gbak?
>Services API? Isc_user_* family of functions? (I know Jim will answer
>that it's necessary to have fb_authenticate_user, but for fb2 this is
>unreal suggestion).
>
>3. Do we let user have infinite number of coteries or limit it with some
>reasonable thing? Answer is not very simple, if we want to let user
>modify his coteries himself. If limited, should it be configurable or
>hardcoded?
>
>

Hi Alex,


I prefer this:

192.168.3.0/24

or

192.168.3.123

for a full ip address

How cotteries should be managed ?
It will be per database ? per server ?
The data should reside insede the database ? or should have some config file (cotteries.conf) ? Or will be just a field in the RDB$USERS ? or even a tbale RDB$COTTERIES that has a FK to RDB$USERS ?

if it will be stored inside the database in system tables, users could update it as wish using simple SQL no need to an API call.

see you !



--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br