If roles should be implemented with interfaces, how assign them dynamically in webapp

Hello, I read that inheritance defines what you are and interfaces define what roles you have.

But if you want to create a webapp where users can have different roles, those roles sometimes should be assignable (dynamically) during runtime. E.g. when a user adds a role to his profile.

In my case if users have more roles they should contain more info (have additional records).

But since implementing interfaces is something that has to be done during compile time it seems that I have to implement all possible roles (interfaces) in my user object, and just leave the unused role dependent records blank. But this seems quite inefficient to me.

I read that inheritance defines what you are and interfaces define what roles you have.

Without further context, this statement doesn't make sense to me. Can you point us to the source, or give examples of the kinds of interfaces involved?

It also doesn't seem to be true. User names, password and roles are often represented as strings; for example, that's how web app security sees it (see this for how one implementation -Tomcat- deals with that).

It's true that the Java security infrastructure is based on interfaces (as opposed to concrete classes) - have a look at the java.security.* and javax.security.* packages, which are full of interfaces. But those interfaces are generic, and rarely need to be tailored for a particular implementation. Maybe that's what the statement meant?

Without further context, this statement doesn't make sense to me. Can you point us to the source, or give examples of the kinds of interfaces involved?

It also doesn't seem to be true. User names, password and roles are often represented as strings; for example, that's how web app security sees it (see this for how one implementation -Tomcat- deals with that).

It's true that the Java security infrastructure is based on interfaces (as opposed to concrete classes) - have a look at the java.security.* and javax.security.* packages, which are full of interfaces. But those interfaces are generic, and rarely need to be tailored for a particular implementation. Maybe that's what the statement meant?

Thanks a lot for the fast reply!

Well I'm thinking about roles that are not specifically related to security / access levels. I want to make users able to add roles as being profiles.

E.g. users can add a dj or (music)producer profile to their user profile.

And the statement I used was derived (hopefully correct) from:

On page 118 (Chapter 2: Object Orientation) of the "SCJP for Java 5 study guide" (by Bert Bates and Cathy Sierra) you can find this sentence:

"But remember that subclassing defines who and what you are, whereas implementing defines a role you can play or a hat you can wear, despite how different you might be from some other class implementing the same interface (but from a different inheritance tree)."

On page 118 (Chapter 2: Object Orientation) of the "SCJP for Java 5 study guide" (by Bert Bates and Cathy Sierra) you can find this sentence:

"But remember that subclassing defines who and what you are, whereas implementing defines a role you can play or a hat you can wear, despite how different you might be from some other class implementing the same interface (but from a different inheritance tree)."

You took this sentence completely out of context I'm affraid It has no bearing whatsoever on information security.

Edit: Too slow. [ August 14, 2008: Message edited by: Jelle Klap ]

Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.

So I guess that if a user can add multiple profiles/roles to his user profile, it should not be implemented as interfaces because they can't be assigned during runtime?

I was already programming the structure of the user object with a collection that can contain profile/role objects for that user, but the sentence I quoted confused me because I interpreted it as "roles should be implemented as interfaces".

That sentence is referring to the roles the objects play in the system, not to user roles - both ArrayList and LinkedList can play the role of a List.

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus

Ulf Dittmer
Rancher

Joined: Mar 22, 2005
Posts: 42958

73

posted Aug 14, 2008 13:49:00

0

So I guess that if a user can add multiple profiles/roles to his user profile, it should not be implemented as interfaces because they can't be assigned during runtime?

Modeling roles as interfaces might still be OK if the set of roles is fixed, and doesn't change over time. But if new roles are added (not to a user - to the system as a whole), you'd have to add a new interface. That would get tiresome quickly.

So the question is not so much whether a user gets assigned a different set of roles, but whether the system allows completely new roles to be introduced. If it does, modeling them through interfaces isn't a good idea.