Menu
▾
▴
jsecurity-developer — Not for support. Please direct user/support questions to the other lists/forums
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(11) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(8) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: lhazlewood (s. by Nabble.com) <li...@na...> - 2006-01-30 14:10:31
|
I don't know when we'll get our first release out. I was kind of hoping that it would be on Sunday of this coming week (Feb 5th), but our work schedules have really prevented us from making much progress in the last few weeks. The sooner the better, but I have to first write an introductory article to be posted on TheServerSide or OnJava prior to release, and that will take me a little while. So, I dunno. As soon as our schedules allow ;) -- View this message in context: http://www.nabble.com/Official-Release-Date--t831207c13668.html#a2660353 Sent from the Developer forum at Nabble.com. |
|
From: Justin B. <ju...@ro...> - 2006-01-30 02:31:25
|
When are you currently scoped for first release? Justin Senior Partner Roundbox Media Atlanta GA ju...@ro... 404.877.0107 |
|
From: Les A. H. <le...@js...> - 2006-01-29 21:44:46
|
I definitely agree that we need to document how the two are used. I'll get started on the method name refactoring probably after we finish a deadline at work on Tuesday. |
|
From: jhaile (s. by Nabble.com) <li...@na...> - 2006-01-28 22:40:18
|
No objections here. That makes sense to me. I currently use the annotations exclusively, although I'll be using the taglibs soon. One thing that I have found developers getting confused with is when to use role-based authorization vs. permission-based authorization. We use permission based authorization exclusively, and I can't think of many good examples of where you would want to mix the two. I think role-based authorization can be good for simple or relatively static security models, whereas permission based authorization is much more flexible. I don't think this should result in any API changes, but perhaps we should discuss this in our documentation. -- View this message in context: http://www.nabble.com/hasPermission-implies-t1016271c13668.html#a2639538 Sent from the Developer forum at Nabble.com. |
|
From: jhaile (s. by Nabble.com) <li...@na...> - 2006-01-28 22:37:05
|
Well, I remember looking at removing the Principal interface when I was changing the AuthorizationContext to support multiple principals, and I remember something about it made me unsure of whether I thought it was a good thing or not. For example, I think some of our logging printed out the principal of the authorization context, etc. - so there is some nice things about having an interface. I don't really have any strong feelings either way. It is nice that there is some type-safety, but at the same time they don't add all that much. Feel free to try removing them, but if you see anything that convinces you that they do have some value, feel free to leave them in as well. -- View this message in context: http://www.nabble.com/AuthenticationToken-Principal-clean-up-t1016241c13668.html#a2639516 Sent from the Developer forum at Nabble.com. |
|
From: lhazlewood (s. by Nabble.com) <li...@na...> - 2006-01-28 20:13:15
|
That last sentence was supposed to read "I really want to do this to squash further confusion that will certainly arise after the first release." ;) -- View this message in context: http://www.nabble.com/hasPermission-implies-t1016271c13668.html#a2638053 Sent from the Developer forum at Nabble.com. |
|
From: lhazlewood (s. by Nabble.com) <li...@na...> - 2006-01-28 16:52:27
|
Ok, so I want to make one more change prior to first release. So, we have this notion so far of AuthorizationContext.hasPermission and other similar methods. In talking with some other developers, maybe some with lesser experience in the Java security world, they were confused about what this meant exactly. - Did it mean that the subject actually _had_ that exact permission (exact being exact same class, target, and actions i.e. equals()), or did it mean something else? Currently what it really means is that any of the subject's Groups and/or Roles had permissions which implied the permission argument - its not a HAS A relationship in the formal sense. So, what I'd like to do, is rename that and other similar methods to implies(), just like the signature that exists on the Permission interface. To me (and to the other developers), this makes much more sense, since it doesn't foster thoughts of concrete OO relationships, which is not what permissioning is all about. This will require some changes in my current projects, but they will be minimal at best (we don't call the API directly - mostly just use annotations and JSP taglibs). I really want to do this to squash further confusion that will certainly arise after the first week. Any objections? Les -- View this message in context: http://www.nabble.com/hasPermission-implies-t1016271c13668.html#a2635989 Sent from the Developer forum at Nabble.com. |
|
From: lhazlewood (s. by Nabble.com) <li...@na...> - 2006-01-28 16:43:57
|
Heya, After talking about the 'usefulness' of the Principal interface (since it only requires equals(), toString() and hashCode() implementations) we had discussed removing it as a required dependency of JSecurity framework classes. I'd like to remove that interface and probably the AuthenticationToken interface for the same reasons. Any objections to this? If we're going to do this, I'd like to do it this week. I really want to get the first release out by Friday (seriously this time). Les -- View this message in context: http://www.nabble.com/AuthenticationToken-Principal-clean-up-t1016241c13668.html#a2635900 Sent from the Developer forum at Nabble.com. |
|
From: lhazlewood (s. by Nabble.com) <li...@na...> - 2005-12-31 18:48:32
|
I want to make an official release date and hold us to it ;) Next weekend would be nice (Jan 8), if we can do it. Maybe the 15th if we spend more time on documentation. Jeremy, Any objections? What else do you want to do before that release, other than cleaning up the LDAP/ActiveDirectory authc modules? -- Sent from the Developer forum at Nabble.com: http://www.nabble.com/Official-Release-Date--t831207c13668.html#a2156369 |
|
From: lhazlewood (s. by Nabble.com) <li...@na...> - 2005-12-31 03:40:25
|
I think the Permission class is too widespread and ingrained in the Java security mindset to abandon it. Aside from minor inconveniences, it seems to work well enough. The name itself is very intuitive to new users (i.e. everyone is pretty comfortable with the terms 'user' 'role' and 'permission'), so this is a good thing. I'm good with leaving the name/target attribute as '*'. This to me is certainly better than what we have now, which always forces a two 2-arg-constructor to be used. If the developer doesn't like it, they can manually override the target to be whatever they want. At least this gives them flexibility over how the permission is constructed, unlike the current code. So, I'll go ahead and make the change of the default actions string from "*" to "" and update the permission instantiation logic accordingly. This is good, I've now achieved the warm-n-fuzzy feeling I was looking for ;) -- Sent from the Developer forum at Nabble.com: http://www.nabble.com/HasPermission-default-target-and-actions-t826978c13668.html#a2150970 |
|
From: jhaile (s. by Nabble.com) <li...@na...> - 2005-12-31 02:08:23
|
Hmmm - but #2 is what I do everywhere. If the Permission class assumes that a name/target will always be specified, why not just leave the default target as "*"? We could make actions optional though if we want to allow a 1-arg constructor. Alternatively we could drop the use of the Permission JDK class entirely and create a JSecurity permission class. I wonder what issues that would cause in the adoption of JSecurity. On the one hand, I think users wouldn't care. On the other hand, it might make it easier to migrate from an existing JAAS implementation. -- Sent from the Developer forum at Nabble.com: http://www.nabble.com/HasPermission-default-target-and-actions-t826978c13668.html#a2150592 |
|
From: lhazlewood (s. by Nabble.com) <li...@na...> - 2005-12-30 22:59:18
|
Yes, this is exactly what I was thinking. But, according to the Permission class and subclasses, a single argument String constructor is always assumed to be the name/target parameter, never the actions. So, we should throw an exception if #2 ever occurred (i.e. that would be a configuration error). And yes, because of the JDK limiting null defaults, I would expect the empty string to mean unspecified (and probably convert to null in the code). -- Sent from the Developer forum at Nabble.com: http://www.nabble.com/HasPermission-default-target-and-actions-t826978c13668.html#a2149214 |
|
From: jhaile (s. by Nabble.com) <li...@na...> - 2005-12-30 22:36:51
|
So would the defaults be "" and JSecurity would know that if you specify an empty string it should use a 1 or 2 arg constructor? There definitely needs to be some default value, and annotations will not allow you to default them to null, so I imagine we will need to use an empty string. So, 1) if I specify @HasPermission(type="..") JSecurity will use a 0-arg constructor. 2) if I specify @HasPermission(type="..", actions="read"), JSecurity will use a 1-arg constructor. 3) if I specify @HasPermission(type="..", target="123"), JSecurity will again use a 1-arg constructor? 4) if I specify @HasPermission(type="..",target="123",actions="read") JSecurity will use a 2-arg constructor. Is this what you are thinking? If not, please give me a similar example and be sure to be specific about what the default values would be. -- Sent from the Developer forum at Nabble.com: http://www.nabble.com/HasPermission-default-target-and-actions-t826978c13668.html#a2148957 |
|
From: lhazlewood (s. by Nabble.com) <li...@na...> - 2005-12-30 22:30:50
|
I had thought of doing this, but it rubs me the wrong way. What about the case where a Permission class has a 1 and 2 argument constructor. If I specify the annotation with just a target/name and no actions, I expect the 1 argument constructor to be called. That would not happen now since JSecurity automatically assumes the second argument must be defaulted to the wildcard - thereby calling the 2 argument constructor, even if the developer didn't intend that to happen. If one desires the default behavior (as do I almost all of the time), I think it is better form to have a 1 argument constructor that merely calls the two argument constructor, automatically filling in the second argument as the wildcard. In fact, the JSecurity InstancePermission already does this. If one specifies just a name and no actions, and there does not exist a single-argument constructor, this should be a programming error - not something JSecurity 'fixes' behind the scenes. That is, I feel it should be the responsibility of the person implementing the Permission class to provide that default behavior if desired (as with InstancePermission), not JSecurity. By having JSecurity do things they way they are now, we limit flexibilty by enforcing a certain programming paradigm, which I don't favor when implementing a wide-use framework. -- Sent from the Developer forum at Nabble.com: http://www.nabble.com/HasPermission-default-target-and-actions-t826978c13668.html#a2148896 |
|
From: jhaile (s. by Nabble.com) <li...@na...> - 2005-12-30 20:10:50
|
Well, one option would be to leave the defaults as they are now, but enhance the "constructor guessing" in PermissionAnnotationAuthorizationModule. All we need to do is catch NoSuchMethodException when getting the declared constructor. I would assume the guessing would go something like this: 1) First check for the two arg constructor. (target, action) 2) Check for a single arg constructor (only action) 3) Check for a no-arg constructor. This would of course be specified in JavaDoc and referenced both by the PermissionAnnotationAuthorizationModule and the HasPermission annotation classes. -- Sent from the Developer forum at Nabble.com: http://www.nabble.com/HasPermission-default-target-and-actions-t826978c13668.html#a2147481 |
|
From: lhazlewood (s. by Nabble.com) <li...@na...> - 2005-12-30 20:04:52
|
I think my concern comes from using Permission classes without 2 arg constructors. As a framework, I think we should support their use if developers want to use them. For example, this example method would not work as things stand now: @HasPermission(type=com.company.pkg.MyPermission.class, target="someName") public void foo(); if the MyPermission class only had a default no-arg or single arg constructor. JSecurity would try to look up a two-arg constructor because of the '*' argument sent implicitly as the default. Here's an interesting note though - A _lot_ of JDK Permission implementations have a 2 arg constructor, but usually ignore the 2nd argument entirely, just to maintain constructor parallelism with the BasicPermission class from which they extend. This is yet another example of the poor design decisions made in JAAS. Anyway, these dummy constructors are convenient for us, but requires custom Permission implementers who use JSecurity to make sure they do the same thing - pretty inconvenient for them and propagates the poor design. Do we want to force them to do this? -- Sent from the Developer forum at Nabble.com: http://www.nabble.com/HasPermission-default-target-and-actions-t826978c13668.html#a2147416 |
|
From: jhaile (s. by Nabble.com) <li...@na...> - 2005-12-30 19:17:06
|
Maybe you could provide a little more info as to how the HasPermission tag would work if we made this change. Currently, all of my permissions have 2-arg constructors. I also do not use the ACL feature, but instead only ever specify the class name and the action(s) - therefore depending upon the default value of "*". The HasPermission annotation currently assumes that all permission classes have a 2-arg constructor. If we changed the annotation to not default to "*" for target and actions, what would it default to? I don't want to have to specify target for every annotation since I don't even use it. Is the HasPermission module going to guess at how many args the constructor takes in? etc etc? I could make up possibilities all day long, but how exactly are you proposing the tag would work if we changed the default from "*"? -- Sent from the Developer forum at Nabble.com: http://www.nabble.com/HasPermission-default-target-and-actions-t826978c13668.html#a2146878 |
|
From: lhazlewood (s. by Nabble.com) <li...@na...> - 2005-12-30 17:27:11
|
I'm thinking we should remove the default target and actions ('*') in the HasPermission annotation.
Automatically defaulting to these will cause problems if the user wants to specify a permission class that doesn't have a 2 (or even 1) argument constructor.
I'm explicitly thinking of classes like AllPermission or similar ones. Although we are assuming that Permission instances will act as JSecurity's ACL mechanism, there is no reason why the framework shouldn't support other Permission classes that don't conform 100% to this assumption.
Will this pose any problems to you if the defaults become null?
--
Sent from the Developer forum at Nabble.com:
http://www.nabble.com/HasPermission-default-target-and-actions-t826978c13668.html#a2145624
|
|
From: Les A. H. <le...@ha...> - 2005-12-06 03:53:23
|
Welcome to the JSecurity-Developer integrated mailing list / support forum. This is not a support forum/list and is to be used by JSecurity developers to discuss architecture, design patterns, and development tasks. Please use any of the other, more appropriate forum/lists for user/support posts. |
