Jurjen Roels
|
| Posted: 06/06/2002, 2:29 AM |
|
wouldn't it be easier to use a table security groups and load all groups from that table into the security groups tab in the project settings.
now you have to maintain a table and the tab to show the roles on the websites.
Regards
Jurjen
|
|
|
 |
Nicole
|
| Posted: 06/06/2002, 5:31 AM |
|
Jurien,
but current version let you create users groups during project design or event do not use them at all.
Do you think it is not good?
|
|
|
|
Brent
|
| Posted: 06/06/2002, 8:43 AM |
|
I have to agree with Jurjen. The security groups should be database driven. What happens
if you have several CCS applications for the same database? You're going to have
to maintain/synchronize several separate security group settings. There is no way
to share the security groups among applications. 
If the security groups were in a database table, it would travel with the database.
Just my 2 cents. :)
Brent
|
|
|
|
Ron Gines
|
| Posted: 06/06/2002, 9:46 AM |
|
I would agree that the security should be driven by a database table(s). This surprised me when I started using CodeCharge and the Studio.
One of the things I have historically done with my Intranet clients is use the NT Authentication instead of the simple security for log on. There are a lot of benefits, especially since you automatically know who has hit your site without them logging in. One of the plans is to try to convert the CC/CCS security over to allow for NT Authentication using IIS/ASP. Given the need define the security levels within CC/CCS itself is going to make it much more difficult than I believe that it needs to be.
Just my 2.5 cents worth ....
|
|
|
|
schaeff
|
| Posted: 06/06/2002, 12:03 PM |
|
Speaking of an ideal world:
If YES should realy make the groups db driven I would prefer an n:n relationship between users and groups. That means using a user table, a group table and an additional table for the relationships, so that users can be members of several groups.
my 2 cents
|
|
|
|
DaveRexel
|
| Posted: 06/06/2002, 3:47 PM |
|
I also prefer the security groups in table model
this solution by scheaff is good:
If YES should realy make the groups db driven I would prefer an n:n relationship between users and groups.
I would like to choose the table for each project.
Greetings,
Dave
|
|
|
|
Ron
|
| Posted: 06/10/2002, 2:07 PM |
|
I wonder why Yes choose to limit the security options to what the saw fit. I feel it would have been easy to add a user defined field to the choices they offer.
Something like:
- user id (field)
- login (field)
- password (field)
- sec.level(field)
- user defined (field)
I now have to figure out how to extend the login procedure to include a "domain" field I have been using in a modified CC login procedure.
Ron
|
|
|
|
