[10:53:37 CDT(-0500)] <athena> so for the native mobile app, we're going to have to think through session timeouts
[10:53:51 CDT(-0500)] <EricDalquist> yeah
[10:54:01 CDT(-0500)] <athena> not sure what the app will/should do if you set your phone down for an hour and come back to the mobile view
[10:54:06 CDT(-0500)] <EricDalquist> is a keep-alive ping from the app reasonable?
[10:54:13 CDT(-0500)] <EricDalquist> hrm
[10:54:45 CDT(-0500)] <athena> dunno - worried about the use case where you just leave your phone for a while
[10:54:52 CDT(-0500)] <EricDalquist> yeah
[10:55:09 CDT(-0500)] <EricDalquist> the hard part is every school does authn differently
[10:55:12 CDT(-0500)] <athena> dunno if maybe we need to track how long it's been since you last made a web request? not sure
[10:55:13 CDT(-0500)] <athena> right.
[10:55:19 CDT(-0500)] <athena> and we need to figure out how to handle authn as well
[10:55:26 CDT(-0500)] <EricDalquist> what work has been done so far around the mobile app authn
[10:55:49 CDT(-0500)] <athena> not much
[10:56:02 CDT(-0500)] <athena> you can enter credentials, and then they're stuck into the URL for local auth
[10:56:14 CDT(-0500)] <athena> Login?userName=, etc.
[10:56:18 CDT(-0500)] <EricDalquist> yeah
[10:56:42 CDT(-0500)] <EricDalquist> I think the idle phone solution is going to depend on how we work out authentication
[10:56:48 CDT(-0500)] <EricDalquist> it would be good to list common approaches
[10:56:54 CDT(-0500)] <EricDalquist> local, cas, shib
[10:56:59 CDT(-0500)] <EricDalquist> others that you may know of
[10:57:10 CDT(-0500)] <EricDalquist> and at a minimum list out some solutions for each
[10:58:27 CDT(-0500)] <athena> yeah
[10:58:31 CDT(-0500)] <athena> i think that makes sense
[10:58:48 CDT(-0500)] <athena> we'd figured we'd initially do CAS auth, since that's probably the most common use case
[10:58:52 CDT(-0500)] <EricDalquist> since we need to know what the initial authn plans are before we can try to figure out how re-auth will work
[10:58:55 CDT(-0500)] <EricDalquist> yeah
[10:58:59 CDT(-0500)] <EricDalquist> and that is similar to shib
[10:59:05 CDT(-0500)] <EricDalquist> and other such systems
[10:59:08 CDT(-0500)] <athena> yeah
[10:59:12 CDT(-0500)] <EricDalquist> where the portal can't actually directly auth someone
[10:59:42 CDT(-0500)] <athena> i think we could step through the workflow in the background on the user's behalf if we needed to
[10:59:50 CDT(-0500)] <athena> kind of like the SSO gateway portlet
[11:00:43 CDT(-0500)] <athena> or maybe it would be reasonable to create an alternate authentication pathway from CAS that accepted POST data and returned a JSON success indication? not sure
[11:01:17 CDT(-0500)] <EricDalquist> yeah, that would be neat
[11:01:26 CDT(-0500)] <EricDalquist> but then that makes it hard for anyone who doesn't use CAS
[11:01:29 CDT(-0500)] <athena> wish there was a better way to tell whether a user was logged into uportal
[11:01:30 CDT(-0500)] <athena> yeah
[11:01:38 CDT(-0500)] <athena> we'll have to have a few strategies
[11:01:39 CDT(-0500)] <EricDalquist> what do you mean?
[11:01:48 CDT(-0500)] <EricDalquist> like a "am I currently authed" check?
[11:02:02 CDT(-0500)] <athena> well, i know we have that programmatically
[11:02:18 CDT(-0500)] <athena> but when the mobile app loads a uportal page, it's not obvious if the user is authenticated or not
[11:02:32 CDT(-0500)] <athena> thought about putting a js variable in the page or something like that
[11:02:32 CDT(-0500)] <EricDalquist> well we need that for our dynamic JS apis as well
[11:02:57 CDT(-0500)] <EricDalquist> why not add a /uPortal/api/user REST api
[11:03:06 CDT(-0500)] <EricDalquist> that returns JSON of some current user info
[11:03:17 CDT(-0500)] <athena> yeah, was wondering whether it's be useful to have a service that says whether the user is logged in
[11:03:22 CDT(-0500)] <EricDalquist> then things can call that to check on the status
[11:03:25 CDT(-0500)] <athena> maybe even REST login/logout targets?
[11:03:35 CDT(-0500)] <athena> yeah
[11:03:42 CDT(-0500)] <athena> though that does add more requests
[11:03:52 CDT(-0500)] <athena> i think maybe the mobile app would use it, but don't think the JS APIs would
[11:03:59 CDT(-0500)] <EricDalquist> right
[11:04:11 CDT(-0500)] <EricDalquist> so part of that is finding a general REST API strategy that works
[11:04:34 CDT(-0500)] <EricDalquist> like have a consistent response code & message if the user's session expired
[11:07:33 CDT(-0500)] <athena> yeah
[11:07:46 CDT(-0500)] <athena> we're currently using the unauthorized code, i think
[11:08:37 CDT(-0500)] <athena> so . . . i guess determining whether you need a new session isn't dependent on authentication choice
[11:09:36 CDT(-0500)] <athena> is the session timeout strategy generally just that your session expires after X number of minutes of not interacting with the portal?
[11:12:12 CDT(-0500)] <EricDalquist> yup
[11:12:30 CDT(-0500)] <EricDalquist> every time you make a request to tomcat it resets the X minute timeout on the session
[11:13:13 CDT(-0500)] <athena> so maybe we could do something like track each known request to tomcat
[11:13:24 CDT(-0500)] <athena> which due to ajax would actually be less than the actual requests, but that's ok
[11:13:44 CDT(-0500)] <athena> and if it seems like we're hitting close to the time limit, send a request to the session-checking service
[11:14:00 CDT(-0500)] <EricDalquist> yup
[11:14:05 CDT(-0500)] <athena> if the user is authed, great (and that has the side effect of resetting the session timeout anyway)
[11:14:08 CDT(-0500)] <EricDalquist> which works if the app is actually running in the bg
[11:14:32 CDT(-0500)] <athena> if not, we redo our auth before sending the request through
[11:15:09 CDT(-0500)] <athena> guess we run into problems when the user is in the middle of a portlet, then the session expires and is reset
[11:15:17 CDT(-0500)] <athena> maybe at that point we just give up and reload the portlet
[11:15:45 CDT(-0500)] <EricDalquist> yup
[11:15:53 CDT(-0500)] <EricDalquist> and how to we deal with apache based sso systems
[11:16:10 CDT(-0500)] <EricDalquist> where when the session expires you may not even make it to tomcat
[11:17:07 CDT(-0500)] <athena> err, was that a question? 
[11:17:26 CDT(-0500)] <EricDalquist> just something to think about :/
[11:20:35 CDT(-0500)] <athena> guess i'm not quite sure i'm following
[11:20:40 CDT(-0500)] <athena> why wouldn't you make it to tomcat?
[11:20:49 CDT(-0500)] <EricDalquist> so like we use shib
[11:21:06 CDT(-0500)] <EricDalquist> it has the same 30 minute session timeout for the shib session that tomcat does
[11:21:30 CDT(-0500)] <EricDalquist> when you have been inactive for 31 minutes and make a request to /uPortal you get redirected to the shib authn page
[11:21:48 CDT(-0500)] <EricDalquist> I realize for the umobile stuff to work we would have to modify our authn configs
[11:22:05 CDT(-0500)] <athena> ah.
[11:22:14 CDT(-0500)] <EricDalquist> but we need to make sure the SSO tools that simply provide a REMOTE_USER to uPortal via some external thing are still going to work
[11:22:17 CDT(-0500)] <athena> ok, so really the use case we're thinking of here is more the one where the portal has no guest view
[11:22:27 CDT(-0500)] <EricDalquist> right, we have no guest view
[11:22:29 CDT(-0500)] <athena> yeah
[11:22:34 CDT(-0500)] <athena> i think that's the big difference
[11:22:42 CDT(-0500)] <EricDalquist> we don't have to solve this for every authn tool
[11:22:57 CDT(-0500)] <EricDalquist> but the remote_user + external sso system is pretty common
[11:22:58 CDT(-0500)] <athena> my hope is that most mobile deloyments will have a guest view
[11:23:09 CDT(-0500)] <athena> since using a campus map seems even more attractive if you're just a visitor
[11:23:15 CDT(-0500)] <EricDalquist> yup
[11:23:32 CDT(-0500)] <EricDalquist> even if we did have a guest view though you still get bounced off of the sso server when viewing it
[11:24:09 CDT(-0500)] <athena> hm, sorry, think maybe i still don't quite see the issue
[11:24:43 CDT(-0500)] <EricDalquist> I guess I'm still just hung up on getting the authn side of things figured out for this
[11:24:50 CDT(-0500)] <athena> ah
[11:25:02 CDT(-0500)] <athena> yeah, the authn stuff itself is going to be a whole nother problem 
[11:25:20 CDT(-0500)] <EricDalquist> right but until that gets resolved I don't think we can come up with a meaningful keep-alive solution
[11:25:21 CDT(-0500)] <athena> thinking it might be best to work through the SSO Gateway style
[11:25:30 CDT(-0500)] <athena> since we coudl apply that to another auth framework pretty easily
[11:25:39 CDT(-0500)] <EricDalquist> where the app has to be updated to know how to walk through the specific login webui?
[11:25:45 CDT(-0500)] <athena> yeah
[11:25:54 CDT(-0500)] <athena> that's better than updating the SSO system, maybe
[11:26:06 CDT(-0500)] <EricDalquist> yeah
[11:26:19 CDT(-0500)] <EricDalquist> do you have a list of auth systems the current gateway SSO code works with?
[11:26:42 CDT(-0500)] <athena> well, don't think the actual portlet is relevant - just the overall strategy
[11:26:53 CDT(-0500)] <athena> and that portlet doesn't exactly support specific auth systems
[11:27:06 CDT(-0500)] <athena> just has a way of doing things like loading up a login form in the background, filling it out, etc.
[11:27:12 CDT(-0500)] <athena> i think we can execute javascript in the context of the web page from the mobile app
[11:27:18 CDT(-0500)] <EricDalquist> ok
[11:27:59 CDT(-0500)] <athena> or we might even be able to just make a series of GET/POSTS to walk through the webflow
[11:28:23 CDT(-0500)] <EricDalquist> yeah
[11:28:36 CDT(-0500)] <athena> cas would probably be pretty simple, i think
[11:28:43 CDT(-0500)] <EricDalquist> I just worry a bit after dealing with writing jmeter scripts that walk through the pubcookie and shib login process
[11:28:48 CDT(-0500)] <athena> yeah
[11:28:50 CDT(-0500)] <EricDalquist> they're both fairly involved
[11:28:53 CDT(-0500)] <EricDalquist> and fairly brittle
[11:29:05 CDT(-0500)] <athena> i think session timeouts and authn are both worrisome problems, though separate ones
[11:30:03 CDT(-0500)] <EricDalquist> well only partially
[11:30:07 CDT(-0500)] <EricDalquist> because of where the authn is applied
[11:30:17 CDT(-0500)] <EricDalquist> things like local, ldap and cas auth are all managed within the portal
[11:30:25 CDT(-0500)] <EricDalquist> so we have LOTS of control over how that all works in uporta;
[11:30:40 CDT(-0500)] <EricDalquist> things like Pubcookie and Shibboleth are managed outside of the portal
[11:30:54 CDT(-0500)] <athena> CAS is managed outside the portal too, really, i think?
[11:30:58 CDT(-0500)] <EricDalquist> so session timeout needs to take this into account at some level
[11:31:10 CDT(-0500)] <EricDalquist> do most people use mod_auth_cas with uPortal?
[11:31:20 CDT(-0500)] <EricDalquist> or do they use the CAS security context?
[11:31:25 CDT(-0500)] <athena> security context
[11:31:51 CDT(-0500)] <athena> from the app perspective i don't think it'll matter though
[11:31:58 CDT(-0500)] <EricDalquist> right but from uPortal's perspective it does
[11:32:14 CDT(-0500)] <EricDalquist> you have control in uPortal code what triggers sending the user to the CAS login page and such
[11:32:41 CDT(-0500)] <athena> are you worried about situations where the user could get sent to a login page before the uportal session expired, or something like that?
[11:33:05 CDT(-0500)] <EricDalquist> that the users portal session and sso session expire at the same time
[11:33:15 CDT(-0500)] <EricDalquist> so there is no way to get a "session expired" response
[11:33:22 CDT(-0500)] <EricDalquist> in that case you'd simply get sent to the login page
[11:33:34 CDT(-0500)] <EricDalquist> I don't think this is a huge issue'
[11:33:51 CDT(-0500)] <EricDalquist> just that for non-integrated SSO solutions we don't have the same degree of control
[11:34:13 CDT(-0500)] <athena> gotcha
[11:34:56 CDT(-0500)] <athena> so you're not thinking about the portal page itself - you're talking about accidentally getting a login page instead of JSON data back?
[11:35:02 CDT(-0500)] <athena> for the is-logged-in JSON service?
[11:35:22 CDT(-0500)] <EricDalquist> yup
[11:35:48 CDT(-0500)] <EricDalquist> so I think one think we can do to be careful about this is make sure all our REST URLs are well named
[11:36:04 CDT(-0500)] <EricDalquist> so at the very least the deployer can exclude specific URLs from their SSO check
[11:36:09 CDT(-0500)] <athena> yeah
[11:36:29 CDT(-0500)] <athena> though i guess then we need to make sure that checking that service doesn't count towards the session-poke-tracking
[11:36:50 CDT(-0500)] <athena> since it might be the case that checking the session doesn't actually reset the clock on the SSO side
[11:37:26 CDT(-0500)] <EricDalquist> yeah
[13:01:43 CDT(-0500)] <DrewWills> hey folks... does anyone have any thoughts on possibly splitting the Welcome fragment into 2 tabs in the defaut data set?
[13:02:09 CDT(-0500)] <EricDalquist> I don't have any real preference either way on it
[13:02:22 CDT(-0500)] <DrewWills> i'm trying to wrap up this "Most Added" portlet... seems like the Welcome is the right audience
[13:02:30 CDT(-0500)] <DrewWills> but it's getting crowded
[13:02:52 CDT(-0500)] <EricDalquist> sure, might be a neat example of two tabs in a single fragment as well
[13:03:05 CDT(-0500)] <DrewWills> awesome, thanks
[13:23:37 CDT(-0500)] <athena> i think we probably need to completely redo the layouts before the next release
[13:23:41 CDT(-0500)] <athena> by the way drew
[13:23:50 CDT(-0500)] <athena> sounds like you've been doing awesome stuff with the stats
[13:24:27 CDT(-0500)] <athena> was actually thinking about whether we want that "popular portlets" stuff to appear in the categories in the ajax user interface
[13:24:30 CDT(-0500)] <athena> that'd be pretty neat
[13:25:54 CDT(-0500)] <athena> EricDalquist: i think our session timeout strategy covers most things except a portal restart
[15:36:36 CDT(-0500)] <DrewWills> athena we could do that... there's a rest service that puts out the data in JSON
[15:38:13 CDT(-0500)] <athena> oh cool
[15:38:26 CDT(-0500)] <athena> or might want to think about integrating it into the portlet listing service
[15:38:33 CDT(-0500)] <athena> so it doesn't need two requests
[15:41:03 CDT(-0500)] <DrewWills> that's fine by me
[15:43:54 CDT(-0500)] <athena> well even just as a portlet is a big improvement though
[15:44:00 CDT(-0500)] <athena> i know people have been asking for that for a while
[15:48:25 CDT(-0500)] <DrewWills> awesome
[15:48:44 CDT(-0500)] <DrewWills> does String channelPubId == fname in uP.next?
[15:49:00 CDT(-0500)] <DrewWills> for IAuthorizationPrincipal.canSubscribe()
[15:50:06 CDT(-0500)] <athena> hmm, quite possibly not
[15:50:09 CDT(-0500)] <athena> it may be the numerical id
[15:51:11 CDT(-0500)] <DrewWills> but it's a string
[15:51:17 CDT(-0500)] <DrewWills> just a toString?
[15:52:11 CDT(-0500)] <athena> yeah, i think it's a string representation of the channel id
[15:52:22 CDT(-0500)] <athena> the current best practice for uportal objects is string ids
[15:52:46 CDT(-0500)] <DrewWills> looks like it... in the db
[16:35:09 CDT(-0500)] <athena> EricDalquist: do you have thoughts about how we might implement something for the news reader portlet that fetches feeds in advance?
[16:35:29 CDT(-0500)] <EricDalquist> heh this venerable topic
[16:35:38 CDT(-0500)] <athena> yeah, i know
[16:35:45 CDT(-0500)] <EricDalquist> quartz + ehcache + commons-httpclient
[16:35:48 CDT(-0500)] <athena> just figuring there's a lot more libraries for stuff like this than there used to be
[16:35:50 CDT(-0500)] <athena> ok, that was my guess
[16:36:04 CDT(-0500)] <EricDalquist> make the ehcache's disk-persistent
[16:36:11 CDT(-0500)] <athena> and really probably the only new logic would be the quartz part, i think?
[16:36:15 CDT(-0500)] <EricDalquist> yeah
[16:36:21 CDT(-0500)] <athena> i think the portlet's already using ehcache
[16:36:32 CDT(-0500)] <EricDalquist> and if we embedd this in uPortal we already have a scheduler setup
[16:36:47 CDT(-0500)] <athena> so i think would just be a matter of writing something that could look through all the administratively-configured feeds and make requests
[16:36:49 CDT(-0500)] <athena> hm, interesting.
[16:37:03 CDT(-0500)] <EricDalquist> so this is where time gets spent
[16:37:12 CDT(-0500)] <athena> do you think this should be on the portal side rather than in the portlet itself?
[16:37:12 CDT(-0500)] <EricDalquist> this is a solution that is interesting for more than just RSS feedas
[16:37:16 CDT(-0500)] <athena> yeah, it is
[16:37:27 CDT(-0500)] <EricDalquist> I think the portal is a good place for it
[16:37:33 CDT(-0500)] <EricDalquist> with a little admin ui
[16:37:46 CDT(-0500)] <athena> yeah i guess i just don't want to become a blocker that prevents us from having the feature
[16:37:50 CDT(-0500)] <EricDalquist> that lets you specify: url, refresh time
[16:37:51 CDT(-0500)] <EricDalquist> to start
[16:38:00 CDT(-0500)] <EricDalquist> right :/
[16:38:14 CDT(-0500)] <athena> there's some advantage to having it in the portlet from an administrative standpoint
[16:38:26 CDT(-0500)] <athena> because then you don't have to configure the URL twice
[16:38:33 CDT(-0500)] <EricDalquist> yeah, it just gets crazy from code dupe issues
[16:38:43 CDT(-0500)] <EricDalquist> because features down the road are things like:
[16:39:00 CDT(-0500)] <EricDalquist> what does it do if the remote feed is down? continue using existing data? email admins that the feed is down?
[16:39:13 CDT(-0500)] <EricDalquist> do you add basic content verification with notification
[16:39:23 CDT(-0500)] <EricDalquist> like being able to say "check if feed x is valid XML"
[16:39:32 CDT(-0500)] <EricDalquist> so I guess I have lots of thoughts
[16:39:35 CDT(-0500)] <athena> yeah
[16:39:42 CDT(-0500)] <EricDalquist> really it depends on how much time you have to work on it :/
[16:39:55 CDT(-0500)] <athena> maybe we can do something simple for now to address the immediate need, then move that code over into the portal eventually?
[16:40:01 CDT(-0500)] <EricDalquist> yup
[16:40:06 CDT(-0500)] <EricDalquist> the other thing that the generic portal side service has as a downside is the extra step
[16:40:10 CDT(-0500)] <athena> i can probably do a bit as part of the mobile work, but i don't think realistically i'd be able to address the portal tool
[16:40:11 CDT(-0500)] <athena> yeah
[16:40:34 CDT(-0500)] <athena> it'd be interesting to see how much code this really winds up being - my guess is not a lot
[16:40:51 CDT(-0500)] <EricDalquist> I could see it working like:
[16:40:51 CDT(-0500)] <EricDalquist> 1. go into portal and configure feed URL & refresh period
[16:40:51 CDT(-0500)] <EricDalquist> 2. get special portal-cached-feed-url for the feed
[16:40:51 CDT(-0500)] <EricDalquist> 3. configure portlet using portal-cached-feed-url
[16:40:53 CDT(-0500)] <athena> because the portlet already has logic for parsing and verifying feeds, only caching them if they're valid, etc.
Manage space
Manage content
Integrations