[06:32:41 EST(-0500)] * jayshao (n=jayshao@pool-72-79-105-68.nwrknj.east.verizon.net) has joined ##uportal
[08:06:08 EST(-0500)] * jayshao (n=jayshao@jayshao.oirt.rutgers.edu) has joined ##uportal
[09:42:41 EST(-0500)] * scottbattaglia (n=scottbat@wg-198-hill012.rutgers.edu) has joined ##uportal
[10:10:49 EST(-0500)] * jayshao (n=jayshao@jayshao.oirt.rutgers.edu) has joined ##uportal
[10:31:44 EST(-0500)] <EiNZTEiN> hey guys
[10:31:52 EST(-0500)] <EiNZTEiN> anyone around? 
[10:32:32 EST(-0500)] * awills (n=awills@12.164.136.183) has joined ##uportal
[10:33:27 EST(-0500)] * jayshao (n=jayshao@jayshao.oirt.rutgers.edu) has left ##uportal
[10:33:34 EST(-0500)] * jayshao (n=jayshao@jayshao.oirt.rutgers.edu) has joined ##uportal
[10:45:04 EST(-0500)] * LennardFuller (n=lfuller@12.164.139.7) has joined ##uportal
[10:58:45 EST(-0500)] * colinclark (n=atrcwrk2@142.150.154.101) has joined ##uportal
[11:08:43 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[11:49:01 EST(-0500)] <EricDalquist> oi
[11:49:12 EST(-0500)] <EricDalquist> the login/authentication/securitycontext code makes my head hurt
[11:50:46 EST(-0500)] <awills> mine too
[11:51:30 EST(-0500)] <EricDalquist> scottbattaglia: did you make any progress figuring out the right places in acegi to add hooks to intercept/listen for authentication events?
[11:52:16 EST(-0500)] <awills> but it's basically state-of-the-art for it's era... I hope that's a good way to phrase that sentiment 
[11:54:40 EST(-0500)] <scottbattaglia> EricDalquist: I haven't had a chance...I've been adding some logging stuff to CAS that we need
[11:55:12 EST(-0500)] <EricDalquist> good ... then I don't feel as bad for just now really looking into login/auth/logout
[11:55:14 EST(-0500)] <EricDalquist>
[12:09:19 EST(-0500)] <scottbattaglia> I'm not too concerned about the logout part
[12:10:21 EST(-0500)] <EricDalquist> so I'm thinking we write a IPersonManager that wraps the Acegi user principal object
[12:10:41 EST(-0500)] <EricDalquist> I think ...
[12:10:48 EST(-0500)] <EricDalquist> I'm going to go do some acegi reading
[12:11:50 EST(-0500)] <scottbattaglia> the thing is we need acegi to execute all of the logic that was previously executed
[12:11:57 EST(-0500)] <scottbattaglia> so I'm not sure wrapping the object is sufficient
[12:12:00 EST(-0500)] <EricDalquist> well there isn't much there
[12:12:22 EST(-0500)] <scottbattaglia> what about the attributes retrieval?
[12:12:30 EST(-0500)] <EricDalquist> remote user security context just grabs the remote user, creates an IPerson and runs the authenticate code
[12:13:01 EST(-0500)] <EricDalquist> and the Login servlet really just invalidates the session and runs you through the process again (talking the remote_user based auth here)
[12:13:12 EST(-0500)] <scottbattaglia> so are we not moving the attribute look up stuff into Acegi?
[12:13:18 EST(-0500)] <EricDalquist> that could probably be rolled into the person manager
[12:13:38 EST(-0500)] <EricDalquist> the attribute stuff can be shifted around as needed
[12:13:50 EST(-0500)] <scottbattaglia> oh okay
[12:14:05 EST(-0500)] <scottbattaglia> so we're mostly just going to delete a lot of code then
[12:14:07 EST(-0500)] <EricDalquist> I'm more concerned about figuring out how we do the guest vs authd IPersons & switch between them (login/logout)
[12:14:40 EST(-0500)] <scottbattaglia> well acegi handles all of the authentication
[12:14:54 EST(-0500)] <EricDalquist> yeah
[12:14:56 EST(-0500)] <scottbattaglia> we'll just need to make sure we only retrieve the IPerson from wherever acegi stores it
[12:15:06 EST(-0500)] <scottbattaglia> and not store it anywhere else
[12:15:06 EST(-0500)] <EricDalquist> and they have an anonymous user object right?
[12:15:10 EST(-0500)] <scottbattaglia> yeah
[12:15:43 EST(-0500)] <EricDalquist> but we can't just use the acegi object, we have to wrap it with a IPerson
[12:16:03 EST(-0500)] <EricDalquist> so how do we know to change the wrapper when the user logs in or out?
[12:16:12 EST(-0500)] <EricDalquist> brb grabbing print out
[12:16:25 EST(-0500)] <scottbattaglia> uhm well our wrapper could just delegate to the SecureContextHolder
[12:16:28 EST(-0500)] <scottbattaglia> and then we don't worry about it
[12:16:48 EST(-0500)] <scottbattaglia> since the SecureContextHolder will always contain the correct principal
[12:17:09 EST(-0500)] <EiNZTEiN> guys, got uportal working
[12:17:11 EST(-0500)] * SusanBramhall (i=Susan@dhcp128036196212.central.yale.edu) has joined ##uportal
[12:17:11 EST(-0500)] <EiNZTEiN> everything was fine after that DB detail you helped with yesterday
[12:17:18 EST(-0500)] <EiNZTEiN> the trick was... do a reboot :/
[12:17:19 EST(-0500)] <scottbattaglia> so even if someone holds on to the wrapper it will always reference the correct object
[12:18:35 EST(-0500)] <EricDalquist> so you're saying the wrapper is updated at the start of each request with the acegi user object?
[12:18:56 EST(-0500)] <EricDalquist> I suppose the person manager could do that since you're supposed to access the IPerson through it
[12:19:17 EST(-0500)] <scottbattaglia> I'm saying the wrapper doesn't even need to be updated since internally it just uses the SecureContextHolder
[12:19:23 EST(-0500)] <scottbattaglia> so even if a stale wrapper is lying around
[12:19:29 EST(-0500)] <scottbattaglia> it can only point to the SecureContextHolder
[12:19:46 EST(-0500)] <scottbattaglia> I don't trust people not to cache it somewhere
[12:19:58 EST(-0500)] <scottbattaglia> I'd have to look at the IPerson interface again to make sure that makes sense
[12:20:41 EST(-0500)] <EricDalquist> ok .... that should work
[12:20:52 EST(-0500)] <EricDalquist> though we'll have to look into it a bit more
[12:20:59 EST(-0500)] <EricDalquist> since we use a thread pool for rendering
[12:20:59 EST(-0500)] <scottbattaglia> the only problem would be that we have no guarantees when the attributes would be set
[12:21:28 EST(-0500)] <EricDalquist> hrm
[12:21:43 EST(-0500)] <EricDalquist> well our IPerson impl could always be provided a reference to the root IPersonAttributeDao
[12:21:56 EST(-0500)] <EricDalquist> and it can just call directly to that
[12:22:07 EST(-0500)] <scottbattaglia> that can get expensive if there is no caching?
[12:22:11 EST(-0500)] <EricDalquist> yup
[12:22:13 EST(-0500)] <scottbattaglia> or are attributes not really looked up that often
[12:22:23 EST(-0500)] <EricDalquist> no it could get expensive if there is no caching
[12:22:34 EST(-0500)] <EricDalquist> and it could be a behavior change
[12:23:07 EST(-0500)] <scottbattaglia> we could do some internal trickery to compare the last Acegi user to the current one in the ThreadLocal
[12:23:13 EST(-0500)] <EricDalquist> since attributes could then change in the middle of the session
[12:23:20 EST(-0500)] <EricDalquist> yeah ....
[12:23:35 EST(-0500)] <EricDalquist> so what about this approach instead
[12:23:54 EST(-0500)] <EricDalquist> we create an IPerson that wraps a SecurityContext
[12:24:06 EST(-0500)] <EricDalquist> the code looks similar to the current RemoteUserPersonManager
[12:24:20 EST(-0500)] <EricDalquist> in that if one of these wrappers doesn't exist it creates/inits one
[12:24:31 EST(-0500)] <EricDalquist> we add a listener for the acegi auth/deauth events
[12:24:59 EST(-0500)] <EricDalquist> and on those events remove the Iperson object, forcing one to be created with the new SecurityContext
[12:25:20 EST(-0500)] <EricDalquist> then we don't have to do weird logic, weird attribute lookup or custom threadlocal management
[12:26:09 EST(-0500)] <scottbattaglia> remove the IPerson object from where?
[12:26:16 EST(-0500)] <EricDalquist> the session
[12:26:23 EST(-0500)] <EricDalquist> that is where it is currently maintained
[12:27:47 EST(-0500)] <scottbattaglia> would the event handler have access to the session
[12:28:02 EST(-0500)] <EricDalquist> hrm
[12:28:03 EST(-0500)] <EricDalquist> not sure
[12:28:10 EST(-0500)] <EricDalquist> brb again
[12:43:07 EST(-0500)] <scottbattaglia> gotta head to the store..be back in a bit
[13:30:11 EST(-0500)] * scottbattaglia (n=scottbat@wg-198-hill012.rutgers.edu) has joined ##uportal
[14:41:13 EST(-0500)] * colinclar1 (n=atrcwrk2@142.150.154.101) has joined ##uportal
[15:39:44 EST(-0500)] <lescour> oh..hey. new email lists
[15:39:48 EST(-0500)] <lescour> when did this happen?
[16:15:45 EST(-0500)] * EiNZTEiN (i=einztein@check.your.ignorelist.com) has left ##uportal
[16:15:50 EST(-0500)] * EiNZTEiN (i=einztein@check.your.ignorelist.com) has joined ##uportal
[16:16:56 EST(-0500)] <EiNZTEiN> im on to develop a new look&feel for our uportal app
[16:16:58 EST(-0500)] <EiNZTEiN> yey
[16:18:08 EST(-0500)] <colinclar1> EiNZTEiN: Cool. What do you have planned?
[16:18:38 EST(-0500)] <EiNZTEiN> I'm still getting familiar with how it's build, but we're making an e-portfolio solution
[16:18:54 EST(-0500)] <EiNZTEiN> so, I'm gonna try and make it as... user-friendly as possible
[16:19:19 EST(-0500)] <EiNZTEiN> the default uportal look is... errr...
[16:19:47 EST(-0500)] <colinclar1>
[16:20:22 EST(-0500)] <colinclar1> What kind of an ePortfolio solution are you working on? Is it all related to the OSP?
[16:26:09 EST(-0500)] <EiNZTEiN> osp?
[17:20:59 EST(-0500)] <jayshao> EiNZTEiN - what version of uPortal are you working with
[17:21:11 EST(-0500)] <EiNZTEiN> 2.6.0
[17:21:20 EST(-0500)] <jayshao> interesting
[17:21:21 EST(-0500)] <EiNZTEiN> I would not design for table-based design 
[17:21:22 EST(-0500)] <EiNZTEiN> hihi
[17:21:24 EST(-0500)] <EiNZTEiN> I'd freak out
[17:21:26 EST(-0500)] <EiNZTEiN> hehee
[17:21:39 EST(-0500)] <jayshao> at the time 2004 the single table was our best compromise
[17:21:50 EST(-0500)] <jayshao> we could have gone all divs, but it didn't degrade nicely
[17:21:57 EST(-0500)] <jayshao> probably worth re-examining now
[17:22:07 EST(-0500)] <jayshao> or are you using the ALM themes?
[17:22:44 EST(-0500)] <jayshao> the xhtml-theme is mostly semantic...
[17:23:53 EST(-0500)] <colinclar1> EiNZTEiN: Sorry, in a meeting. OSP = Open Source Portfolio. http://www.osportfolio.org/
[17:24:13 EST(-0500)] <colinclar1> Table-based designs are evil.
[17:24:32 EST(-0500)] <EiNZTEiN> I don't know yet! Somebody is developing the backend part... I haven't actually seen it yet :S
[17:24:35 EST(-0500)] <jayshao> we told ourselves a table of channels was vaguely semantic
[17:24:48 EST(-0500)] <colinclar1>
[17:24:57 EST(-0500)] <EiNZTEiN> I'm gonna develop some sort of theme for uportal, and the eportfolio channel will use it, kinda think
[17:25:00 EST(-0500)] <EiNZTEiN> thing*
[17:25:18 EST(-0500)] <jayshao> was there something particular about the markup that you didn't like though?
[17:25:35 EST(-0500)] <jayshao> we're just starting to converge on a modern theme, and I'd really like to evolve the out-of-box one if possible
[17:25:44 EST(-0500)] <jayshao> instead of going back to lots of institutional forks
[17:26:48 EST(-0500)] <colinclar1> That makes a lot of sense.
[17:27:29 EST(-0500)] <EiNZTEiN> the out-of-box needs (desperate) work
[17:28:20 EST(-0500)] <EiNZTEiN> I was very turned-off when my colleague told me that we were bound to uportal... I've never heard of it, and the website and 2.5 seemed stalled in time....
[17:29:30 EST(-0500)] <jayshao> the new default in 2.6 needs lots of work?
[17:29:41 EST(-0500)] <jayshao> since the theme/skin is completely different from the 2.5 default
[17:30:29 EST(-0500)] <jayshao> it's derived from the myRutgers presentation and while not perfect isn't table-based except for a single container for channels (no promises about the markup inside the channels)
[17:30:40 EST(-0500)] <jayshao> and is fairly semantic, best-practices XHTML
[17:32:28 EST(-0500)] <jayshao> ...except where it's not... but it shouldn't be that bad...
[17:34:12 EST(-0500)] <colinclar1> 2.6 was a huge and great leap forward.
Page Comparison
General
Content
Integrations