[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.
[17:39:01 EST(-0500)] <jayshao> gtg EiNZTEiN if there's anything we can do to the ootb theme/skin I'd really like to know – I think we're at the point where we can finally start evolving the markup, and in combination with work like FLUID we really need to standardize some of the document structure if possible
[17:39:22 EST(-0500)] <EiNZTEiN>
[17:39:42 EST(-0500)] <EiNZTEiN> I'll be working here, and when I get some solid suggestions/ideas I'll keep y'all posted
[17:40:27 EST(-0500)] <EiNZTEiN> jayshao: when I say it's "stalled in time" I mean design-wise
[17:41:04 EST(-0500)] <jayshao> ah, you mentioned nested tables though which didn't seem to mesh with the xhtml theme
[17:41:23 EST(-0500)] <jayshao> I'm certainly interested in picking up a variety of different presentations and skins
[17:41:30 EST(-0500)] * michelled (n=team@142.150.154.114) has joined ##uportal
[17:41:34 EST(-0500)] <jayshao> I'd like to keep us on a common markup base if possible though
[18:01:18 EST(-0500)] * EiNZTEiN (i=einztein@check.your.ignorelist.com) has joined ##uportal
[18:01:18 EST(-0500)] * colinclar1 (n=atrcwrk2@142.150.154.101) has joined ##uportal
[18:01:18 EST(-0500)] * SusanBramhall (i=Susan@dhcp128036196212.central.yale.edu) has joined ##uportal
[18:01:18 EST(-0500)] * lescour (n=lescour@129.244.24.211) has joined ##uportal
[18:28:52 EST(-0500)] * colinclar1 (n=atrcwrk2@142.150.154.101) has left ##uportal
[19:24:34 EST(-0500)] * colinclark (n=atrcwrk2@bas1-toronto09-1279335567.dsl.bell.ca) has joined ##uportal
[19:24:43 EST(-0500)] * colinclark (n=atrcwrk2@bas1-toronto09-1279335567.dsl.bell.ca) has left ##uportal
Page Comparison
General
Content
Integrations