I think it depends on the scenario. In some cases, you want multiple login possibilities (username/password + OpenID), other time you just want one (CMA). We should be flexible enough to support both variations.
Can we do this with properties? D. On Wed, Oct 12, 2011 at 12:17 AM, Vladimir Ivanov <[email protected]> wrote: > At the moment, all auth modules are mapped to specific URL in order to hook > in and create new / retreive existing user to log in into app. Now following > questions come to my mind: > > What path should container auth module be mapped to? *Any* path (_)? Now due > to authentication takes place externally (by container), while it's possible > to check if user is authorized and get username, in general I'm not able to > figure out whether module's logic have to be executed for every specific > request (after user has been redirected to requested path). > > Any ideas? > > Vladimir > > 2011/10/8 Richard Hirsch <[email protected]> > >> >> How would I configure esme to go straight to the >> container-authentication without having to go to " >> http://your_host_port_and_context/cm/login"; . I type in >> "http://your_host_port_and_context"; and am sent automatically to the >> container-based authenication. Assuming that is not Tomcat or >> jetty-based but another site and thus, I don't have to type in >> username/password but use something else, like a token. >> >> Thanks, >> >> D. >> >> >> >> On Sat, Oct 8, 2011 at 3:06 AM, Vladimir Ivanov <[email protected]> >> wrote: >> > Hi guys, >> > >> > List of all possible roles is taken from default property file as a value >> of >> > role_list property. hsr.isUserInRole(_) call checks whether current user >> has >> > role to access this resource. If we talk about container-managed >> > authentication in Java EE web application, then mappings between URLs and >> > roles are specified in web.xml. In turn, mappings between users (groups) >> and >> > roles are container-specific. It might be a property/xml file like >> > jetty-login.properties or tomcat-users.xml (as far as I remember we >> decided >> > not to add these files in repository, but they should have been attached >> to >> > corresponding issue in JIRA) or web container might be configured to use >> an >> > LDAP server. All neccessary configuration steps are described in blog >> entry. >> > >> > So most probably the reason of this problem is that mapping between users >> > and roles is not configured properly. >> > >> > Vladimir >> > >> > >> > 2011/10/5 Richard Hirsch <[email protected]> >> > >> >> Thanks >> >> >> >> D. >> >> >> >> On Wed, Oct 5, 2011 at 10:45 AM, Ethan Jewett <[email protected]> >> wrote: >> >> > Hi Dick, >> >> > >> >> > Maybe change rolesToCheck to something like: >> >> > >> >> > val rolesToCheck = Props.get("role_list") match { >> >> > case Full(s) => { debug("The following roles were found in >> >> > role_list: %s".format(s)) >> >> > s.split(',').toList } >> >> > case _ => { debug("No roles found in role_list.") >> >> > Nil } >> >> > } >> >> > >> >> > No idea if that will actually compile, but it looks more or less >> right. >> >> > >> >> > Cheers, >> >> > Ethan >> >> > >> >> > On Tue, Oct 4, 2011 at 5:28 AM, Richard Hirsch <[email protected] >> > >> >> wrote: >> >> >> Hi, >> >> >> >> >> >> Right now, I'm trying to get container-based authentication to work >> >> >> and I'm having a problem with the roles in UserAuth.scala. I know >> that >> >> >> Vladimir is still on vacation but I thought someone else might be >> able >> >> >> to help me. >> >> >> >> >> >> The code is here: >> >> >> >> >> >> val currentRoles = >> rolesToCheck.filter(hsr.isUserInRole(_)) >> >> >> debug("User from HTTP Request: %s has following >> >> >> roles=%s".format(username, currentRoles)) >> >> >> if(currentRoles.size == 0) { >> >> >> debug("No roles have been found") >> >> >> S.error(S.?("base_user_err_unknown_creds")) >> >> >> >> >> >> The size of currentRoles is always 0 and I'm trying to trace why. >> >> >> >> >> >> How could I debug/trace all the values to rolesToCheck (line 290) ? >> >> >> >> >> >> Thanks >> >> >> >> >> >> D. >> >> >> >> >> > >> >> >> > >> > >> > >> > -- >> > Best Regards, >> > Vladimir Ivanov >> > >> > > > > -- > Best Regards, > Vladimir Ivanov >
