> My rough plan was to create a concrete class implementing
> IAuthorizationStrategy, a SignIn.java and corresponding SignIn.html. Then
> in any application that needed authorization, I'd call
> setAuthorizationStrategy and pass in an instance of my
> SignInAuthorizationStrategy.
>
> The problem is that I *don't* want to have to force all of my applications
> to override getSessionFactory to provide a session for authorization;
> This is both because the applications may want to put something else in
> the session for their own use, and because this wouldn't solve my sign-in
> problem anyway. I'd still end up having to sign in once per application.
>
> The only way I can think to do it is a fairly gross-looking hack to get at
> the HttpSession object and put my authorization-related objects in the
> user's HTTP session diroctly. This strikes me as inelegant, since it
> steps outside the framework to perform tasks inside the framework.
I can't see a much better way to do this though. Imo it's not bad. If
you make a base session class:
public class FooSession extends WebSession {
...
public void setUser(User user) {
httpSession = ...
httpSession.setAttribute(FooSession.class.getName() + "_user", user);
}
etc
As long as you can depend on having the http session available (which
seems ok, get it like
((WebRequestCycle)RequestCycle.get()).getWebRequest().getHttpServletRequest().getSession(true);)
you'll have something that works over multiple applications, while
still providing end-users of your session objects with a clean
interface. Sometimes you just don't get around doing nasty tricks, but
as long as you hide it neatly, imho that's ok.
> It also doesn't look like I can make SignIn its own WebApplication, since
> RestartResponseAtInterceptPageException takes a Page, not an Application.
> And if I call getSession on the SignIn page component, I'm going to get
> the Application's session, which again won't be shared across all
> applications.
If you use the code I gave above, that would work. Alternatively (or
additionally) you could take a look at ISessionStore implementations,
in case you want those applications to share the same concrete session
object. In that case, you'd want to extend AbstractHttpSessionStore
and have an implementation like HttpSessionStore (or
SecondLevelCacheSessionStore) but instead of using
getSessionAttributePrefix everywhere, you would just use the same key.
Btw, the fact that you can do this, doesn't mean this is the greatest
way of doing this :)
> Is there a "right" way to do this in Wicket?
There is hardly ever a 'right' way for Wicket; you can usually solve
your problems in different ways which are not good or bad, but just
depend on your situation and preferences (isn't that nice and vague?)
Eelco
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
