You are right, Scott; in my example I did not deal with 'unsecure' modules/templates... probably the best solution is the one illustrated in one of the Turbine's docs (maybe the Velocity Howto, but I'm not sure...): two super classes (e.g. WeakScreen, without security controls, and StrongScreen, with security controls) extended by the modules. Thus all the modules that don't need a security check extend the WeakScreen (or WeakAction) and don't belong to any group. So the log-in procedure is necessary only to gain access to 'group' modules while the 'no-group' modules are always accessible.
Do you think that this could be a good solution? And what about modules belonging to more than one group? (e.g. a BuyBookAction action module that is used by trusted users both in the SHOP and OFFICE groups)... Thank you Scott, Jacopo > I like everything in Jacopo's post, plus this: the ability to nominate a > default user for the site and implement this by extending screens and > actions. This user's security is used for all transactions until the user > manually signs in. > > Example: > > SCOTT decides to visit the MagicShop to browse it's wonderful and eclectic > selection of books. However, he does not have an account nor does he want > one at this moment. He just wants to SEARCH and READ as a part of the SHOP > group without worrying about signing in. IMOHO, he should be able to do > this. > > Scott > > -----Original Message----- > From: Jacopo Cappellato [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 18, 2001 10:43 AM > To: [EMAIL PROTECTED] > Subject: Best way to use groups, roles, permission... > > > As I have written in another message posted to this list (subject: "Security > framework for modules"), I'm trying to understand which are the best > practices about the use of Turbine's security stuff. > In this thread I would like to discuss with you on this issue: > what is the best way to use Turbine's groups, roles, permissions and users > in a complex web application? > > This is my humble opinion. > ************************** > some definitions: > web application: a (servlet-) context (this is the universe, nothing exists > out of here) > user: someone that can interact with the web application (e.g. jacopo) > role: a generic (e.g. administrator, guest, operator...) set of permissions > permission: a single, generic (e.g. write, read, delete...) or specific > (e.g. viewPurchasePrize...) task > group: a set of logically related modules (actions and screens) within the > same web application (universe) > > This is the big picture: > a Turbine user is created for a web application; > there is only one entry point (a login screen) in the web application; > the web application is made up of many modules (screens, actions and so on); > the web application can be divided in different domains; > a domain is a Turbine group, and so it is a set of related modules; > if a user wants to interact with a particular domain, he/she must have a > role (or, at least, sufficient permissions) within the domain's group > > Example (rather stupid): > web application: MagicShop, an on-line bookshop > users: TOM (the application's administrator), JOHN (an employee), PAUL (a > customer) > domains/groups: SHOP (this is where a customer can search and buy books), > ADMIN (this is where an administrator can, for example, set the whole > application default language), OFFICE (this is where the employers change > the book list, manage customers' orders and so on...) > permissions: four generic VIEW, SEARCH, WRITE, DELETE permissions and a > specific SEND_A_GIFT one > roles: GUEST (a generic read-only role made up of VIEW and SEARCH > permissions) and OPERATOR (a generic read-write role made up of VIEW, > SEARCH, WRITE and DELETE permissions) > > TOM has in group ADMIN the role of OPERATOR and in group OFFICE the role of > GUEST (in fact he is also a supervisor for the office tasks) > JOHN has in group OFFICE the role of OPERATOR > PAUL has in group SHOP the role of OPERATOR > TOM has in group OFFICE the special permission SEND_A_GIFT (in fact he is > the only one that can send a gift to special customers) > > TOM, JOHN, PAUL log in through the same place Login.vm but then they see > different index pages... > > Ok... let's stop now!!! What do you think of all this stuff? What about the > pros and cons of this solution (flexibility, semplicity???). > I would like to know your ideas... > > Thank you in advance, > Jacopo > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
