Hello Rik,
Questions;
Do you use a normal login form according to Acegi or do you use a
Wicket login form?
We use a signin page that is derived from the example in
wicket-auth-roles-example. So it's a Wicket login form.
Where do you put your authorization settings?
The complete
Hi Erik,
Thanks for your reply.
First I will arrange authentication with Acegi in mine application
and then I will take a good look to the
MetaDataRoleAuthorizationStrategy.
Regards,
Rik
On 12-nov-2006, at 13:47, Erik van Oosten wrote:
Hello Rik,
Questions;
Do you use a normal login
Eelco Hillenius wrote:
But as you got from the answers on this thread, URL based
authorization schemes in not something we recommend for Wicket. It'll
basically bring you back to page-level development again, whereas the
whole point of Wicket is to provide a component based paradigm.
Yeah. There are just multiple problems with URL based authorization.
It works fine for document-oriented sites, but how long ago was it
when we were building those :)
Take for example the use case that you want to hide a panel - but show
the rest of the page - when a user is not authorized for
Hi Rik,
We use Acegi because of its excellent backend features. We do not use
Acegi to do authorization in the frontend, we just give a
username/pasword and ask it for the roles. Acegi gets it out of LDAP for
us, wicket-auth-roles does the authorization. The Acegi filter sets the
Hi Erik,
Yes. So you mean in short: use Acegi for authentication and use
wicket-auth-roles for authorization. That is a good compromise
because you get some of the features of Acegi out-of-the-box, like a
LDAP-server authentication as you mention.
Questions;
Do you use a normal login form
Erik van Oosten wrote:
Wicket supports per component authorisation. You could take a look at
wicket-auth-roles-example (a small project available through svn).
In this project some components (pages) are marked. The mark indicates
which roles are required for the component. As long as
Here is a rough outline. You'll need to study wicket-auth-roles-example
to see how you can integrate this.
You can put the the Wicket servlet behind 2 different url patterns. In
your own session implementation you can access the http session and read
the authenticated user and/or roles as was
you can use package mounting to mount all pages in your admin package to a path, depends on how your classes are stored-igorOn 11/9/06, Dmitry Kandalov
[EMAIL PROTECTED] wrote:Erik van Oosten wrote:
Wicket supports per component authorisation. You could take a look at wicket-auth-roles-example
And if you use 2.0, you can set
getSecuritySettings().setEnforceMounts(true), so that these mounted
pages are only reachable using these paths.
But as you got from the answers on this thread, URL based
authorization schemes in not something we recommend for Wicket. It'll
basically bring you back
I want to define security constraints for tomcat authentication so that one
part of my wicket application would be anonymously available and another
not. So I guess I need different url's. What is the best way to do this?
Should I make two different WebApplication's and map them to different
Wicket supports per component authorisation. You could take a look at
wicket-auth-roles-example (a small project available through svn).
In this project some components (pages) are marked. The mark indicates
which roles are required for the component. As long as the user does not
hit those
On 11/9/06, Erik van Oosten [EMAIL PROTECTED] wrote:
Wicket supports per component authorisation. You could take a look at
wicket-auth-roles-example (a small project available through svn).
You can also download the auth-roles-examples project from sourceforge
for Wicket 1.2(.3). Look under
I search to implements security on my wicket Application.
I plan to use Tomcat 5.X for Authentication, So I search a simple
Authentication page to use it (Email,Password,Role), do you know how to
implement this in Wicket.
If you want to use a login page that is used by the container to
14 matches
Mail list logo