The static groups are not the solution for my application because I don't
know in advance how many cinemas will be entered, what will be their names,
the relation between Users and Cinemas, and etc.
Your solution is not close to the real world situations. Your solution is
private case of the common situations in the world and is not suitable for
my applications.
Maybe I have to return to JBoss where this can be realized?
Why you do private case as principals instead to implements the real world
situations which can solve private cases also?
Miro.
On 5/15/07, Bobby Bissett - Javasoft <Robert.Bissett_at_sun.com> wrote:
>
> >
> > I am not sure that I understand your suggestion. If I am login with some
> > user which is with fixed groups how this groups will be changed when I
> > am on different objects?
>
> What I'm suggesting is that you never change the groups. Instead, you
> have a group for each specific situation. Now I understand that you're
> talking about one application, not separate ones. So you could have a
> large group users, and smaller groups cinema-manager, museum-manager, etc.
>
> > Imagine that the application is looking like Windows Explorer where the
> > left side is one Tree, and the right side is a table. You select an
> > object cinema "Metropolitan" which extends Company where you are the
> > boss. So, in this case you must to have "cinema-manager" group and
> > rights. Then you select another cinema "Multiplex" where you are just
> > user. In this case you must to have "cinema-user" group and rights. Both
> > cinemas are children of parent Cinema which extends Company for example.
> > The same with another type of objects like museums, warehouses, etc.
> > How this will be realized with your suggestion?
>
> Groups: users, metropolitan-manager, multiplex-manager, etc. A person
> would be in the general user group and then also in whatever *-manager
> group was appropriate. You can also have "higher level" groups such as
> cinema-manager and the multiplex manager resources would only be able to
> be accessed by users in groups multiplex-manager and cinema-manager.
>
> With your idea of changing the group based on the user and resource
> being accessed, you'd have to have some way to know which users have
> access to what resource that didn't have anything to do with groups. In
> my suggestion, the groups are finer grained and take care of all that
> for you in the first place.
>
> The dynamic idea scares me a little because you have to be very sure
> there's not a way for a user to gain access s/he should not have. For
> instance, principal P is only a user for resource R1 but is a manager
> for resource R2. So, when accessing R2, if you change P to be in a
> generic "manager" group, there could be some way for P to access R1 as a
> manager if you're not careful. In a web application, for instance, this
> would be as simple as accessing R2 and then pasting the R1 url into the
> browser before doing any other action that would cause him to be removed
> from the manager group. Your application sounds different, but I just
> wanted to give an example of the worst case scenario.
>
> Cheers,
> Bobby
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>