In my case, I don't even need authorization exceptions. It looks like this:for (Action a :
entity.getActions()) {add(new ActionButton(a));}So for every link/button you have you have a listview and/or panels in wicket?Because you can't just not add a button/link if it is specified in the markup.
Johan Compagner schrieb:
In my case, I don't even need authorization exceptions. It looks like
this:
for (Action a : entity.getActions()) {
add(new ActionButton(a));
}
So for every link/button you have you have a listview and/or panels in
wicket?
Yes.
Because you can't just
I don't think the design I'm currently using is the best for allsituations. Quoting from my previous posting:
| I guess peoples opinions differ because the situations differ. In my| case, the security features of Wicket just add to Wickets complexity,| which is a bad thing. In other cases, it
Igor Vaynberg schrieb:
wicket is not MVC so the design of your application will be different.
I think a lot of people take wicket for a MVC framework, but let's not
have yet another discussion about what MVC is.
Since wicket propagates seperation of concerns (and it has a very good
most of the time you want security over pages or links (rendered/shown or not)It should be easy to integrate a signin page and so on.that should be possible in wicket. And that is what the security interfaces (and an example implemention) is for
just to provide hooks to do those things.Most people
Johan Compagner schrieb:
most of the time you want security over pages or links (rendered/shown or
not)
This can be very elegantly solved with an application model. For
example, a navigation provider should only return navigation items the
user has access to.
As for other links/buttons
Signin is part of the authentication (not authorization), and I concur
that a web framework should provide hooks for it.
Heh :) Don't agree. Authentication should be seen as part of
authorization. Authorization is the end-means of seeing whether action
x is permitted or not. Authentication is
Eelco Hillenius schrieb:
I would like to put it a bit differently. Actually I think wicket is
more MVC than frameworks like struts are because we have the MVC at
the level of components instead of requests.
But to answer your question: yes it is a good idea to have such a
framework, even if you
Eelco Hillenius schrieb:
Signin is part of the authentication (not authorization), and I concur
that a web framework should provide hooks for it.
Heh :) Don't agree. Authentication should be seen as part of
authorization. Authorization is the end-means of seeing whether action
x is permitted
any way you look at it wicket is where requests originate. so wicket is
the first layer of request processing. some people feel comfortable
determining authorization as soon as possible. that means either in
wicket, or in some filter over wicket servlet. why should we limit
those people?
also
unless you are stepping up and
saying that your design is the best for every situation out there
I don't know which one yet, but mine is best! ;)
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?
11 matches
Mail list logo
