uPortal IRC Logs-2012-10-18

[12:47:42 CDT(-0500)] * Naenyn stares blankly at drewwills and athena

[12:48:43 CDT(-0500)] <athena> hey folks

[12:48:57 CDT(-0500)] <athena> so it sounds like there's interest in a conversation about the web proxy portlet?

[12:49:06 CDT(-0500)] <Naenyn> There is!

[12:49:19 CDT(-0500)] <athena> for background, this conversation is about the new version

[12:49:30 CDT(-0500)] <athena> which has some relation to the old version and should eventually have similar features

[12:49:34 CDT(-0500)] <athena> but may have a different architecture

[12:50:01 CDT(-0500)] <athena> to date, there's an IDocumentFilter interface, which allows for filtering of the proxied document - things like clipping, adjusting URLs to be proxied, etc.

[12:50:17 CDT(-0500)] <athena> that filter is specifically designed to adjust content as necessary

[12:50:45 CDT(-0500)] <athena> Naenyn had brought up some use cases that are covered by the previous incarnation of the portlet - specifically adjusting the requested URL to do things like include user attributes

[12:51:25 CDT(-0500)] <athena> my thought is that we probably want a hook into the proxying process - perhaps one that's specific to the HTTP connection use case

[12:51:36 CDT(-0500)] <athena> so that it can adjust URLs, but also potentially insert headers, set basic authentication, etc.

[12:51:51 CDT(-0500)] <drewwills> yes that sounds right

[12:51:52 CDT(-0500)] <EricDalquist> so the old version essentially filtered the portlet preferences

[12:52:03 CDT(-0500)]

[12:52:11 CDT(-0500)] <athena> yeah

[12:52:18 CDT(-0500)] <athena> i think we have a couple pre-request use cases

[12:52:22 CDT(-0500)] <athena> 1. filter the base URL

[12:52:29 CDT(-0500)] <drewwills> yes, i discovered that for SCSU recently

[12:52:58 CDT(-0500)] <athena> 2. add authentication (maybe adding something like a CAS ticket, maybe adding basic auth, maybe doing some form thing)

[12:53:08 CDT(-0500)] <athena> 3. add headers to the request

[12:53:19 CDT(-0500)] <athena> a bunch of these are specific to the first request only, which is perhaps something to think about

[12:53:50 CDT(-0500)] <EricDalquist> basic auth is pretty important

[12:53:54 CDT(-0500)] <athena> yeah

[12:53:55 CDT(-0500)] <EricDalquist> The form auth is neat

[12:54:01 CDT(-0500)] <EricDalquist> but I personally haven't seen it used

[12:54:04 CDT(-0500)] <EricDalquist> not sure if others have

[12:54:07 CDT(-0500)] <athena> ok, that's good to know

[12:54:11 CDT(-0500)] <athena> so maybe we don't need to prioritize that

[12:54:14 CDT(-0500)] <EricDalquist> yeah

[12:54:16 CDT(-0500)] <athena> CAS is used pretty broadly too

[12:54:20 CDT(-0500)] <EricDalquist> I'd say cas/shib proxy

[12:54:22 CDT(-0500)] <athena> though it turns out it's broken in the current impl

[12:54:22 CDT(-0500)] <EricDalquist> and basic

[12:54:26 CDT(-0500)] <EricDalquist> and headers

[12:54:32 CDT(-0500)] <EricDalquist> are all high priority

[12:54:35 CDT(-0500)] <athena> yeah

[12:54:45 CDT(-0500)] <athena> ok, so we need something that can cover all of those use cases

[12:54:56 CDT(-0500)] <drewwills> proxy cas broken in the current impl?

[12:54:58 CDT(-0500)] <athena> yes

[12:55:06 CDT(-0500)] <drewwills> i thought I had that working for SCSU

[12:55:08 CDT(-0500)] <athena> it works on the first request and subsequent proxied links

[12:55:36 CDT(-0500)] <athena> but if you leave the portlet and come back before the session times out, the portlet will re-request the base URL with the CAS proxy ticket it originally used

[12:55:53 CDT(-0500)] <athena> if it's going to go through CAS proxy again, it needs to use a new ticket

[12:55:59 CDT(-0500)] <athena> that just came up with brooklyn this week

[12:56:15 CDT(-0500)] <drewwills> ok, so there's an issue with it

[12:57:04 CDT(-0500)] <Naenyn> drewwills: weren't you also suggesting that the preprocessing be moved to within the scope of the request..?

[12:57:22 CDT(-0500)] <Naenyn> assuming I'm understanding everything you said at my desk earlier =]

[12:58:17 CDT(-0500)] <drewwills> "within the scope?" – when we spoke earlier, i suggested that "interceptors" or "processors" might want to manipulate the request out of httpclient

[12:58:51 CDT(-0500)] <athena> the old version had both a PreInterceptor and PostInterceptor interface, and we might want to at least use those as a starting point

[12:59:54 CDT(-0500)] <drewwills> in this respect I think the earlier portlet wasn't off the mark... we provide an interface that allows concrete implementations to make arbitrary adjustments to the httpclient req after it's constructed, but before it executes

[12:59:55 CDT(-0500)] <athena> we also likely need an interface for providing the HttpClient instance

[13:00:47 CDT(-0500)] <athena> yeah, i think those previous interfaces were pretty close to what we need

[13:01:11 CDT(-0500)] <athena> though the implementation needs to be changed so that we can use httpclient 4, which is signifcantly different

[13:01:16 CDT(-0500)] <athena> so we'l have to see how that affects things

[13:01:30 CDT(-0500)] <Naenyn> Then in that case, I suppose what I wrote is just a temporary fix for my needs until a better implementation can be created..

[13:01:33 CDT(-0500)] <drewwills> but in the new version maybe we provied better out-of-the-box examples and a more intuitive way to configure them

[13:02:36 CDT(-0500)] <athena> Naenyn: i think what you've written so far is a great start

[13:02:57 CDT(-0500)] <athena> yes, it might be temporary, but it's let you get your project working, and it's sparked a good community discussion about what the requirements are for the long-term

[13:03:01 CDT(-0500)] <athena> so i'd count that as success

[13:03:14 CDT(-0500)] <Naenyn> =]

[13:03:14 CDT(-0500)] <athena> and drewwills i think there's certainly agreement that we'd want a more intuitive editing interface

[13:03:33 CDT(-0500)] <drewwills> i'm all for non-permanent, just-good-enough solutions... but i also think it's a good idea to have a longer-term vision and line the preliminary stuff up with it as a "nod" (hints) to those who step in next

[13:03:40 CDT(-0500)] <athena> totally

[13:04:01 CDT(-0500)] <athena> really glad we're talking about this - coop dev can help with this portlet some, so if we can all agree on a roadmap i can help make it happen

[13:04:14 CDT(-0500)] <athena> we'd sort of paused dev until we got some feedback about what the next priorities are

[13:04:21 CDT(-0500)] <drewwills> yeah i'd be delighted to hve this project advance

[13:04:24 CDT(-0500)] <athena> and it sounds like there's plenty of reason to think that auth should be a next priority

[13:04:34 CDT(-0500)] <athena> also i think if we're starting to support auth, we need to support sessions and cookies

[13:04:39 CDT(-0500)] <athena> since otherwise the auth won't be of much use

[13:04:57 CDT(-0500)] <athena> so my inclination is to pull in Naenyn's change, since he's the only production user so far

[13:05:17 CDT(-0500)] <athena> and then take a look through the previous impl and sketch out the next step at expanding his change to something more general

[13:05:20 CDT(-0500)] <Naenyn> from my project's standpoint, we are good to go with the latest changes I wrote, but it could definitely use web-based config util.. not sure where that should be on the priority tho.

[13:05:31 CDT(-0500)] <athena> ok, that's great feedback

[13:05:45 CDT(-0500)] <Naenyn> use a*

[13:05:48 CDT(-0500)] <athena> and maybe we get more people trying it out if there's a decent config tool

[13:05:52 CDT(-0500)] <athena> so we could even do that first

[13:06:01 CDT(-0500)] <athena> also gives us a way to work on a few things in the portlet in parallel

[13:07:11 CDT(-0500)] <Naenyn> thankfully my needs are pretty simple at this point. =]

[13:07:40 CDT(-0500)] <Naenyn> and on a side note.. am I technically a production user? I haven't rolled this out to prod yet...

[13:07:50 CDT(-0500)] <Naenyn> although I suppose I will be shortly.

[13:08:11 CDT(-0500)] <athena> well

[13:08:16 CDT(-0500)] <athena> "a user", even

[13:08:21 CDT(-0500)] <Naenyn> hehe

[13:08:27 CDT(-0500)] <athena> if you participate, you get to influence requirements

[13:08:57 CDT(-0500)] <athena> drewwills and EricDalquist - how does this sound to you guys? any implementation / interface changes you'd recommend from the first version?

[13:11:59 CDT(-0500)] <EricDalquist> sounds good to me

[13:15:49 CDT(-0500)] <drewwills> you mean the pull request?

[13:19:26 CDT(-0500)] <athena> from the first version of the portlet

[13:19:45 CDT(-0500)] <athena> we can certainly start w/ something similar, but good to consider if there are things we already know we want changed

[13:19:51 CDT(-0500)] <athena> if not, i'll just start with something reasonable

[13:19:55 CDT(-0500)] <EricDalquist> oh ... like everything

[13:20:00 CDT(-0500)] <EricDalquist> just start with something reasonable

[13:22:08 CDT(-0500)] <drewwills> (as far as the pull request...) I think it's great... I'm delighted to have new ideas and energy... happy to have it... my small suggestion would be to move the interceptor processing from ProxyPortletController to HttpContentService.getContent(), and make the method sig something like "public String filter(HttpUriRequest httpRequest, RenderRequest portletRequest, RenderResponse portletResponse);"

[13:22:45 CDT(-0500)] <drewwills> and yes, just start with something reasonable

[13:23:32 CDT(-0500)] <drewwills> if he new one is even close to ready, I can start putting energy into it with projects like Manhattan

[13:30:31 CDT(-0500)] <athena> yeah - sounds good

[13:30:40 CDT(-0500)] <athena> i think we'd originally discussed moving that logic into the content service

[13:30:49 CDT(-0500)] <athena> so far i think we can limit this to just the http content service too

[14:05:39 CDT(-0500)] <EricDalquist> oh githubh: Great repository names are short and memorable. Need inspiration? How about freezing-octo-hipster.

[14:15:06 CDT(-0500)] <Naenyn> EricDalquist: Dan McCallum would approve.

[14:15:13 CDT(-0500)] <EricDalquist> lol

[14:33:43 CDT(-0500)] <lfuller>

[16:48:09 CDT(-0500)] <sjungling> hey guys. got a report from our Help Desk that someone signing in to uPortal had no content. did some digging around in the logs and found, what seems like an abnormally high volume of errors for: https://raw.github.com/gist/ac1e21cf0eb10a8a7c20/d81695108051f1b6614bb2af5422e3e71979743d/uPortal.log

[16:48:30 CDT(-0500)] <sjungling> sounds/looks similar to https://issues.jasig.org/browse/UP-3194

[16:49:13 CDT(-0500)] <sjungling> odd part is that I can look-up the user via the User Admin portlet and impersonate those users and I see all the tabs that they should

[17:10:43 CDT(-0500)] <sjungling> unrelated to this, on an 4.0.7 dev instance I'm seeing the following periodically

[17:10:44 CDT(-0500)] <sjungling> ERROR [uPortal-TaskExecutor-1-aggregateRawEvents] internal.BatchingBatch.[] 2012-10-18 15:08:02,311 - HHH000315: Exception executing batch [ORA-00001: unique constraint (UPORTAL4.SYS_C0058421) violated

[17:10:44 CDT(-0500)] <sjungling> ]