Re: Type safe roles for AUTH-ROLES?
heh. it is a functional example of a fully implemented authorization
strategy. but it doesnt have any fancy features, nor will they be
added to it in the future. it is meant to serve as an example, so
users can see how to implement their own authorization strategies.
what more do you want me to say exactly?
-igor
On Jan 14, 2008 1:51 PM, Dan Kaplan [EMAIL PROTECTED] wrote:
What? Really? Fuck. Can you please elaborate? Did I waste every second
of the time I spent looking at the examples on wicketstuff? I applied these
examples to my webapp. Did I implement some type of pretend authorization
strategy?
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 12, 2008 10:31 AM
To: users@wicket.apache.org; [EMAIL PROTECTED]
Subject: Re: Type safe roles for AUTH-ROLES?
wicket-auth-roles is just an example. its not really meant to be
something you drop into your application, for that there is
wicketstuff-wasp and wicketstuff-swarm
-igor
On Jan 12, 2008 9:14 AM, Jeremy Thomerson [EMAIL PROTECTED]
wrote:
I have several successful Wicket projects going, and in all have used my
own
authorization strategy based on annotations. I'm just trying
wicket-auth-roles for my next project, but seem confused by the apparent
String-only roles. I already have a domain model where a User has a Role
or
Role(s), where Role is a class. This promotes type-safety, etc, etc.
But, I can't go:
@AuthorizeInstantiation({ Role.ADMIN, Role.SUPER_USER,
Role.MEMBER_SERVICE_REP, Role.MEMBER })
I also can't do:
@AuthorizeInstantiation({ Role.ADMIN.name(), Role.SUPER_USER.name (),
Role.MEMBER_SERVICE_REP.name(), Role.MEMBER.name() })
So, do I *have* to use Strings? Or is there another way? If I have to
use
Strings, then I either have to redefine all my roles and change how the DB
stores them, or just use the names of my own roles (i.e . SUPER_USER
which
later my UserAuthorizer does a Role.valueOf(String) on), and risk typoes
messing me up, or have Role.SUPER_USER and Role.SUPER_USER_NAME as a
public
static final String.
It's been a long week - I could be missing something.
Thanks in advance.
Jeremy
-
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]
RE: Type safe roles for AUTH-ROLES?
What? Really? Fuck. Can you please elaborate? Did I waste every second
of the time I spent looking at the examples on wicketstuff? I applied these
examples to my webapp. Did I implement some type of pretend authorization
strategy?
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 12, 2008 10:31 AM
To: users@wicket.apache.org; [EMAIL PROTECTED]
Subject: Re: Type safe roles for AUTH-ROLES?
wicket-auth-roles is just an example. its not really meant to be
something you drop into your application, for that there is
wicketstuff-wasp and wicketstuff-swarm
-igor
On Jan 12, 2008 9:14 AM, Jeremy Thomerson [EMAIL PROTECTED]
wrote:
I have several successful Wicket projects going, and in all have used my
own
authorization strategy based on annotations. I'm just trying
wicket-auth-roles for my next project, but seem confused by the apparent
String-only roles. I already have a domain model where a User has a Role
or
Role(s), where Role is a class. This promotes type-safety, etc, etc.
But, I can't go:
@AuthorizeInstantiation({ Role.ADMIN, Role.SUPER_USER,
Role.MEMBER_SERVICE_REP, Role.MEMBER })
I also can't do:
@AuthorizeInstantiation({ Role.ADMIN.name(), Role.SUPER_USER.name (),
Role.MEMBER_SERVICE_REP.name(), Role.MEMBER.name() })
So, do I *have* to use Strings? Or is there another way? If I have to
use
Strings, then I either have to redefine all my roles and change how the DB
stores them, or just use the names of my own roles (i.e . SUPER_USER
which
later my UserAuthorizer does a Role.valueOf(String) on), and risk typoes
messing me up, or have Role.SUPER_USER and Role.SUPER_USER_NAME as a
public
static final String.
It's been a long week - I could be missing something.
Thanks in advance.
Jeremy
-
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]
Re: Type safe roles for AUTH-ROLES?
In my opinion there is nothing 'wrong' with auth-roles. but they are
limited in scope. Fortunately the code base is really small so it
wouldn't take that much effort to roll your own based on that code.
That said, I think that a lot of applications can live with the 3
levels of authorization: none, user and admin provided by auth-roles.
Martijn
(who likes using auth-roles)
On 1/14/08, Dan Kaplan [EMAIL PROTECTED] wrote:
I guess I'll have to read about swarm/wasp to read about what fancy features
I'm missing out on. But, ATM, I'm content to stay with it because
auth-roles are simple and allow me to move on to the actual content of my
webapp. Am I going to be kicking myself later for that choice?
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Monday, January 14, 2008 1:55 PM
To: users@wicket.apache.org
Subject: Re: Type safe roles for AUTH-ROLES?
heh. it is a functional example of a fully implemented authorization
strategy. but it doesnt have any fancy features, nor will they be
added to it in the future. it is meant to serve as an example, so
users can see how to implement their own authorization strategies.
what more do you want me to say exactly?
-igor
On Jan 14, 2008 1:51 PM, Dan Kaplan [EMAIL PROTECTED] wrote:
What? Really? Fuck. Can you please elaborate? Did I waste every second
of the time I spent looking at the examples on wicketstuff? I applied
these
examples to my webapp. Did I implement some type of pretend
authorization
strategy?
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 12, 2008 10:31 AM
To: users@wicket.apache.org; [EMAIL PROTECTED]
Subject: Re: Type safe roles for AUTH-ROLES?
wicket-auth-roles is just an example. its not really meant to be
something you drop into your application, for that there is
wicketstuff-wasp and wicketstuff-swarm
-igor
On Jan 12, 2008 9:14 AM, Jeremy Thomerson [EMAIL PROTECTED]
wrote:
I have several successful Wicket projects going, and in all have used my
own
authorization strategy based on annotations. I'm just trying
wicket-auth-roles for my next project, but seem confused by the apparent
String-only roles. I already have a domain model where a User has a
Role
or
Role(s), where Role is a class. This promotes type-safety, etc, etc.
But, I can't go:
@AuthorizeInstantiation({ Role.ADMIN, Role.SUPER_USER,
Role.MEMBER_SERVICE_REP, Role.MEMBER })
I also can't do:
@AuthorizeInstantiation({ Role.ADMIN.name(), Role.SUPER_USER.name (),
Role.MEMBER_SERVICE_REP.name(), Role.MEMBER.name() })
So, do I *have* to use Strings? Or is there another way? If I have to
use
Strings, then I either have to redefine all my roles and change how the
DB
stores them, or just use the names of my own roles (i.e . SUPER_USER
which
later my UserAuthorizer does a Role.valueOf(String) on), and risk typoes
messing me up, or have Role.SUPER_USER and Role.SUPER_USER_NAME as a
public
static final String.
It's been a long week - I could be missing something.
Thanks in advance.
Jeremy
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Type safe roles for AUTH-ROLES?
Sure, and although not an included option, can't I just make a new one named
moderator and use that where I want? I haven't tried this but I assume
the library won't care.
-Original Message-
From: Martijn Dashorst [mailto:[EMAIL PROTECTED]
Sent: Monday, January 14, 2008 2:22 PM
To: users@wicket.apache.org
Subject: Re: Type safe roles for AUTH-ROLES?
In my opinion there is nothing 'wrong' with auth-roles. but they are
limited in scope. Fortunately the code base is really small so it
wouldn't take that much effort to roll your own based on that code.
That said, I think that a lot of applications can live with the 3
levels of authorization: none, user and admin provided by auth-roles.
Martijn
(who likes using auth-roles)
On 1/14/08, Dan Kaplan [EMAIL PROTECTED] wrote:
I guess I'll have to read about swarm/wasp to read about what fancy
features
I'm missing out on. But, ATM, I'm content to stay with it because
auth-roles are simple and allow me to move on to the actual content of my
webapp. Am I going to be kicking myself later for that choice?
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Monday, January 14, 2008 1:55 PM
To: users@wicket.apache.org
Subject: Re: Type safe roles for AUTH-ROLES?
heh. it is a functional example of a fully implemented authorization
strategy. but it doesnt have any fancy features, nor will they be
added to it in the future. it is meant to serve as an example, so
users can see how to implement their own authorization strategies.
what more do you want me to say exactly?
-igor
On Jan 14, 2008 1:51 PM, Dan Kaplan [EMAIL PROTECTED] wrote:
What? Really? Fuck. Can you please elaborate? Did I waste every
second
of the time I spent looking at the examples on wicketstuff? I applied
these
examples to my webapp. Did I implement some type of pretend
authorization
strategy?
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 12, 2008 10:31 AM
To: users@wicket.apache.org; [EMAIL PROTECTED]
Subject: Re: Type safe roles for AUTH-ROLES?
wicket-auth-roles is just an example. its not really meant to be
something you drop into your application, for that there is
wicketstuff-wasp and wicketstuff-swarm
-igor
On Jan 12, 2008 9:14 AM, Jeremy Thomerson [EMAIL PROTECTED]
wrote:
I have several successful Wicket projects going, and in all have used
my
own
authorization strategy based on annotations. I'm just trying
wicket-auth-roles for my next project, but seem confused by the
apparent
String-only roles. I already have a domain model where a User has a
Role
or
Role(s), where Role is a class. This promotes type-safety, etc, etc.
But, I can't go:
@AuthorizeInstantiation({ Role.ADMIN, Role.SUPER_USER,
Role.MEMBER_SERVICE_REP, Role.MEMBER })
I also can't do:
@AuthorizeInstantiation({ Role.ADMIN.name(), Role.SUPER_USER.name (),
Role.MEMBER_SERVICE_REP.name(), Role.MEMBER.name() })
So, do I *have* to use Strings? Or is there another way? If I have
to
use
Strings, then I either have to redefine all my roles and change how
the
DB
stores them, or just use the names of my own roles (i.e . SUPER_USER
which
later my UserAuthorizer does a Role.valueOf(String) on), and risk
typoes
messing me up, or have Role.SUPER_USER and Role.SUPER_USER_NAME as a
public
static final String.
It's been a long week - I could be missing something.
Thanks in advance.
Jeremy
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
-
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]
RE: Type safe roles for AUTH-ROLES?
I guess I'll have to read about swarm/wasp to read about what fancy features
I'm missing out on. But, ATM, I'm content to stay with it because
auth-roles are simple and allow me to move on to the actual content of my
webapp. Am I going to be kicking myself later for that choice?
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Monday, January 14, 2008 1:55 PM
To: users@wicket.apache.org
Subject: Re: Type safe roles for AUTH-ROLES?
heh. it is a functional example of a fully implemented authorization
strategy. but it doesnt have any fancy features, nor will they be
added to it in the future. it is meant to serve as an example, so
users can see how to implement their own authorization strategies.
what more do you want me to say exactly?
-igor
On Jan 14, 2008 1:51 PM, Dan Kaplan [EMAIL PROTECTED] wrote:
What? Really? Fuck. Can you please elaborate? Did I waste every second
of the time I spent looking at the examples on wicketstuff? I applied
these
examples to my webapp. Did I implement some type of pretend
authorization
strategy?
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 12, 2008 10:31 AM
To: users@wicket.apache.org; [EMAIL PROTECTED]
Subject: Re: Type safe roles for AUTH-ROLES?
wicket-auth-roles is just an example. its not really meant to be
something you drop into your application, for that there is
wicketstuff-wasp and wicketstuff-swarm
-igor
On Jan 12, 2008 9:14 AM, Jeremy Thomerson [EMAIL PROTECTED]
wrote:
I have several successful Wicket projects going, and in all have used my
own
authorization strategy based on annotations. I'm just trying
wicket-auth-roles for my next project, but seem confused by the apparent
String-only roles. I already have a domain model where a User has a
Role
or
Role(s), where Role is a class. This promotes type-safety, etc, etc.
But, I can't go:
@AuthorizeInstantiation({ Role.ADMIN, Role.SUPER_USER,
Role.MEMBER_SERVICE_REP, Role.MEMBER })
I also can't do:
@AuthorizeInstantiation({ Role.ADMIN.name(), Role.SUPER_USER.name (),
Role.MEMBER_SERVICE_REP.name(), Role.MEMBER.name() })
So, do I *have* to use Strings? Or is there another way? If I have to
use
Strings, then I either have to redefine all my roles and change how the
DB
stores them, or just use the names of my own roles (i.e . SUPER_USER
which
later my UserAuthorizer does a Role.valueOf(String) on), and risk typoes
messing me up, or have Role.SUPER_USER and Role.SUPER_USER_NAME as a
public
static final String.
It's been a long week - I could be missing something.
Thanks in advance.
Jeremy
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Type safe roles for AUTH-ROLES?
for a comparison between auth-roles and swarm/wasp, take a look at http://wicketstuff.org/confluence/display/STUFFWIKI/Security+Framework+Comparison gerolf On Jan 14, 2008 11:14 PM, C. Bergström [EMAIL PROTECTED] wrote: On Mon, 2008-01-14 at 13:51 -0800, Dan Kaplan wrote: What? Really? F***. Can you please elaborate? Did I waste every second of the time I spent looking at the examples on wicketstuff? I applied these examples to my webapp. Did I implement some type of pretend authorization strategy? http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security +Examples Sources are available here.. https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-security-examples maybe this is more in the ballpark of what you were expecting? ./C - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Type safe roles for AUTH-ROLES?
No, I'm perfectly happy with the functionality provided by the examples on wicketstuff. I just want to make sure they are secure. I don't want to use them if they're giving me a false sense of security. -Original Message- From: C. Bergström [mailto:[EMAIL PROTECTED] Sent: Monday, January 14, 2008 2:15 PM To: users@wicket.apache.org Subject: RE: Type safe roles for AUTH-ROLES? On Mon, 2008-01-14 at 13:51 -0800, Dan Kaplan wrote: What? Really? F***. Can you please elaborate? Did I waste every second of the time I spent looking at the examples on wicketstuff? I applied these examples to my webapp. Did I implement some type of pretend authorization strategy? http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security +Examples Sources are available here.. https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-s ecurity-examples maybe this is more in the ballpark of what you were expecting? ./C - 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]
Type safe roles for AUTH-ROLES?
I have several successful Wicket projects going, and in all have used my own
authorization strategy based on annotations. I'm just trying
wicket-auth-roles for my next project, but seem confused by the apparent
String-only roles. I already have a domain model where a User has a Role or
Role(s), where Role is a class. This promotes type-safety, etc, etc.
But, I can't go:
@AuthorizeInstantiation({ Role.ADMIN, Role.SUPER_USER,
Role.MEMBER_SERVICE_REP, Role.MEMBER })
I also can't do:
@AuthorizeInstantiation({ Role.ADMIN.name(), Role.SUPER_USER.name (),
Role.MEMBER_SERVICE_REP.name(), Role.MEMBER.name() })
So, do I *have* to use Strings? Or is there another way? If I have to use
Strings, then I either have to redefine all my roles and change how the DB
stores them, or just use the names of my own roles (i.e . SUPER_USER which
later my UserAuthorizer does a Role.valueOf(String) on), and risk typoes
messing me up, or have Role.SUPER_USER and Role.SUPER_USER_NAME as a public
static final String.
It's been a long week - I could be missing something.
Thanks in advance.
Jeremy
Re: Type safe roles for AUTH-ROLES?
wicket-auth-roles is just an example. its not really meant to be
something you drop into your application, for that there is
wicketstuff-wasp and wicketstuff-swarm
-igor
On Jan 12, 2008 9:14 AM, Jeremy Thomerson [EMAIL PROTECTED] wrote:
I have several successful Wicket projects going, and in all have used my own
authorization strategy based on annotations. I'm just trying
wicket-auth-roles for my next project, but seem confused by the apparent
String-only roles. I already have a domain model where a User has a Role or
Role(s), where Role is a class. This promotes type-safety, etc, etc.
But, I can't go:
@AuthorizeInstantiation({ Role.ADMIN, Role.SUPER_USER,
Role.MEMBER_SERVICE_REP, Role.MEMBER })
I also can't do:
@AuthorizeInstantiation({ Role.ADMIN.name(), Role.SUPER_USER.name (),
Role.MEMBER_SERVICE_REP.name(), Role.MEMBER.name() })
So, do I *have* to use Strings? Or is there another way? If I have to use
Strings, then I either have to redefine all my roles and change how the DB
stores them, or just use the names of my own roles (i.e . SUPER_USER which
later my UserAuthorizer does a Role.valueOf(String) on), and risk typoes
messing me up, or have Role.SUPER_USER and Role.SUPER_USER_NAME as a public
static final String.
It's been a long week - I could be missing something.
Thanks in advance.
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
