Normally, wicket wraps HttpSession, which you can't get outside of an HttpRequest. Shiro provides a session you can get from a pojo context. If your code and wicket use the Shiro session, then you can hold the same session both inside and outside the HttpRequest. Shiro will remember your login if you want it to. You can get the session from Shiro and manipulate it as a 'raw' Shiro session any way you need to. Yes.
David -----Original Message----- From: Thomas Heigl [mailto:[email protected]] Sent: Tuesday, November 15, 2011 12:27 PM To: [email protected] Subject: Re: Creating a Wicket Session outside of a Wicket request That looks quite straight forward, but wouldn't I still have the same problem I'm currently facing? The ShiroWebSession is still just a normal wicket session that can't be created from outside the Wicket request. Or are you suggesting to login the subject using "raw" Shiro and then check in the next wicket request if the subject is authenticated and log him in transparently? Thomas On Tue, Nov 15, 2011 at 8:40 PM, David Berkman <[email protected]>wrote: > Don't know. It was easy enough I just rolled my own. > > David > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Tuesday, November 15, 2011 11:36 AM > To: [email protected] > Subject: Re: Creating a Wicket Session outside of a Wicket request > > That's interesting I was trying to do some thing similar n eariler and > just dropped it. Is it possible to use wicket shiro instead? > -----Original Message----- > From: "David Berkman" <[email protected]> > Date: Tue, 15 Nov 2011 11:09:10 > To: <[email protected]> > Reply-To: [email protected] > Subject: RE: Creating a Wicket Session outside of a Wicket request > > You can integrate Shiro with auth-roles very easily. Just create > ShiroAuthenticatedWebSession. > > package com.wicketized.extension.security; > > import java.util.LinkedList; > import org.apache.shiro.SecurityUtils; import > org.apache.shiro.authc.UsernamePasswordToken; > import org.apache.shiro.subject.Subject; import > org.apache.wicket.authroles.authentication.AuthenticatedWebSession; > import > org.apache.wicket.authroles.authorization.strategies.role.Roles; > import org.apache.wicket.request.Request; > > public class ShiroWebSession extends AuthenticatedWebSession { > > private static final Roles NO_ROLES = new Roles(); > > public ShiroWebSession (Request request) { > > super(request); > } > > @Override > public boolean authenticate (String username, String password) { > > Subject currentUser; > > if (!(currentUser = SecurityUtils.getSubject()).isAuthenticated()) > { > > UsernamePasswordToken token = new UsernamePasswordToken(username, > password); > > token.setRememberMe(true); > try { > currentUser.login(token); > } > catch (Exception exception) { > > return false; > } > } > > return true; > } > > @Override > public Roles getRoles () { > > Subject subject; > > if (((subject = SecurityUtils.getSubject()) != null) && > subject.isAuthenticated()) { > > LinkedList<String> codeList; > String[] codes; > > codeList = new LinkedList<String>(); > for (RoleType roleType : RoleType.values()) { > if (subject.hasRole(roleType.getCode())) { > codeList.add(roleType.getCode()); > } > } > > codes = new String[codeList.size()]; > codeList.toArray(codes); > > return new Roles(codes); > } > > return NO_ROLES; > } > > @Override > public void signOut () { > > SecurityUtils.getSubject().logout(); > super.signOut(); > } > } > > -----Original Message----- > From: Thomas Heigl [mailto:[email protected]] > Sent: Tuesday, November 15, 2011 11:06 AM > To: [email protected] > Subject: Re: Creating a Wicket Session outside of a Wicket request > > Hey David, > > Thanks for your reply! I have thought about using Spring Security or > Shire, but at the moment the minimal wicket-auth-roles is enough for > my requirements. I'd prefer to just create the session myself when I > need it. > > Any other ideas? > > Cheers, > > THomas > > On Tue, Nov 15, 2011 at 8:02 PM, David Berkman > <[email protected]>wrote: > > > Apache Shiro, and create a shiro version of WebSession. Then wicket > > can ask for the Shio Session from the Http context, and you can get > > it > > > outside the context. > > > > David > > > > -----Original Message----- > > From: Thomas Heigl [mailto:[email protected]] > > Sent: Tuesday, November 15, 2011 10:57 AM > > To: [email protected] > > Subject: Creating a Wicket Session outside of a Wicket request > > > > Hey all, > > > > I have a requirement where I'd like to create a Wicket Session > > outside > > > of a Wicket request: > > > > My application runs stand-alone (no problem here) and as a Facebook > > application. Facebook calls my REST authentication service with a > > user's credentials if they open my application in facebook. At this > > point I don't have a Wicket session, but want to signin the user in > > my > > > AuthenticatedWebSession from wicket-auth-roles. I'm using the > > WicketSessionFilter in front of my REST service to get access to the > > session, which works fine if the session already exists. If there is > > no session, as in this case, the filter throws an > IllegalArgumentException. > > > > Since I have access to the Wicket Application I thought about > > calling Application.get().newSession(), but this method only accepts > > Wicket's WebRequest and WebResponse objects. Is it somehow possible > > to bind a new session in a non-wicket request? > > > > Kind regards, > > > > Thomas > > > > -------------------------------------------------------------------- > > - 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] > > > --------------------------------------------------------------------- > 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]
