Here's a few thoughts:
1) Instead of all the redirecting around, put the unauthenticated content on
the root page. If the user is authenticated, redirect them to a url such as
/users and make everything below that mount protected. People don't pay much
attention to URLs any more anyway. Don't get too attached to your URLs looking
pretty, but if you must, deal with them at the end by creating mount points.
2) Protecting everything below certain mount points can be done with servlet
filters on path components, but remember that this is not the native
representation of a Page in Wicket. If you forget to make a mount for a page
that should be protected, it can be accessed by someone who knows where to find
it (generally a user that sees the page, then logs out and does something bad
as if they are logged in).
3) Consider creating pages that can act differently, depending on the access
rights of the current user. By using the @AuthorizeInstantiation annotation
(and the appropriate support behind it), you can disable and enable components
declaratively. So your home page can serve both authorized and unauthorized
users. By having components display something grayed out (for instance)
instead of real data, you can "tease" users into becoming paid users.
4) Connect @AuthorizeInstantiation to a standardized security manager such as
Wicket Auth Roles, Shiro, or Spring Security. It's easy enough to implement
IAuthorizationStrategy and do it yourself, but Wicket Auth Roles is very
comprehensive and will open your thought process up to more of what is
possible. Shiro and Spring Security are more powerful still (for instance with
cookie-managed security, integration with data sources such as LDAP, and other
benefits).
Start with a few of these in order, but don't get too lost in trying to do all
of this out of the gate.
On May 30, 2011, at 7:32 PM, Mark Petrovic wrote:
> Hello. I just finished reading Wicket In Action, and now I'm working
> on my first Wicket app. I have a simple question about page
> redirects.
>
> My application's homepage is WelcomePage.java, which I have mounted on
> /welcome. However, if the user has already authenticated and they
> have a session, I would like to immediately send them to HomePage.java
> if they happen to browse to /welcome. HomePage.java is a "protected"
> page that contains stuff only a logged user can see. Whereas
> WelcomePage.java is the unauthenticated user's restricted view of the
> site.
>
> As a first step, I have chosen to implement this redirect in the
> WelcomePage ctor as follows:
>
> public WelcomePage(PageParameters parameters) {
> add(new Label("message", "blah"));
>
> if (AppSession.get().isAuthenticated()) {
> setResponsePage(HomePage.class);
> }
> }
>
> While checking the session for an authenticated user and setting the
> response page to HomePage.class seems to work, I don't know if it
> represents the "Wicket Way". I was thinking there may be a more
> elegant way to affect the redirect, perhaps with one of the Page
> lifecycle methods.
>
> Would someone who has been here be kind enough to comment?
>
> Thank you.
>
>
> --
> Mark
>
> ---------------------------------------------------------------------
> 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]
