Hi Rama, Andreas' solution is a reasonable solution for coleslaw's problem: coleslaw in this case is acting as a 'framework developer' and not a typical Shiro end-user (i.e. he's developing an integration solution and/or a framework extension).
Subject.Builder is certainly free to be used by anyone that is doing this type of framework work. The JavaDoc warning is in place to let Shiro end-users know that they should be using SecurityUtils.getSubject() whenever possible to acquire the Subject and to only resort to using Subject.Builder if they can't do that (or are providing framework 'behind the scenes' type of stuff). The key to this particular solution is to ensure that the Session IDs transmitted are secure (done over an SSL/SSH/HTTPS connection). Passing raw session IDs around is probably ok only if the transport is secure. There are more secure mechanisms of course, but that should be a basic starting point. HTH, Les Hazlewood CTO, Stormpath | http://www.stormpath.com | 888.391.5282 twitter: @lhazlewood | http://twitter.com/lhazlewood blog: http://leshazlewood.com stormpath blog: http://www.stormpath.com/blog On Mon, Apr 9, 2012 at 10:28 AM, rama.casturi <[email protected]> wrote: > Hi, > > @coleslaw, were you able to figure out how to get this working? I have a > similar situation and have not found a suitable solution yet. From the > javadocs, it looks like Subject.Builder() is NOT recommended to be used by > users of shiro and is intended for internal framework development. If you > have found a good solution, please let me know. > > Thanks > Rama > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Sorta-HTTP-Session-Management-in-HTTP-Session-tp7418918p7450386.html > Sent from the Shiro User mailing list archive at Nabble.com.
