[00:02:16 EDT(-0400)] * andrew_petro_ubu (n=apetro@71-223-119-61.phnx.qwest.net) has joined ##uportal
[00:02:28 EDT(-0400)] <andrew_petro_ubu> kinda lonely in here...
[01:28:42 EDT(-0400)] <andrew_petro_ubu> Any good reason I wouldn't be able to sftp into www.ja-sig.org : Status: Connection established, waiting for welcome message...
[01:28:42 EDT(-0400)] <andrew_petro_ubu> Error: Could not connect to server
[03:07:27 EDT(-0400)] * apetro_win_home (n=andrew_p@ip68-99-92-218.ph.ph.cox.net) has left ##uportal
[03:07:37 EDT(-0400)] * apetro_win_home (n=andrew_p@ip68-99-92-218.ph.ph.cox.net) has joined ##uportal
[09:21:25 EDT(-0400)] * esm (n=esm@asdf.dkc.jhu.edu) has joined ##uportal
[10:15:09 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[10:17:31 EDT(-0400)] <esm> EricDalquist: hey got a sec
[10:17:42 EDT(-0400)] <EricDalquist> sure
[10:18:00 EDT(-0400)] <esm> so... on this ldap thing
[10:18:11 EDT(-0400)] <esm> backing up, I took a look at users in general in up3
[10:18:22 EDT(-0400)] <EricDalquist> ok
[10:19:53 EDT(-0400)] <esm> so there is an acegi authentication provider, used on login, and there is another user controller with "acegi" in the classname used by the portal common context code
[10:20:15 EDT(-0400)] <EricDalquist> sounds like what I remember
[10:20:37 EDT(-0400)] <esm> the acegi authentication provider is totally vanilla, and actually looks at the "user" and "authorities" column of the db.
[10:20:49 EDT(-0400)] <esm> the UserDaoImpl (used by the context code) looks at UP_USER
[10:20:55 EDT(-0400)] <EricDalquist> yeah
[10:21:15 EDT(-0400)] <EricDalquist> so the UserDaoImpl is what ties the acegi generated principal with uP3's concept of a user
[10:21:26 EDT(-0400)] <esm> so i'm wondering the best way to proceed. those divergent approaches need to be merged, right?
[10:21:29 EDT(-0400)] <esm> ok
[10:21:43 EDT(-0400)] <EricDalquist> so you would swap the acegi auth config to go against ldap
[10:21:49 EDT(-0400)] <esm> right
[10:22:00 EDT(-0400)] <esm> no prob there
[10:22:10 EDT(-0400)] <EricDalquist> and then the next step would be to update the UserDaoImpl and perhaps some UserDao client code logic to deal with users that don't actually exist yet
[10:22:23 EDT(-0400)] <EricDalquist> I'm thinking you'll only need to update UserDaoImpl
[10:22:43 EDT(-0400)] <EricDalquist> so that it is smart enough that if a user being asked about doesn't exist it creates the uP3 user object and persists it
[10:23:21 EDT(-0400)] <esm> ok i think i get it
[10:23:56 EDT(-0400)] <EricDalquist> UserDao is really more of a mapping
[10:24:29 EDT(-0400)] <EricDalquist> from acegi generated principal IDs to the internal User object (really represented by the generated key in the table that UserDaoImpl uses)
General
Content
Integrations