[
https://issues.apache.org/jira/browse/DELTASPIKE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13196833#comment-13196833
]
Gerhard Petracek commented on DELTASPIKE-64:
small addition (if we agree on
review and discuss @Secured
---
Key: DELTASPIKE-64
URL: https://issues.apache.org/jira/browse/DELTASPIKE-64
Project: DeltaSpike
Issue Type: Sub-task
Components: Security-Module
Affects Versions: 0.1
[
https://issues.apache.org/jira/browse/DELTASPIKE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13196852#comment-13196852
]
Shane Bryzak commented on DELTASPIKE-64:
In Seam Security we have a system of
hi @ all,
imo this feature of myfaces codi-core is a nice starting point for the
security-api discussion, because the basic idea behind it is a very thin
integration layer (which can be used by other modules).
the basic concept:
a cdi interceptor invokes (inline) voters to secure the target
Is it up to the developer to define the bean that implements an interface?
On Tue, Jan 31, 2012 at 6:59 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi @ all,
imo this feature of myfaces codi-core is a nice starting point for the
security-api discussion, because the basic idea
that's one option. a 2nd option is to use a deltaspike-security-impl.
module which can provide e.g. an adapter for 3rd party
security-framework. or users just add a possible deltaspike-add-on provided
by an external community e.g. by a security-framework itself.
regards,
gerhard
2012/1/31 John
Hi,
My first objection when I saw the CODI feature the first time, was that it
maybe is too basic: When I have to implement the Voter anyway (or my
security-framework of choice delivers it), why should I use @Secured at all? I
mean, what is the REAL benefit of using @Secured over a custom
Oops, I posted my respone on the JIRA issue - copying to this thread
instead:
In Seam Security we have a system of typesafe security annotations.
Essentially, it's up to the developer to create the annotations required for
the authorization checks in their application. The security binding
in case of myfaces codi it's also used for secured view and it is
integrated with the default-error-view concept (as mentioned in the ticket
we will postpone this part).
furthermore it's used by codi-scopes to avoid a different expiration
behaviour of beans cause by a security check (see the
Hi Shane,
I like that. I guess, it is possible to inject the InjectionPoint into the
@Secures method?
Cheers,
Arne
-Ursprüngliche Nachricht-
Von: Shane Bryzak [mailto:sbry...@redhat.com]
Gesendet: Dienstag, 31. Januar 2012 13:25
An: deltaspike-dev@incubator.apache.org
Cc: Gerhard
Yep, all parameters are injection points so shouldn't be a problem to
inject the InvocationContext or InjectionPoint or whatever other
contextual information we like.
On 31/01/12 22:37, Arne Limburg wrote:
Hi Shane,
I like that. I guess, it is possible to inject the InjectionPoint into the
Gerhard, for explaining this you will probably need to also explain the
TypeSafe Navigation as we have it in CODI [1].By using custom annotations, you
would loose lots of functionality in this area.
I know that this is not the current topic, but discussing security mechanisms
without
Hi Mark,
I don't see, why this could not be done with the Seam Security approach. We can
recognize security annotations via the @SecurityBindingType
Cheers,
Arne
-Ursprüngliche Nachricht-
Von: Mark Struberg [mailto:strub...@yahoo.de]
Gesendet: Dienstag, 31. Januar 2012 14:28
An:
hi mark,
thx for the heads-up. i just talked with shane about all those details.
i don't see an issue with view-configs. codi just extracts the @Secured
annotation during the bootstrapping process in case of view-configs. that
would be the same for such custom annotations meta-annotated with
On 01/02/12 00:21, Gerhard Petracek wrote:
hi mark,
thx for the heads-up. i just talked with shane about all those details.
i don't see an issue with view-configs. codi just extracts the @Secured
annotation during the bootstrapping process in case of view-configs. that
would be the same for
hi shane,
that's one of the reasons why i won't block it right now.
if the majority prefers custom annotations, we should just introduce it
after v0.1 and prototype the missing parts (and test it with the
supported servers).
my vote is +0 right now (for both).
regards,
gerhard
2012/1/31
review and discuss @SecurityBindingType
---
Key: DELTASPIKE-65
URL: https://issues.apache.org/jira/browse/DELTASPIKE-65
Project: DeltaSpike
Issue Type: Sub-task
Components: Security-Module
preparations for v0.1
-
Key: DELTASPIKE-66
URL: https://issues.apache.org/jira/browse/DELTASPIKE-66
Project: DeltaSpike
Issue Type: Task
Components: Core
Reporter: Gerhard Petracek
I personally like the binding approach a little better. It seems to be more
similar to the CDI way of doing interceptors (which, at the end of the day
is essentially what we're doing). However, we have seen a need of doing
@Admin || @User or @Admin @User. The and is fairly easy, but the or is
Seems like a good time for us to kick the tires on @Exclude.
On Tue, Jan 31, 2012 at 07:30, Gerhard Petracek
gerhard.petra...@gmail.comwrote:
hi rudy,
thx! imo it's the right time to restart this discussion.
mark prefers to use @Typed() for custom project-stages (@mark please
correct me if
hi jason,
since it's just a technical issue it doesn't look that nice if we suggest
to annotate custom project-stages with @Exclude
(basically you are right - it would work - but it doesn't look that nice
imo)
regards,
gerhard
2012/1/31 Jason Porter lightguard...@gmail.com
Seems like a good
Looks like I responded to the wrong thread as well.
I personally like the binding approach a little better. It seems to be more
similar to the CDI way of doing interceptors (which, at the end of the day
is essentially what we're doing). However, we have seen a need of doing
@Admin || @User or
Okay, just seemed like a good place to start using our own features.
On Tue, Jan 31, 2012 at 14:39, Gerhard Petracek
gerhard.petra...@gmail.comwrote:
hi jason,
since it's just a technical issue it doesn't look that nice if we suggest
to annotate custom project-stages with @Exclude
I would approach the or use case by simply providing another annotation:
@SecurityBindingType
@Retention(RetentionPolicy.**RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface AdminOrUser {
}
public boolean @Secures @AdminOrUser isAdminOrUser() {
return isAdmin() ||
+1 to gerhards approach.
--
Pete Muir
http://in.relation.to/Bloggers/Pete
On 31 Jan 2012, at 14:30, Gerhard Petracek gerhard.petra...@gmail.com wrote:
hi rudy,
thx! imo it's the right time to restart this discussion.
mark prefers to use @Typed() for custom project-stages (@mark please
What about something like this:
public @interface AnyOf {
Class? extends Annotation[] value();
}
Usage:
@AnyOf({User.class, Admin.class})
public void doSomething() {
// something
}
It's not as nice as @AnyOf({@User, @Admin}) but it's valid Java syntax. :)
Christian
@Exclude: But the ExcludeExtension can be deactivated. In doing so, you
could end up with errors on your custom project stage suddenly.
Not transparent to user, I guess.
So we need an Extension then where we can do the veto of the ProjectStages
(and in the future possibly other types of
@christian: that's correct. but the advantage of using custom annotation
arguments can't be used any more.
and that's also one of my concerns - simple cases work (but also simple
cases are more complex than the usage of @Secured) and such advanced
use-cases are restricted.
in some cases it's
28 matches
Mail list logo
