Hi Al, Yep, Shiro will continue to be supported in standalone applications as well as any other environment we are able to support. :)
When you authenticate a user with the UsernamePasswordToken, the underlying Realm returns a PrincipalCollection that will be used to identify the Subject at runtime. Each realm returns a PrincipalCollection to retain principals it 'knows' about and that the application might use. If multiple Realms are configured, the principals from all realms are aggregated into a 'bundle' PrincipalCollection and that is used. If one realm is configured, that realm's PrincipalCollection is used directly. No matter how many principals across realms there might be, typically you'll have a 'primary' principal that identifies the user across the entire application. Shiro's default heuristic in determining that 'primary' value is just to assume that the first principal returned by the very first Realm is the 'primary' one for the entire application. A simple Realm implementation could have its doGetAuthenticationInfo return the following: new SimplePrincipalCollection(username, password, getName()); If this is the only Realm consulted during authentication, then the following call: subject.getPrincipal(); will return the username (because it is the Realm's PrincipalCollection's first value). When you get that username, you'll have to do a query against your datasource that backs the realm for any additional information for that user keyed off of the username. This is a simple example. Another approach is to have that principal be a user ID instead (for example, a surrogate primary key in a 'users' rdbms table): User user = queryForUser(usernamePasswordToken); return new SimplePrincipalCollection(user.getId(), user.getPassword(), getName()); Now when you call subject.getPrincipal() it will return the value of user.getId(). You might then do this in your application code: User user = userService.getUser((Long)subject.getPrincipal()); which will typically result in a faster query execution due to the primary key lookup. Which approach you choose is entirely up to you - you could store anything you want in the PrincipalCollection (username, userId, first name, last name, etc). Most people almost always use a unique key such as a user id or username and look up other user data based on that key, relying on things like caching to ensure those lookups remain as fast as possible for the application. I hope that helps! Cheers, Les On Tue, Nov 3, 2009 at 1:14 PM, aloleary <[email protected]> wrote: > > Hello, > Just starting to use Shiro in a standlone application and I really like > what I have seen so far. I just have a couple of questions: > > 1) Is the standalone capability going to be supported going forward - I can > see it's documented as very much a developer aid but it fits very well into > standalone single vm/lightweight apps. > > 2) once i have authenticated/logged in... i have a requirement to pull out > the actual username and password for the subject later in the application > (to construct credentials for httpbasic auth requests) > > Is there any 'shiro way' to do this ? > > UsernamePasswordToken token = new > UsernamePasswordToken("root", "secret" > ); > token.setRememberMe(true); > Subject currentUser = SecurityUtils.getSubject(); > currentUser.login(token); > .... > > // somewhere else in code > Subject currentUser = SecurityUtils.getSubject(); > ... ?? how to get users username and password in code ??? > > Currently investigating using Shiro in a Swing & JavaFX application - so far > so good ! > > -A- > > > -- > View this message in context: > http://n2.nabble.com/Standalone-Environment-tp3940226p3940226.html > Sent from the Shiro User mailing list archive at Nabble.com. >
