uPortal IRC Logs-2009-03-17

Owned by Apereo Infrastructure
Last updated: Mar 17, 2009Version comment
37 min read

[01:51:20 EDT(-0400)] * ChanServ (ChanServ@services.) has joined ##uportal
[01:51:20 EDT(-0400)] * tsnfoo (n=tsnfoo@cpe-65-24-108-125.columbus.res.rr.com) has joined ##uportal
[01:51:20 EDT(-0400)] * jayshao_ (n=jayshao@ool-45731411.dyn.optonline.net) has joined ##uportal
[01:51:20 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[01:51:20 EDT(-0400)] * dstn (n=dstn@unaffiliated/dstn) has joined ##uportal
[02:05:12 EDT(-0400)] * ChanServ (ChanServ@services.) has joined ##uportal
[02:05:12 EDT(-0400)] * tsnfoo (n=tsnfoo@cpe-65-24-108-125.columbus.res.rr.com) has joined ##uportal
[02:05:12 EDT(-0400)] * jayshao_ (n=jayshao@ool-45731411.dyn.optonline.net) has joined ##uportal
[02:05:12 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[02:05:12 EDT(-0400)] * dstn (n=dstn@unaffiliated/dstn) has joined ##uportal
[08:14:06 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[08:45:36 EDT(-0400)] <dstn> so athena, how does jQuery UI function properly after completely reassigning the jquery namespace to up.JQuery?
[08:46:08 EDT(-0400)] <athena> you have to use up.jQuery rather than $
[08:46:11 EDT(-0400)] <athena> so like
[08:46:17 EDT(-0400)] <athena> up.jQuery(document).ready
[08:46:36 EDT(-0400)] <athena> although you can always reassign it back to $ or whatever else you like within a closure
[08:46:58 EDT(-0400)] <dstn> but I'm talking like in the jQuery UI code itself
[08:47:03 EDT(-0400)] <dstn> doesn't it use $?
[08:47:04 EDT(-0400)] <athena> you might want to take a look at my presentation notes - there are a few examples of the resource server stuff in there
[08:47:23 EDT(-0400)] <dstn> ya, I read them
[08:47:35 EDT(-0400)] <athena> i sucks in the jQuery variable and assigns it to $ with in the closures, i believe
[08:47:56 EDT(-0400)] <athena> but regardless of that, the jquery ui code has already been evaluated before you call jQuery.noConflict
[08:48:15 EDT(-0400)] <dstn> ahhhhh, yes
[09:02:49 EDT(-0400)] * anastasiac (n=stasia@142.150.154.189) has joined ##uportal
[09:33:56 EDT(-0400)] * tsnfoo (n=tsnfoo@wso-mbp15.test.denison.edu) has joined ##uportal
[09:37:05 EDT(-0400)] <dstn> so many dollar signs
[09:38:19 EDT(-0400)] * jessm (n=Jess@c-71-232-3-4.hsd1.ma.comcast.net) has joined ##uportal
[09:45:34 EDT(-0400)] <athena> dstn: if only you got a dollar for each one of those $s? (smile)
[09:48:54 EDT(-0400)] <dstn> oh ya, that'd be nice
[09:56:28 EDT(-0400)] <athena> (smile)
[10:05:18 EDT(-0400)] <athena> i hate this daylight savings time thing
[10:05:33 EDT(-0400)] <athena> everyone i need to talk to is asleep!
[10:05:40 EDT(-0400)] <athena> morning agherna
[10:05:46 EDT(-0400)] <agherna> hello
[10:06:35 EDT(-0400)] <agherna> dstn, i have a patch cut for the WeatherPortlet but I haven't written a JIRA ticket for it yet.
[10:06:41 EDT(-0400)] * athena cheers
[10:06:52 EDT(-0400)] <agherna> will do soon though
[10:07:15 EDT(-0400)] <agherna> i deployed it to 1 of our instances this morning in prod (I have a high degree of confidence it works)
[10:08:37 EDT(-0400)] <agherna> is there a way to get in touch w/ the Accuweather folks to let them know that their feed should be corrected?
[10:09:00 EDT(-0400)] <athena> i think they've been pretty receptive to communication in the past?
[10:10:38 EDT(-0400)] <dstn> agherna, great! look forward to the JIRA issue and patch, thanks for your help
[10:11:03 EDT(-0400)] <agherna> NP. We love the WeatherPortlet (smile)
[10:11:03 EDT(-0400)] <dstn> agherna, I can give you the guy to contact at AccuWeather, let me find his name
[10:11:10 EDT(-0400)] <agherna> ok
[10:11:26 EDT(-0400)] <agherna> i'm putting together the feed to show him
[10:12:05 EDT(-0400)] <dstn> his name is Michael Sylvie, you can contact him at developer-at-accuweather.com
[10:12:33 EDT(-0400)] <dstn> mention the uport feed
[10:13:00 EDT(-0400)] <agherna> will do
[10:14:39 EDT(-0400)] <agherna> thanks for that info
[10:16:19 EDT(-0400)] <dstn> np, thanks for your help
[10:25:18 EDT(-0400)] <agherna> dstn, one question: is there a data dictionary somewhere for the accuweather feed?
[10:27:07 EDT(-0400)] <dstn> one sec, let me look at my email
[10:27:42 EDT(-0400)] <dstn> shoot, I no longer have the email
[10:27:59 EDT(-0400)] <agherna> Hmmm
[10:28:00 EDT(-0400)] <agherna> ok
[10:28:01 EDT(-0400)] <dstn> I'm not positive but I recall that Michael sent me one or pointed me to a link in the past
[10:28:19 EDT(-0400)] <dstn> I'm sure he'd have no problem giving it to you if you asked
[10:28:25 EDT(-0400)] <agherna> ok
[10:29:16 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined ##uportal
[10:29:29 EDT(-0400)] <agherna> i'm framing my note as a question: "Is there a specification for date/time formats that are sent by the feed?".
[10:30:00 EDT(-0400)] <agherna> it's possible that the data could have been entered incorrectly one day by somebody
[10:30:15 EDT(-0400)] <agherna> that's the trouble with consuming downstream content (as most of our portal does)
[10:30:52 EDT(-0400)] <athena> yeah
[10:31:23 EDT(-0400)] <athena> i've sort of been wondering if we should make some recommendations for issues like that
[10:31:25 EDT(-0400)] <athena> and for security
[10:31:48 EDT(-0400)] <athena> it does help that a lot of our current content is produced by the JSTL c:out tag, which XML-escapes content by default
[10:32:07 EDT(-0400)] <athena> but as we move into more and more javascript, i worry that we'll be more vulnerable to script injection issues
[10:32:38 EDT(-0400)] <athena> even w/ the c:out tag, if you're printing out something that goes into a js string, need to make sure to escape apostrophes and such
[10:36:58 EDT(-0400)] <agherna> Here's a decent (not the best) podcast that talks about such attacks: http://se-radio.net/podcast/2009-03/episode-128-web-app-security-bruce-sams
[10:37:24 EDT(-0400)] <agherna> the way we've been dealing with it thus far is through policy
[10:38:03 EDT(-0400)] <agherna> we have so far only consumed content from "trusted sources" (campus partners or public resources that have a lot of credibility like CNN, ESPN, etc.)
[10:38:18 EDT(-0400)] <athena> yeah, i think that's how most people are probably handling stuff too
[10:38:31 EDT(-0400)] <agherna> also, just making sure we don't echo stuff back to the screen that the user enters
[10:38:42 EDT(-0400)] <athena> right
[10:38:44 EDT(-0400)] <agherna> unless we've "cleansed" it
[10:39:13 EDT(-0400)] <agherna> but its not enough to just assume someone else will handle the same way
[10:39:18 EDT(-0400)] <agherna> because they won't
[10:39:21 EDT(-0400)] <athena> yeah, sort of wondering if we want to have to add some sort of standard utility for "cleansing" things to the ajax portlet utils package
[10:39:29 EDT(-0400)] <agherna> it's a hard thing to put into place though
[10:39:43 EDT(-0400)] <agherna> should be optional
[10:40:00 EDT(-0400)] <agherna> maybe you have an application that relies on it (a trusted campus application for example)
[10:40:34 EDT(-0400)] <athena> yeah
[10:40:35 EDT(-0400)] <athena> anthony colebourne did some nice work with the news reader portlet using antisamy
[10:40:50 EDT(-0400)] <athena> you can set up XML files declaring a policy for incoming content like RSS feeds
[10:41:02 EDT(-0400)] <athena> and it'll potentially strip out images, script tags, etc.
[10:41:25 EDT(-0400)] <athena> but you can have different policy files - so you could have one for your trusted content, and one for other content
[10:41:33 EDT(-0400)] <athena> i kind of liked the approach
[10:45:38 EDT(-0400)] <agherna> OK, sent a note to the accuweather folks.
[10:48:05 EDT(-0400)] <dstn> agherna, great, let me know how that goes!
[10:48:17 EDT(-0400)] <agherna> I will
[10:49:24 EDT(-0400)] * invisibill (i=80876350@gateway/web/ajax/mibbit.com/x-6ef3774617f50893) has joined ##uportal
[10:57:08 EDT(-0400)] <invisibill> Greetings uPortal devs: I'm attemption to use the jasig weather portlet: http://www.ja-sig.org/wiki/display/PLT/Weather+Portlet. I've tried both the xstream and dom4j parsers but keep coming up with this exception: "Caused by: java.lang.RuntimeException: Unable to parse sunset value"
[10:57:51 EDT(-0400)] <invisibill> does anyone know if the data is bad?
[11:00:14 EDT(-0400)] <athena> how topical!
[11:00:27 EDT(-0400)] <invisibill> I've got the portlet configured to read Chicago IL and area code. 60504
[11:00:35 EDT(-0400)] <athena> invisibill, i believe dstn and agherna have been working on that this morning, in fact
[11:00:44 EDT(-0400)] <invisibill> cool.
[11:01:05 EDT(-0400)] <athena> from what i overheard, i think it's potentially bad data coming back from accuweather, but i'll let one of them fill you in on the details if they're around
[11:02:30 EDT(-0400)] <invisibill> ok. np. I'm going to try to get the announcement portlet up in running this morning also. http://www.ja-sig.org/wiki/display/PLT/Announcements+Portlet I'll stay online and call back here to report back issues.
[11:02:36 EDT(-0400)] <invisibill> thanks for the info.
[11:04:25 EDT(-0400)] <athena> hope it goes well!
[11:06:49 EDT(-0400)] <agherna> http://www.ja-sig.org/issues/browse/WPT-22
[11:07:08 EDT(-0400)] <agherna> invisibill, we've been having problems with Chicago data too. how coincidental
[11:07:46 EDT(-0400)] <agherna> The link i just sent has an illustration of the problem and a fix attached to it.
[11:08:03 EDT(-0400)] <agherna> now, if dstn will review it and commit it (smile) (smile)
[11:08:08 EDT(-0400)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:09:40 EDT(-0400)] <agherna> but definitely it's a problem that could happen to anybody's feed.
[11:19:51 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[11:24:06 EDT(-0400)] <dstn> athena, as the author of the Resource Server ... I was hoping you had an opinion as to it's use vs the use of a static server (i.e. an apache server).
[11:24:24 EDT(-0400)] <athena> hang on a moment - on the phone (smile)
[11:24:29 EDT(-0400)] <dstn> np
[11:24:44 EDT(-0400)] <dstn> agherna, I'll try to get to your patch sometime today or tonight
[11:25:01 EDT(-0400)] <agherna> great, thank you
[11:25:01 EDT(-0400)] <invisibill> ok. thanks. so I just need to apply the patch to our weather portlet and rebuild?
[11:25:11 EDT(-0400)] <agherna> it worked for us, yes
[11:25:23 EDT(-0400)] <agherna> this patch addresses the xstream object only
[11:25:32 EDT(-0400)] <agherna> i did not look at the dom4j version
[11:25:50 EDT(-0400)] <agherna> although depending on how that one works it may need something similar done to it as well
[11:26:32 EDT(-0400)] <invisibill> I don't have a requirement for either but the error message was the same.
[11:28:45 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:29:39 EDT(-0400)] <invisibill> agherna how do I apply the patch?
[11:32:23 EDT(-0400)] <invisibill> patch WeatherConverter.java WeatherConverter_WPT-22_1.patch
[11:33:09 EDT(-0400)] <agherna> invisibill: from the root of your WeatherPortlet source: patch -p4 < ~/Documents/portal/WeatherPortlet/WeatherConverter_WPT-22_1.patch
[11:33:42 EDT(-0400)] <invisibill> ok thanks.
[11:35:43 EDT(-0400)] <agherna> invisibill, actually you don't need the ~/Documents/portal/WeatherPortlet (that's just where the patch file is on my machine--sorry about that) (tongue)
[11:38:57 EDT(-0400)] <agherna> and it looks like WeatherUtil in the dom4j version could use a similar fix as well (after looking at it, see getForecast())
[11:45:07 EDT(-0400)] <athena> so dstn: if you want to use an apache server to do this stuff, i think that's a totally reasonable option
[11:45:23 EDT(-0400)] <athena> we wanted a solution we could bundle and have automatically configured
[11:45:35 EDT(-0400)] <athena> but if you have a local static server and prefer that, that's a completely reasonable alternative
[11:54:17 EDT(-0400)] <dstn> athena, sorry, I was talking to someone
[11:54:49 EDT(-0400)] <dstn> totally understand why it was developed and agree it makes sense
[11:55:40 EDT(-0400)] <invisibill> thanks agherna and athena the patch worked and we have the weather portlet running now.
[11:55:56 EDT(-0400)] <dstn> I think we are going to use our static server for various reasons, thanks for your input
[11:56:05 EDT(-0400)] <agherna> invisibill, that's great news!
[11:56:21 EDT(-0400)] <invisibill> we are using the default xstream parser
[11:56:51 EDT(-0400)] <agherna> so are we, but I'm getting together a patch for the dom4j version as well since it has the same problem
[11:58:14 EDT(-0400)] <invisibill> ok
[12:00:48 EDT(-0400)] <agherna> patch is up on the ticket: http://www.ja-sig.org/issues/browse/WPT-22
[12:03:53 EDT(-0400)] <agherna> the patch for dom4j that is
[12:04:59 EDT(-0400)] <invisibill> ok. I patched the dom4j version as well to keep in synch.
[12:09:49 EDT(-0400)] <invisibill> Hi agherna: I have a request. can the .classpath, .project, .settings/ eclipse file be removed from the source tree so that it doesn't bump into our local configurations? That way, we can stay in full synch with whats released and not have port the changes to our local copy.
[12:10:44 EDT(-0400)] <agherna> invisibill, i can't remove that file (don't have commit access to the project).
[12:11:50 EDT(-0400)] <invisibill> ok. I'll try emailing Dustin Schultz
[12:15:05 EDT(-0400)] <agherna> he's on the channel @dstn
[12:16:13 EDT(-0400)] <invisibill> oh ok. It is mostly just a convenience for us to make merging into our local copies easier.
[12:19:44 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[12:28:24 EDT(-0400)] <agherna> There was a great blog some months ago debating whether or not project metadata (e.g. .classpath files and nbproject/ directories) should be versioned
[12:28:29 EDT(-0400)] <agherna> there are pros and cons to both
[12:29:32 EDT(-0400)] <agherna> http://www.lousycoder.com/blog/index.php?/archives/105-Arguments-against-checking-in-your-.project-and-.classpath-files.html if you're interested in reading this
[12:29:45 EDT(-0400)] <agherna> it's a very cogent argument against version such things
[12:30:08 EDT(-0400)] <agherna> and I agree with it, but we here don't follow it :\
[12:31:14 EDT(-0400)] <EricDalquist> so right now none of the eclipse config files contain any absolute path info and should work for anyone using eclipse (as long as they have the maven plugin which they would need even if the files were not there)
[12:31:33 EDT(-0400)] <EricDalquist> If uPortal developers want to use other IDEs and check in those project files I have no problem with that
[12:32:02 EDT(-0400)] <EricDalquist> with any of them the idea would be that the ones in the repo may not be 100% up to date
[12:33:18 EDT(-0400)] <EricDalquist> though I'd hope that since we use maven the other IDEs would be like eclipse and the .classpath and .project files would be essentially static
[12:37:45 EDT(-0400)] <invisibill> yeah. its not really a big issue or anything. We are also making use of the Announcements portlet which doesn't include those files.
[12:41:01 EDT(-0400)] <awills> fwiw I agree w/ argherna: http://uportal.pastebin.com/d2e81730f
[12:41:25 EDT(-0400)] <awills> i always get M .project and M .classpath
[12:41:35 EDT(-0400)] <awills> and whenever they change, i have to fix them
[12:42:11 EDT(-0400)] <EricDalquist> if it is an annoyance call a vote about it on uportal-dev
[12:42:59 EDT(-0400)] <awills> it's nicer if somehow we all agree (smile)
[12:43:17 EDT(-0400)] <EricDalquist> how about we all agree on whatever the vote outcome is (smile)
[12:44:45 EDT(-0400)] <awills> also, if we were to take the view that each person gets 1 vote for every commit in the last 12 mo, you'd have all the votes
[12:45:01 EDT(-0400)] <awills> i really don't want to screw you up, b/c you do so much more than me
[12:45:28 EDT(-0400)] <holdorph> i dont understand why your last pastebin, so much of the file is considered a diff
[12:45:33 EDT(-0400)] <holdorph> the lines aren't different
[12:45:39 EDT(-0400)] <EricDalquist> different tab indent
[12:45:52 EDT(-0400)] <EricDalquist> but that isn't how it works
[12:45:53 EDT(-0400)] <awills> i don't understand that bit either, unless it's tabs (yeah)
[12:45:53 EDT(-0400)] <holdorph> that would be a whole different problem then
[12:46:05 EDT(-0400)] <awills> or line endings
[12:46:09 EDT(-0400)] <EricDalquist> we have very much tried to adopt the apache model for voting
[12:46:16 EDT(-0400)] <EricDalquist> so every commiter gets 1 binding vote
[12:46:27 EDT(-0400)] <EricDalquist> non-commiters can vote but they are non binding
[12:47:23 EDT(-0400)] <holdorph> drew do you have a subversion config file setup?
[12:48:07 EDT(-0400)] <awills> approx commits 3/2008 - 3/2009: edalquist 314, awills 35
[12:48:24 EDT(-0400)] <awills> i believe i do
[12:49:01 EDT(-0400)] <awills> there's a wiki page on that, correct
[12:49:03 EDT(-0400)] <awills> ?
[12:49:10 EDT(-0400)] <holdorph> i think so
[12:49:22 EDT(-0400)] <holdorph> just trying to see if that might have been a reason for the problem
[12:49:40 EDT(-0400)] <holdorph> it's likely there is a reason of some kind.
[12:49:44 EDT(-0400)] <awills> the substantive difference in the .project file is the project name
[12:51:50 EDT(-0400)] * holdorph goes back to his sakai work, before he gets too far behind on that.
[13:00:28 EDT(-0400)] <awills> not sure if this makes a difference in this case... the build.xml file has the "svn:eol-style" property set to "native", but the .project and .classpath files don't have that property set at all
[13:02:46 EDT(-0400)] <awills> same for my local working set and in the SVN repo
[13:28:35 EDT(-0400)] <holdorph> could be that someone created those files without the subversion config set up.
[13:29:10 EDT(-0400)] <holdorph> i don't think the subversion config changes existing files, it only affects new 'svn add'ed files.
[13:29:20 EDT(-0400)] <EricDalquist> that was probably me
[13:29:39 EDT(-0400)] <EricDalquist> a 3.2 task should probably be to do a little find script to set the svn attributes correctly
[13:29:48 EDT(-0400)] <EricDalquist> then ask everyone to use a standard config file
[13:42:13 EDT(-0400)] <athena> subversion config only applies if you've chosen to use one
[13:42:36 EDT(-0400)] <athena> i periodically go through the repo and fix eol styles when it breaks my vendor imports
[13:42:49 EDT(-0400)] <athena> but it'd be great if we could set some standards, have a svn commit hook, etc.
[13:44:32 EDT(-0400)] <EricDalquist> well we'd loose the commit hook when we moved to jira studio
[13:44:37 EDT(-0400)] <athena> ah
[13:44:56 EDT(-0400)] <athena> i did add the config file that i used to confluence about a year ago
[13:45:07 EDT(-0400)] <athena> i do'tn know if we want to make any official recommendations about such things or not
[13:45:32 EDT(-0400)] <EricDalquist> we probably should
[13:45:44 EDT(-0400)] <EricDalquist> way down on my todo list is developer standards for uPortal
[13:51:27 EDT(-0400)] <athena> that'd be cool
[14:29:01 EDT(-0400)] <dstn> athena, I'm having a bit of trouble getting the tabbed search portlet jquery ui tabs to work
[14:29:08 EDT(-0400)] <dstn> it looks like this http://i40.tinypic.com/292yc5e.jpg
[14:29:23 EDT(-0400)] <athena> css issue
[14:29:49 EDT(-0400)] <athena> are you including the the jquery 1.6 theme?
[14:29:53 EDT(-0400)] <dstn> ya, I got that much but I am not sure I understand the css in uportal
[14:29:55 EDT(-0400)] <athena> i don't know what yale's skin is like these days
[14:29:58 EDT(-0400)] <athena> ah
[14:30:16 EDT(-0400)] <athena> i had to make a couple edits to the default jquery css to make it all play nicely
[14:30:48 EDT(-0400)] <athena> some of the reset templates we use mess with the list styles
[14:32:30 EDT(-0400)] <athena> so you could take a look at the differences between the one in svn and the default jquery one
[14:36:11 EDT(-0400)] <dstn> this is using the uportal default skin (whatever that's called)
[14:36:23 EDT(-0400)] <dstn> ok, thanks for the pointers, I'll look there
[14:36:25 EDT(-0400)] <athena> hm
[14:36:29 EDT(-0400)] <athena> ok, that's not right then
[14:36:40 EDT(-0400)] <athena> what does the code look like?
[14:38:30 EDT(-0400)] <dstn> ok, maybe this is a stupid question, but do I need to include the jquery 1.6 theme? I thought that was covered by the fluid uportal 3 theme?
[14:38:40 EDT(-0400)] <dstn> one sec, let me pastebin
[14:40:18 EDT(-0400)] * apetro (n=apetro@ip68-3-207-51.ph.ph.cox.net) has joined ##uportal
[14:40:25 EDT(-0400)] * dstn says yay, I solved it
[14:40:32 EDT(-0400)] <dstn> tried one last thing and it work
[14:40:35 EDT(-0400)] <dstn> worked*(
[14:40:51 EDT(-0400)]

<dstn> changed $("#$

Unknown macro: {n}

searchPortletTabs > ul").tabs(); to $("#$

searchPortletTabs").tabs();


[14:44:07 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[14:51:30 EDT(-0400)] <athena> ok, i was about to suggest that
[14:51:34 EDT(-0400)] <athena> sorry i'm only half here
[14:55:10 EDT(-0400)] <dstn> np
[15:26:14 EDT(-0400)] <dstn> for long rendering pages is there a google solution to eliminate FOUC {color}
[15:26:21 EDT(-0400)] <athena> fouc?
[15:26:31 EDT(-0400)] <dstn> FOUC (Flash of Unstyled Content)
[15:30:51 EDT(-0400)] <athena> ah
[15:31:03 EDT(-0400)] <athena> i don't know if google has anything specifically for that
[15:31:20 EDT(-0400)] <athena> in the past we've pre-styled elements w/ jquery css classes to prevent some of that
[15:32:06 EDT(-0400)] <athena> it should also be possible to call $(element).ready rather than $(document).ready so that components don't have to wait until there very end of the page load to be rendered
[15:32:19 EDT(-0400)] <athena> which won't fix what you're seeing, but is sort of related
[15:32:38 EDT(-0400)] <athena> which thing are you seeing issues w/? i think i've noticed it more w/ jquery than google
[15:32:51 EDT(-0400)] <athena> seems like some of google's stuff just doesn't load until everything is available
[16:11:11 EDT(-0400)] <dstn> athena, I'm experiencing the whole tabbed search portlet being unstyled until the page fully loads
[16:11:23 EDT(-0400)] <athena> ah ok
[16:11:24 EDT(-0400)] <athena> yeah
[16:11:42 EDT(-0400)] <athena> might want to see if applying some styles ahead of time fixes that
[16:11:51 EDT(-0400)] <athena> that's what we'd done in the past
[16:12:01 EDT(-0400)] <dstn> ok
[16:14:36 EDT(-0400)] <athena> EricDalquist: any more thoughts about uportal registration?
[16:17:17 EDT(-0400)] <EricDalquist> yeah ... just a minute
[16:18:24 EDT(-0400)] <EricDalquist> well just 10-20 minutes
[16:18:27 EDT(-0400)] <EricDalquist> back in a few ....
[16:18:44 EDT(-0400)] <athena> sure (smile)
[16:19:20 EDT(-0400)] * apetro (n=apetro@ip68-3-207-51.ph.ph.cox.net) has joined ##uportal
[16:28:34 EDT(-0400)] <dstn> svn down?
[16:28:49 EDT(-0400)] <dstn> nm...worked after a refresh
[16:39:06 EDT(-0400)] <EricDalquist> so athena I guess I've been thinking about that issue as a bigger picture
[16:39:20 EDT(-0400)] <EricDalquist> I'd really really love to have the opt-in automated data gathering
[16:39:36 EDT(-0400)] <athena> yeah that would be fantastic
[16:40:21 EDT(-0400)] <EricDalquist> but the more I think about it there are some big issues there that we need to discus on the dev list a lot before going forward with it
[16:40:45 EDT(-0400)] <EricDalquist> so for 3.1 I think the best we can do and be responsible about it is an updated portlet to just submit some basic data
[16:41:04 EDT(-0400)] <EricDalquist> so the user clicks a button and we somehow track some information
[16:41:23 EDT(-0400)] <EricDalquist> on the steering committee call sending an email was brought up as a possibility
[16:41:40 EDT(-0400)] <EricDalquist> but I'm concerned that it wouldn't make it ... so much spam and SMTP filtering now
[16:41:53 EDT(-0400)] <EricDalquist> so we probably need a little webapp on www.ja-sig.org listening for these
[16:45:19 EDT(-0400)] <EricDalquist> I've started:
[16:45:19 EDT(-0400)] <EricDalquist> http://www.ja-sig.org/wiki/display/UPC/Automated+Portal+Registration
[16:45:25 EDT(-0400)] <EricDalquist> so we can coordinate a little bit
[16:48:47 EDT(-0400)] <athena> sounds great
[16:48:59 EDT(-0400)] <athena> are we going to try an do something for 3.1 or hold off for the next release?
[16:49:12 EDT(-0400)] <EricDalquist> already putting that on the page
[16:49:21 EDT(-0400)] <EricDalquist> but I'm thinking for 3.1 we add a framework portlet
[16:49:32 EDT(-0400)] <EricDalquist> that lets the user register the instance
[16:49:49 EDT(-0400)] <EricDalquist> and POSTS to some yet to be written service on www.ja-sig.org to collect the data
[16:49:53 EDT(-0400)] <EricDalquist> no automated anything
[16:50:00 EDT(-0400)] <EricDalquist> and just put that on the default admin layout
[16:50:30 EDT(-0400)] <athena> gotcha
[16:51:39 EDT(-0400)] <EricDalquist> the UI could have a few inputs for institution name, deployer name, contact email/phone
[16:52:01 EDT(-0400)] <EricDalquist> and then some checkboxes for what to submit
[16:52:09 EDT(-0400)] <EricDalquist> perhaps a view to show what exactly would get sent back
[16:53:34 EDT(-0400)] <athena> sounds cool
[16:54:07 EDT(-0400)] <EricDalquist> think that is doable by Friday?
[16:54:20 EDT(-0400)] <EricDalquist> I'm also thinking we need to generate a GUID during initportal
[16:54:34 EDT(-0400)] <EricDalquist> so we can track duplicate submissions
[16:55:10 EDT(-0400)] <athena> yes, i think potentially so
[16:55:12 EDT(-0400)] <athena> hm, about the GUID
[16:55:33 EDT(-0400)] <athena> i assume that would change when the portal was rebuilt?
[16:55:50 EDT(-0400)] <EricDalquist> not sure
[16:55:59 EDT(-0400)] <EricDalquist> I need to go read up on GUID generation
[16:56:36 EDT(-0400)] <awills> I've just been reading up on the hibernate query cache...
[16:57:31 EDT(-0400)] <awills> I guess I had fed myself bad information... I had thought hibernate would detect changes to the tables and evict the queries automatically
[16:57:49 EDT(-0400)] <awills> it doesn't seem to be working that way (sad)
[16:57:59 EDT(-0400)] <EricDalquist> it will if you make the changes through the active hibernate instance
[16:58:07 EDT(-0400)] <EricDalquist> external changes are not detected
[16:58:22 EDT(-0400)] <awills> on another portal server? or in another JVM?
[16:58:25 EDT(-0400)] <EricDalquist> unless hibernate is using a clustered cache
[16:59:00 EDT(-0400)] <EricDalquist> if you enable clustered cache eviction notifications in ehcache it should work
[16:59:09 EDT(-0400)] <EricDalquist> I believe JHU did that
[16:59:22 EDT(-0400)] <awills> how would you do it?
[16:59:32 EDT(-0400)] <dstn> athena, have you found a good way to reference a namespaced jQuery reference in an external file if you are using the portlet namespace?
[16:59:42 EDT(-0400)] <awills> multicast?
[16:59:55 EDT(-0400)] <athena> i don't think you should have to, dstn
[17:00:00 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[17:00:08 EDT(-0400)] <EricDalquist> http://ehcache.sourceforge.net/documentation/distributed_caching.html
[17:00:14 EDT(-0400)] <EricDalquist> (darn pidgin crashed)
[17:00:24 EDT(-0400)] <EricDalquist> we're looking at it too, not a high priority
[17:00:26 EDT(-0400)] <athena> take a look at the ajax preferences js file
[17:00:27 EDT(-0400)] <dstn> athena, why not? what if you want to use jQuery in the external file? is there something I'm missing?
[17:00:40 EDT(-0400)] <EricDalquist> our plan is to get a multicast IP setup for each clustered environment
[17:00:40 EDT(-0400)] <awills> so it is the multicast option?
[17:00:58 EDT(-0400)] <awills> is this approach safe to turn on in uP by default?
[17:01:02 EDT(-0400)] <EricDalquist> then broadcast remove notifications (not all uPortal objects are serializable so you can't broadcast put or update)
[17:01:11 EDT(-0400)] <EricDalquist> well update counts as remove in the remove-only mode
[17:01:31 EDT(-0400)] <dstn> athena, using the (function($) { })(jQuery) way...is that what you are referring too?
[17:01:35 EDT(-0400)] <athena> yeah
[17:01:39 EDT(-0400)] <athena> exactly
[17:02:06 EDT(-0400)] <awills> eric is this something we can configure in ehcache.xml by default?
[17:02:15 EDT(-0400)] <EricDalquist> no
[17:02:22 EDT(-0400)] <athena> i'm assuming that should be imported in before your jQuery.noConflict call anyway, yes?
[17:02:29 EDT(-0400)] <EricDalquist> you either have to know a specific multicast IP provided by your network admins
[17:02:29 EDT(-0400)] <dstn> athena, hmmm...I tried that and none of my functions were available
[17:02:30 EDT(-0400)] <EricDalquist> or
[17:02:38 EDT(-0400)] <EricDalquist> know the IPs of all other servers in the cluster
[17:02:39 EDT(-0400)] <EricDalquist> http://ehcache.sourceforge.net/documentation/configuration.html
[17:02:51 EDT(-0400)] <dstn> athena, I'd call them explicitly and I'd get undefined
[17:02:51 EDT(-0400)] <awills> that's what i feared... i think it might be simpler to turn off caching for this query: SELECT x FROM FragmentDefinition x ORDER BY x.precedence DESC
[17:03:07 EDT(-0400)] <EricDalquist> why?
[17:03:15 EDT(-0400)] <EricDalquist> we should just better document the distrubted caching
[17:03:18 EDT(-0400)] <athena> do you have the javascript to look at?
[17:03:33 EDT(-0400)] <EricDalquist> lots of other parts of the portal will break too if you expect direct database changes to appear on servers
[17:03:40 EDT(-0400)] <EricDalquist> groups, permissions, channels, portlet preferences
[17:03:41 EDT(-0400)] <dstn> athena, let me revert the file and pastebin it
[17:03:44 EDT(-0400)] <EricDalquist> all cached in ehcache
[17:03:48 EDT(-0400)] <awills> b/c you can't add fragments to a running portal if that cache is enabled, not unless you do it in the same JVM
[17:03:52 EDT(-0400)] <athena> sure dstn, i'll take a look when you have it up
[17:03:57 EDT(-0400)] <EricDalquist> right
[17:04:05 EDT(-0400)] <EricDalquist> that is a problem we have to deal with in the import/export scripts
[17:04:23 EDT(-0400)] <EricDalquist> the command line tools can't really ever get around that
[17:04:38 EDT(-0400)] <EricDalquist> well perhaps with the clustered options
[17:04:39 EDT(-0400)] <awills> but the imp/exp scripts are good citizens in this case... using the JPA DAO appropriately
[17:04:46 EDT(-0400)] <EricDalquist> yes
[17:05:06 EDT(-0400)] <EricDalquist> so if you have clustering setup and the machine you're running the import from can be part of the cluster you're fine
[17:05:14 EDT(-0400)] <EricDalquist> or if you use the import portlet
[17:05:17 EDT(-0400)] <EricDalquist> then you're in the same JVM
[17:05:31 EDT(-0400)] <awills> what's the impact of taking that query out of cache? I suspect it's very small – there's still the 2nd-level cache
[17:05:45 EDT(-0400)] <EricDalquist> the second level cache isn't used if the query cache is off
[17:05:50 EDT(-0400)] <dstn> athena, http://uportal.pastebin.com/m4446a7c0
[17:05:55 EDT(-0400)] <EricDalquist> at least that is my understanding
[17:06:08 EDT(-0400)] <awills> didn't look that way in the docs, but i'm new to this
[17:06:16 EDT(-0400)] <EricDalquist> the query cache is the more important one for us anyways
[17:06:23 EDT(-0400)] <athena> hm - dstn, does that script actually load up w/o errors?
[17:06:27 EDT(-0400)] <EricDalquist> creating new data objects isn't that expensive
[17:06:37 EDT(-0400)] <EricDalquist> running the SQL is very expensive in comparison
[17:06:37 EDT(-0400)] <athena> looks to me like missing equals signs in things like "var useGsaSuggestion function(suggestion, namespace)"
[17:06:43 EDT(-0400)] <EricDalquist> that's external IO
[17:06:59 EDT(-0400)] <dstn> athena, opps, pasted a version with an error
[17:07:08 EDT(-0400)] <awills> how high does the # of fragments have to get to make it expensive? or is that not really a factor
[17:07:12 EDT(-0400)] <athena> having the html as well would be helpful
[17:07:28 EDT(-0400)] <EricDalquist> it isn't the number of fragments. it is the frequency of the calls
[17:07:42 EDT(-0400)] <EricDalquist> so how often is the DAO called upon to get that data
[17:07:57 EDT(-0400)] <awills> can we set a timeout for query cache?
[17:07:59 EDT(-0400)] <athena> ok dstn: beyond all the above, your functions aren't going to be visible because they're functions within a closure
[17:08:04 EDT(-0400)] <awills> 5 min or somesuch
[17:08:04 EDT(-0400)] <athena> er, variables, i meant
[17:08:13 EDT(-0400)] <athena> so you can't see them outside of there
[17:08:24 EDT(-0400)] <dstn> right...that's what I was mentioning earlier
[17:08:26 EDT(-0400)] <EricDalquist> <cache name="org.hibernate.cache.StandardQueryCache"
[17:08:26 EDT(-0400)] <EricDalquist> eternal="false" maxElementsInMemory="250" overflowToDisk="false" diskPersistent="false"
[17:08:26 EDT(-0400)] <EricDalquist> timeToIdleSeconds="0" timeToLiveSeconds="300" memoryStoreEvictionPolicy="LRU" />
[17:08:37 EDT(-0400)] <EricDalquist> it defaults to 5 minutes
[17:08:43 EDT(-0400)] <athena> if you look at ajax-preferences-jquery.js, the only visible function is the one of the format "$.uportal.UportalLayoutManager = function(callerSettings) {"
[17:08:58 EDT(-0400)] <awills> so it already works that way?
[17:09:09 EDT(-0400)] <athena> all the ones that say "var something = function" aren't visible
[17:09:32 EDT(-0400)] * dstn is looking at ajax-preferences again
[17:09:51 EDT(-0400)] <athena> ajax-preferences, incidentally, is not a good example of best practices (smile)
[17:09:53 EDT(-0400)] <athena> but it does work
[17:10:03 EDT(-0400)] <EricDalquist> yeah
[17:10:10 EDT(-0400)] <athena> in an ideal world, we'd refactor things as a more contained, configurable component
[17:10:11 EDT(-0400)] <EricDalquist> and dlm evaluator has a 300 second cache too
[17:10:25 EDT(-0400)] <EricDalquist> so worst case should be about a 5 minute wait
[17:10:28 EDT(-0400)] <awills> if the query will refresh in 5 min than this is not an issue at all, i think
[17:10:40 EDT(-0400)] <awills> yeah that's cool... no worries
[17:10:51 EDT(-0400)] <EricDalquist> great
[17:11:10 EDT(-0400)] <EricDalquist> In general if the cache timeouts are ever an issue I'd rather educate users on the realities of caching and configuration
[17:11:31 EDT(-0400)] <awills> i do have to get a small patch in to ensure that new frags are activated, though... i have that all set
[17:11:34 EDT(-0400)] <EricDalquist> I think JHU posted in the manual with an example of setting up clustering
[17:11:39 EDT(-0400)] <EricDalquist> ok
[17:11:44 EDT(-0400)] <EricDalquist> that should go in as soon as possible
[17:12:09 EDT(-0400)] <awills> np. in minutes
[17:12:40 EDT(-0400)] <awills> btw i like what's been done in the .dlm package for config and such
[17:12:44 EDT(-0400)] <athena> EricDalquist: i should be updating the google portlet tonight
[17:12:59 EDT(-0400)] <EricDalquist> ah yeah I meant to ask you about that
[17:13:17 EDT(-0400)] <EricDalquist> so we need to make sure docs are updated to point to the spring config for the loader type instead of dlm.xml
[17:13:21 EDT(-0400)] <EricDalquist> athena: wonderful
[17:13:33 EDT(-0400)] <awills> yeah it looks great, e.g RDBMConfigurationLoader extends LegacyConfigurationLoader
[17:14:29 EDT(-0400)] <EricDalquist> yeah, it removed quite a bit of code by rearranging those and creating an interface to define the base functionality of ConfigurationLoader
[17:16:00 EDT(-0400)] <awills> i think that package will benefit from some non-trivial reshaping... i'm glad we broke the ice (wink)
[17:16:12 EDT(-0400)] <EricDalquist> yeah
[17:16:32 EDT(-0400)] <EricDalquist> on the bus a few days ago I was doing some redesign sketching of layout manager code in uPortal
[17:16:43 EDT(-0400)] <EricDalquist> I need to put it up on the wiki and start some conversation about that
[17:16:51 EDT(-0400)] <EricDalquist> since that is a big project that needs some serious insight
[17:17:17 EDT(-0400)] <athena> that would be fantastic
[17:17:18 EDT(-0400)] <EricDalquist> but I think I have some ideas that would greatly simplify the code that goes into the layout dao and managers
[17:17:24 EDT(-0400)] * athena is a fan of this thought
[17:17:32 EDT(-0400)] <EricDalquist> and potentially add much more flexibility to dlm fragments
[17:17:46 EDT(-0400)] <EricDalquist> athena: did you get a chance to look at that wiki page about the portlet?
[17:17:50 EDT(-0400)] <athena> what kind of flexibility do you have in mind?
[17:18:14 EDT(-0400)] <athena> no, finishing up something
[17:18:17 EDT(-0400)] <athena> should be done soon though
[17:19:11 EDT(-0400)] <EricDalquist> so my initial thought (this comes from the sandbox portal work) is that we simplify the database a bit and the XML stored is just tree structured data with node IDs
[17:19:36 EDT(-0400)] <EricDalquist> node ids are unique for at least that user forever (node ids will never be recycled on a per-user basis) same contract we have now
[17:19:57 EDT(-0400)] <EricDalquist> loading a layout is a more pipelined operation with things that look similar to the current DLM param processor
[17:20:38 EDT(-0400)] <EricDalquist> like adding chanid to channel layout nodes would be done by a processor that looks up the appropriate channel info based on some table it maintains behind a DAO of user+nodeid->chanid
[17:20:50 EDT(-0400)] <EricDalquist> that's for PLFs
[17:21:05 EDT(-0400)] <EricDalquist> then fragments are merged in from things that aren't overloaded layouts
[17:21:13 EDT(-0400)] <EricDalquist> we actually have some sort of fragment XML format
[17:21:21 EDT(-0400)] <athena> sounds cool
[17:21:30 EDT(-0400)] <EricDalquist> the hard part with all of that is it comes back around to the problem of editing fragments
[17:21:31 EDT(-0400)] <athena> i'd really love to have pull-based fragments
[17:21:35 EDT(-0400)] <athena> yeah
[17:21:45 EDT(-0400)] <EricDalquist> and the nice thing about overloaded layouts as fragments is they are easy to reuse existing tools to edit
[17:21:49 EDT(-0400)] <athena> yeah
[17:21:55 EDT(-0400)] <athena> though we're missing a bunch of pieces right now
[17:22:04 EDT(-0400)] <EricDalquist> but I'm thinking we could have a marker attribute as to where the fragment starts
[17:22:41 EDT(-0400)] <EricDalquist> not sure how all that would look
[17:22:44 EDT(-0400)] <EricDalquist> so yeah
[17:22:51 EDT(-0400)] <EricDalquist> I just need to start writing this down more
[17:23:07 EDT(-0400)] <EricDalquist> and get some more input on all of it
[17:23:44 EDT(-0400)] <EricDalquist> like I think in theory the DLM fragments + PLF merge logic could be encapsulated in a XSL
[17:24:04 EDT(-0400)] <EricDalquist> which may simplify things, it could be easier to do that merge logic in an XSL versus java code
[17:24:17 EDT(-0400)] <EricDalquist> again these are all just random ideas
[17:24:22 EDT(-0400)] <EricDalquist> that need to become more coherent
[17:24:46 EDT(-0400)] <EricDalquist> but the general idea goes along with the pipeline approach we had in the sandbox
[17:25:43 EDT(-0400)] <athena> (smile)
[17:25:44 EDT(-0400)] <athena> cool
[17:25:54 EDT(-0400)] <athena> just taking a look now at the reporting channel page
[17:26:07 EDT(-0400)] <EricDalquist> db -> plf dom -> plf node & attr sources -> frags + plf -> merged layout node & attr sources -> structure transform -> struct node & attr sources -> theme transform -> output to user
[17:26:19 EDT(-0400)] <EricDalquist> that was very close to what the sandbox portal did
[17:26:35 EDT(-0400)] <EricDalquist> just minus the frags + plf step
[17:26:51 EDT(-0400)] <EricDalquist> the idea is you have some nice base classes to just add attributes to nodes
[17:27:13 EDT(-0400)] <athena> cool (smile)
[17:27:18 EDT(-0400)] <EricDalquist> but if you want it isn't a big leap to stick a full blown SAX filter in at any point to manipulate the structure if you want
[17:27:26 EDT(-0400)] <EricDalquist> there was also intelligent caching logic
[17:27:39 EDT(-0400)] <athena> oh nice
[17:27:42 EDT(-0400)] <EricDalquist> where the pipeline would build a big compostite cache key
[17:28:03 EDT(-0400)] <EricDalquist> and on render it would start at the output end and work its way back checking the cache validity
[17:28:22 EDT(-0400)] <EricDalquist> so each step could say yes/no as to if state related to that step changed
[17:28:36 EDT(-0400)] <athena> excellent
[17:28:56 EDT(-0400)] <EricDalquist> so a change to a structure attribute via some other process could trigger everything from that point forward to re-run
[17:29:11 EDT(-0400)] <athena> that makes sense
[17:29:15 EDT(-0400)] <EricDalquist> yeah
[17:29:20 EDT(-0400)] <athena> so about this portlet - i think the data collected is good, but i think we may want some additional info
[17:29:27 EDT(-0400)] <EricDalquist> sounds good
[17:29:38 EDT(-0400)] <EricDalquist> what are you thinking?
[17:29:41 EDT(-0400)] <athena> i could see someday maybe want to build a visual representation of the data - say a map or something, or re-do the deployers list
[17:29:58 EDT(-0400)] <athena> the deployers list currently has the name of the instance "YaleInfo", "myRutgers", etc.
[17:30:07 EDT(-0400)] <athena> and a link to the instance itself
[17:30:25 EDT(-0400)] <athena> so we may want that data at some point
[17:30:40 EDT(-0400)] <athena> the other thing we may want is some geographical data to generate a map from
[17:30:52 EDT(-0400)] <athena> of course, an IP address is probably close enough for those purposes
[17:30:56 EDT(-0400)] <EricDalquist> sure
[17:31:06 EDT(-0400)] * jessm (n=Jess@c-71-232-3-4.hsd1.ma.comcast.net) has joined ##uportal
[17:31:09 EDT(-0400)] <athena> so those are the things i'd probably add, off the top of my head
[17:31:20 EDT(-0400)] <EricDalquist> think you would be comfortable putting together a little portlet view with the data you're thinking of?
[17:31:24 EDT(-0400)] <athena> sure
[17:31:40 EDT(-0400)] <EricDalquist> even just a little html doc attached to that wiki page would be great
[17:31:50 EDT(-0400)] <athena> perhaps a toggle for whether it's ok to include the instance publicly in the deployers list?
[17:31:56 EDT(-0400)] <athena> ok
[17:32:35 EDT(-0400)] <EricDalquist> yeah
[17:32:52 EDT(-0400)] <EricDalquist> I'm thinking this is going to be a few fields and a bunch of checkboxes
[17:33:33 EDT(-0400)] <athena> yeah
[17:33:43 EDT(-0400)] <athena> so just "permission to send and we'll figure it out ourselves"
[17:35:26 EDT(-0400)] <EricDalquist> yup
[17:37:17 EDT(-0400)] <awills> done eric, btw
[17:38:06 EDT(-0400)] <EricDalquist> great, thanks awills
[17:38:20 EDT(-0400)] <awills> of course (smile)
[17:39:25 EDT(-0400)] <athena> we really need some uportal marketing wizards
[17:39:39 EDT(-0400)] <athena> i'd really love to be able to have someone write up friendly, inviting copy for this thing
[17:40:06 EDT(-0400)] <EricDalquist> well if you can get a UI up we can see what sort of eyes we can get on it in the next few days
[17:40:21 EDT(-0400)] <athena> yeah
[17:47:12 EDT(-0400)] <athena> should have something for you soon eric
[17:47:21 EDT(-0400)] <athena> do you want me to commit it somewhere? email it?
[17:47:40 EDT(-0400)] <EricDalquist> attach it to that page
[17:47:46 EDT(-0400)] <athena> sure
[17:47:49 EDT(-0400)] <EricDalquist> I've just done a bunch more updates there
[17:49:29 EDT(-0400)] <athena> awesome
[17:50:27 EDT(-0400)] <EricDalquist> feel free to edit that page with any ideas/insight you have
[17:51:38 EDT(-0400)] * tsnfoo_ (n=tsnfoo@cpe-65-24-108-125.columbus.res.rr.com) has joined ##uportal
[17:52:16 EDT(-0400)] <athena> sure
[17:52:45 EDT(-0400)] <athena> building a JSP page since i assume that's what we'll wind up wanting - sound good?
[17:52:51 EDT(-0400)] <EricDalquist> yup
[18:13:39 EDT(-0400)] * athena writes in labels and attempts to make the UE guys proud
[18:13:59 EDT(-0400)] <athena> or you know, at least not think I ignore them!
[18:14:52 EDT(-0400)] <EricDalquist> lol
[18:17:01 EDT(-0400)] <athena> i do try
[18:17:15 EDT(-0400)] <EricDalquist> I hear ya, I do it
[18:17:18 EDT(-0400)] <EricDalquist> too
[18:23:40 EDT(-0400)] <athena> ok eric, i've uploaded a form JSP and a success JSP
[18:23:46 EDT(-0400)] <athena> hopefully that'll at least get us started
[18:24:24 EDT(-0400)] <EricDalquist> great
[18:24:35 EDT(-0400)] <EricDalquist> I'll spend some time on the code behind it tonight
[18:24:45 EDT(-0400)] <EricDalquist> I'm sending an email to uportal-dev about it
[18:25:08 EDT(-0400)] <athena> awesome
[18:25:15 EDT(-0400)] <athena> let me know if there's other things i can help with
[18:25:20 EDT(-0400)] <athena> i think i'm mostly done with my uportal work
[18:25:26 EDT(-0400)] <athena> getting the google portlet together now
[18:25:26 EDT(-0400)] <EricDalquist> will do
[18:25:31 EDT(-0400)] <EricDalquist> I'll be back in here when I start on it
[18:25:40 EDT(-0400)] <athena> and hopefully will be able to test gary's changes tomorrow night
[18:25:43 EDT(-0400)] <athena> ok
[18:25:43 EDT(-0400)] <EricDalquist> getting those jira issues fixed is a huge help too (smile)
[18:25:54 EDT(-0400)] <athena> which ones?
[18:26:12 EDT(-0400)] <EricDalquist> like the google portlet one
[18:26:46 EDT(-0400)] <athena> oh
[18:26:47 EDT(-0400)] <athena> yes (smile)
[18:27:00 EDT(-0400)] <athena> well, i'm really hoping that most of them are being addressed
[18:27:01 EDT(-0400)] <EricDalquist> pretty much anything that is open against 3.1 are things that I can't easily fix myself
[18:27:34 EDT(-0400)] <athena> yeah
[18:27:41 EDT(-0400)] <athena> i think the google one is pretty much the last one that's left that's mine
[18:27:46 EDT(-0400)] <EricDalquist> great
[18:27:52 EDT(-0400)] <EricDalquist> does that fix both issues related to that portlet?
[18:27:53 EDT(-0400)] <athena> i have some concerns about http://www.ja-sig.org/issues/browse/UP-2265 though
[18:27:55 EDT(-0400)] <athena> no
[18:28:02 EDT(-0400)] <athena> the other one gary's going to have to fix
[18:28:14 EDT(-0400)] <athena> i suspect it's related to the jquery ui widget issues
[18:28:18 EDT(-0400)] <EricDalquist> ok
[18:28:26 EDT(-0400)] <athena> i think there's something weird going on with one of the fluid classes
[18:28:47 EDT(-0400)] <athena> with that tab issue . . . i'd heard it was fixed, but i can't find the jira
[18:28:51 EDT(-0400)] <athena> i think you applied a patch for it
[18:28:57 EDT(-0400)] <athena> i think i'm still seeing it though
[18:28:58 EDT(-0400)] <athena> oh :/
[18:29:09 EDT(-0400)] <athena> also, i'm still getting that weird behavior from time to time that we talked about earlier
[18:29:19 EDT(-0400)] <EricDalquist> :/
[18:29:19 EDT(-0400)] <athena> i'm wondering if there's any chance it's related to the ajax controller?
[18:29:29 EDT(-0400)] <athena> since i'm the only one that seems to have encountered it
[18:29:42 EDT(-0400)] <athena> and most of the work i've been doing has been ajax portlet development
[18:29:47 EDT(-0400)] <EricDalquist> I can't see how that could cause the problem
[18:29:53 EDT(-0400)] <athena> me neither
[18:29:57 EDT(-0400)] <EricDalquist> but who knows
[18:30:00 EDT(-0400)] <athena> i can't see how anything is causing the problem though
[18:31:27 EDT(-0400)] <athena> it's illogical so it should be banned! only sensible errors from now on!
[18:34:00 EDT(-0400)] <EricDalquist> lol
[18:44:46 EDT(-0400)] <EricDalquist> the JSPs look great athena
[18:44:53 EDT(-0400)] <athena> great
[18:45:09 EDT(-0400)] <EricDalquist> if you have time do you think you could try and grab some of collin's/gary's/etc time just to give them a once over?
[18:45:17 EDT(-0400)] <athena> eventually i imagine we'll want to put the string is messages bundles, but it seemed like that would just confuse things right now
[18:45:23 EDT(-0400)] <EricDalquist> yeah
[18:45:25 EDT(-0400)] <athena> i can ask
[18:45:37 EDT(-0400)] <athena> i don't think gary will be able to
[18:45:46 EDT(-0400)] <EricDalquist> this isn't a high priority thing but if they have any ideas or such it would be much appreciated
[18:46:16 EDT(-0400)] <athena> i think he's already scrambling to find the time to fix our bugs
[18:46:17 EDT(-0400)] <athena> yeah
[18:46:30 EDT(-0400)] <athena> maybe we could say something over in fluid and see if anyone is interested
[18:46:36 EDT(-0400)] <EricDalquist> that would be great
[18:46:41 EDT(-0400)] <athena> yeah
[18:46:44 EDT(-0400)] <colinclark> say what?
[18:46:45 EDT(-0400)] <colinclark> (smile)
[18:46:48 EDT(-0400)] <EricDalquist> you mind doing that?
[18:46:48 EDT(-0400)] <athena> hey colin
[18:46:52 EDT(-0400)] <colinclark> heya
[18:47:00 EDT(-0400)] <athena> i was just about to say that you guys had probably wandered off by now - it's late1
[18:47:02 EDT(-0400)] * EricDalquist goes back to figuring out detached portlet window tracking
[18:47:03 EDT(-0400)] <athena> lol
[18:47:52 EDT(-0400)] <colinclark> i'm just finishing up some emails
[18:47:56 EDT(-0400)] <colinclark> but still around
[18:48:00 EDT(-0400)] <colinclark> bosmon is here too
[18:48:21 EDT(-0400)] <colinclark> do you guys need a hand with something for the 3.1 release/
[18:48:22 EDT(-0400)] <colinclark> ?
[18:48:38 EDT(-0400)] <athena> yes, i think we're potentially looking for someone to look over some JSP screens
[18:48:56 EDT(-0400)] <athena> basically we're trying to put together a uportal registration portlet last-minute
[18:49:07 EDT(-0400)] <athena> basically something that would allow deployers to register a uportal instance with jasig
[18:49:24 EDT(-0400)] <athena> so that we can actually have some idea of how many people are using uportal, what hardware, etc.
[18:49:38 EDT(-0400)] <athena> since we've never really been able to get many people registering on the website
[18:49:51 EDT(-0400)] <athena> i think the general idea is you type a few things into a form and it collects the rest automagically
[18:50:01 EDT(-0400)] <athena> http://www.ja-sig.org/wiki/display/UPC/Automated+Portal+Registration
[18:50:04 EDT(-0400)] <colinclark> cool
[18:51:02 EDT(-0400)] <colinclark> We're all sort of crunched with the 1.0 release coming, but we can definitely help.
[18:51:14 EDT(-0400)] <colinclark> I'd say fj4000 might be the best person to take a look.
[18:51:18 EDT(-0400)] <athena> awesome
[18:51:21 EDT(-0400)] <colinclark> He'll be back tomorrow, I can ask him to ping you.
[18:51:27 EDT(-0400)] <athena> thanks!
[18:51:31 EDT(-0400)] <athena> i don't think it'd be anything major
[18:51:52 EDT(-0400)] <athena> but if someone had a couple minutes to look over the one JSP page and give any suggestions you guys might have
[18:51:54 EDT(-0400)] <colinclark> So you just need some sketches or wireframes for the UI? Or code?
[18:52:17 EDT(-0400)] <colinclark> amazing that you guys are doing this... we talked about it briefly in a steering committee meeting, and now here it is! (smile)
[18:52:20 EDT(-0400)] <athena> i have endeavored to do things i hear are encouraged, like, you know, use labels, ro something
[18:52:27 EDT(-0400)] <athena> lol
[18:52:31 EDT(-0400)] <colinclark> (smile)
[18:52:32 EDT(-0400)] <athena> apparently we've been productive lately
[18:52:43 EDT(-0400)] <athena> hey wireframes/sketches would be even better if you have time
[18:52:51 EDT(-0400)] <colinclark> if it comes down to making it look good and have decent markup and the like, fj4000 is your man
[18:52:51 EDT(-0400)] <athena> but whatever you have time for
[18:52:59 EDT(-0400)] <athena> awesome
[18:53:04 EDT(-0400)] <colinclark> i'll mention it to him
[18:53:09 EDT(-0400)] <athena> i'm hoping someone even just has feedback about the text
[18:53:19 EDT(-0400)] <colinclark> ok, sure
[18:54:07 EDT(-0400)] <athena> speaking of talking briefly and then making things happen
[18:54:19 EDT(-0400)] <athena> i think we've actually gotten a start on some utility portlets
[18:54:23 EDT(-0400)] <athena> so i'm very happy about that
[18:54:35 EDT(-0400)] <athena> need to find time to email the list
[18:54:41 EDT(-0400)] <athena> http://qwertied.com/portlets.png
[19:04:39 EDT(-0400)] <colinclark> oh yes, i saw these
[19:04:41 EDT(-0400)] <colinclark> i was going to tell you
[19:04:43 EDT(-0400)] <colinclark> awesome!
[19:05:15 EDT(-0400)] <colinclark> giving igoogle a run for its money (wink)
[19:07:33 EDT(-0400)] <athena> lol
[19:07:51 EDT(-0400)] <athena> well, when someone writes the igoogle widget importer portlet we'll really be all set (wink)
[19:08:07 EDT(-0400)] <athena> it actually is pretty easy to add a single widget now if you really want to
[19:08:13 EDT(-0400)] <EricDalquist> I think there is already a jsr168 google gadget portlet
[19:08:21 EDT(-0400)] <athena> we have the google docs one running in our demo instance
[19:08:21 EDT(-0400)] <athena> yeah
[19:08:28 EDT(-0400)] <athena> i dont' know if it's publicly posted anywhere though
[19:08:35 EDT(-0400)] <EricDalquist> not sure
[19:08:35 EDT(-0400)] <athena> i'm sure there have been a few versions
[19:08:46 EDT(-0400)] <athena> should we worry about security with those?
[19:08:47 EDT(-0400)] <EricDalquist> I think we should have a portlets,portlets,portlets focus for 3.2
[19:08:52 EDT(-0400)] <EricDalquist> that is a good question
[19:08:56 EDT(-0400)] <athena> yes, that would be fantastic
[19:08:58 EDT(-0400)] <EricDalquist> do they have access to the portal dom?
[19:09:04 EDT(-0400)] <EricDalquist> or the portal domain via JS calls?
[19:09:14 EDT(-0400)] <athena> finally ramp up on some of that default content
[19:09:16 EDT(-0400)] <athena> i don't know
[19:09:21 EDT(-0400)] <athena> i can't remember if they're in iframes or not
[19:09:39 EDT(-0400)] <athena> last time i tried to break stuff it didn't seem ridiculously trivial, at least
[19:09:54 EDT(-0400)] <athena> but i've seen some exploits demonstrated in the past
[19:10:14 EDT(-0400)] <EricDalquist> yeah
[19:11:22 EDT(-0400)] <colinclark> i can't remember either if gadgets are in iframes...
[19:11:58 EDT(-0400)] <colinclark> but it's pretty safe to assume that, in HTML, when things are mashed up together, that the DOM is the easiest place to leak sensitive data
[19:12:14 EDT(-0400)] <colinclark> I guess the key is the same origin policy.
[19:12:25 EDT(-0400)] <colinclark> JSONP in the portal should probably cause us some concern.
[19:12:43 EDT(-0400)] <athena> yeah
[19:12:44 EDT(-0400)] <athena> it's hard
[19:12:48 EDT(-0400)] <colinclark> totally
[19:12:49 EDT(-0400)] <athena> i mean we want to include cool stuff
[19:12:53 EDT(-0400)] <colinclark> yes
[19:13:02 EDT(-0400)] <athena> but i think the portal's a particularly concerning target because it has so many data sources on one page
[19:13:08 EDT(-0400)] <colinclark> bosmon and I were talking about exactly this subject in the bar in Dallas when you dropped by to say goodbye
[19:13:24 EDT(-0400)] <colinclark> Secure mashups are really only viable with some help from the server.
[19:13:28 EDT(-0400)] <athena> and it's quite likely to include sensitive info like grades, financials, SS#, etc.
[19:13:33 EDT(-0400)] <athena> ah, wish i'd had time to chat about that (smile)
[19:13:38 EDT(-0400)] <colinclark> And even then, there's the issue Erik raised about whether users trust the portal with their info, too.
[19:13:38 EDT(-0400)] <EricDalquist> so the solution is not returning JSON right?
[19:13:49 EDT(-0400)] <athena> yeah that's a good point colin
[19:13:54 EDT(-0400)] <colinclark> EricDalquist: It's not JSON that is the problem....
[19:13:59 EDT(-0400)] <colinclark> it's JSONP
[19:14:03 EDT(-0400)] <colinclark> awkward naming
[19:14:10 EDT(-0400)] * EricDalquist is not familiar with JSONP
[19:14:11 EDT(-0400)] <colinclark> this is a strategy for getting around the same origin policy
[19:14:24 EDT(-0400)] <colinclark> if i understand it correctly, it basically works like this:
[19:14:28 EDT(-0400)] <EricDalquist> is that where you write a <script> tag ?
[19:14:34 EDT(-0400)] <colinclark> yep, that's it
[19:14:37 EDT(-0400)] <EricDalquist> yeah
[19:14:38 EDT(-0400)] <colinclark> so for the twitter example
[19:14:47 EDT(-0400)] <colinclark> you can do jsonp by loading a script tag from twitter.com
[19:14:52 EDT(-0400)] <colinclark> and then updating it with a query string
[19:14:54 EDT(-0400)] <EricDalquist> so I ran into that trying to do a mashup with the madison bus info system
[19:15:05 EDT(-0400)] <colinclark> so, for one, it limits you to GET, which is a drag
[19:15:20 EDT(-0400)] <colinclark> but secondly, you have to really trust the place you are doing JSONP with
[19:15:25 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[19:15:26 EDT(-0400)] <EricDalquist> yeah
[19:15:38 EDT(-0400)] <athena> sorry - router hiccup
[19:15:46 EDT(-0400)] <athena> anthony colebourne did some neat stuff with antisamy in his news reader portlet
[19:15:58 EDT(-0400)] <EricDalquist> trust as in any browser page with access to your auth cookie must have all content on it trusted
[19:16:01 EDT(-0400)] <EricDalquist> right?
[19:16:06 EDT(-0400)] <athena> basically lets you create policy files that dictate what elements are allowed - so you can strip out scripts, images, etc.
[19:16:19 EDT(-0400)] <athena> and use different policies at different times / for different servers
[19:17:21 EDT(-0400)] <EricDalquist> so the way this company is preventing mashups with their map data is they don't return true JSON data
[19:17:39 EDT(-0400)] <EricDalquist> for example: http://webwatch.cityofmadison.com/webwatch/UpdateWebMap.aspx?u=80&amp;timestamp=1237331835995
[19:17:48 EDT(-0400)] <EricDalquist> they have custom delimeters
[19:17:53 EDT(-0400)] <EricDalquist> and do browser-side parsing
[19:18:22 EDT(-0400)] <EricDalquist> which means only javascript running on content they rendered can use that data
[19:18:26 EDT(-0400)] <EricDalquist> since JSONP won't work with it
[19:19:00 EDT(-0400)] <EricDalquist> and then the solution to calls that make changes is that we require POST
[19:19:31 EDT(-0400)] <EricDalquist> so like the layout customization callbacks should only honor POSTs and return an error on GET
[19:19:39 EDT(-0400)] <EricDalquist> to require that calls are coming from portal rendered content
[19:19:45 EDT(-0400)] <EricDalquist> am I on track with this stuff?
[19:20:42 EDT(-0400)] <colinclark> well, i think the data format doesn't much matter
[19:20:57 EDT(-0400)] <colinclark> assuming "evil script" got into the portal in the first place, in some form...
[19:21:08 EDT(-0400)] <EricDalquist> well I think the concern is the iframes
[19:21:09 EDT(-0400)] <colinclark> all it has to do is inject a <script> tag to send data back home
[19:21:30 EDT(-0400)] <colinclark> i am still somewhat fuzzy on these issues, but it's pretty fascinating
[19:21:35 EDT(-0400)] <EricDalquist> if an evil script appears in the portal rendered DOM you're screwed
[19:22:02 EDT(-0400)] <EricDalquist> so the hope is you trust the content you're rendering inline
[19:22:19 EDT(-0400)] <EricDalquist> where as the bigger danger would be letting users add arbitrary content
[19:22:31 EDT(-0400)] <EricDalquist> in that case you need to do something like an iframe
[19:22:46 EDT(-0400)] <EricDalquist> and then you're OK as long as the iframe can't effectively call your AJAX APIs
[19:22:53 EDT(-0400)] <EricDalquist> due to them requiring POSTs to change data
[19:23:03 EDT(-0400)] <EricDalquist> and returning sensitive data in some format other than JSON
[19:23:41 EDT(-0400)] <EricDalquist> since if it isn't json the JSONP approach fails because the <script> tag will complain about getting invalid javascript back from the server
[19:24:14 EDT(-0400)] <athena> i'm consistently glad that the c:out tag escapes XML
[19:24:26 EDT(-0400)] <colinclark> EricDalquist: Yes, that makes sense.
[19:24:35 EDT(-0400)] <colinclark> User-supplied data should definitely be sandboxed in an iframe
[19:24:53 EDT(-0400)] <EricDalquist> which would include a generic gadgets portlet
[19:25:01 EDT(-0400)] <EricDalquist> we're safe there as long as they are Iframes
[19:25:07 EDT(-0400)] <athena> do you have best practices recommendations about user-supplied strings?
[19:25:11 EDT(-0400)] <EricDalquist> and as long as the portal ajax APIs are following the rules
[19:25:15 EDT(-0400)] <EricDalquist> me?
[19:25:40 EDT(-0400)] <athena> i meant more colin, but if you have input then sure
[19:26:01 EDT(-0400)] <EricDalquist> escape everything?
[19:26:40 EDT(-0400)] <athena> sounds reasonable to me (smile)
[19:26:47 EDT(-0400)] <athena> i'm not sure i know what "everything" is
[19:26:52 EDT(-0400)] <athena> apostrophes clearly
[19:27:16 EDT(-0400)] <EricDalquist> pretty much set the default escaping for spring to escape xml and javascript
[19:27:51 EDT(-0400)]

<EricDalquist> and as handy as it is to do $

Unknown macro: {foo}

directly in a JSP you really need to do $

Unknown macro: {fn}

[19:27:55 EDT(-0400)] <EricDalquist> that is actually all that is needed
[19:28:03 EDT(-0400)] <EricDalquist> you there is no JS specific escaping
[19:28:21 EDT(-0400)] <EricDalquist> that makes sure no one can write out html tags to invoke scripts and such
[19:28:31 EDT(-0400)] <EricDalquist> then on the DB side everything should be a prepared statement
[19:28:42 EDT(-0400)] <athena> it escapes xml by default i think?
[19:28:50 EDT(-0400)]

<EricDalquist> $

Unknown macro: {foo}

does not


[19:28:54 EDT(-0400)] <athena> just c:out?
[19:28:54 EDT(-0400)] <EricDalquist> and there is no way to make it
[19:29:03 EDT(-0400)] <EricDalquist> you can set the default for c:out
[19:29:09 EDT(-0400)] <EricDalquist> but not direct usage of ${}
[19:29:27 EDT(-0400)] <athena> i actually assumed it had the same defaults as the c:out tag
[19:29:30 EDT(-0400)] <athena> that's unfortunate
[19:29:31 EDT(-0400)] <EricDalquist> if you ever do have to do dynamic SQL building (we are here for an app that builds a query dynamically) use a lookup table or file
[19:29:34 EDT(-0400)] <EricDalquist> nope
[19:29:51 EDT(-0400)] <athena> ugh
[19:29:55 EDT(-0400)] <EricDalquist> if you use ${} outside of a tag it just evaluates it exactly as is right there
[19:29:58 EDT(-0400)] <EricDalquist> it is very unfortunate
[19:30:01 EDT(-0400)] <athena> yeah
[19:30:02 EDT(-0400)] <EricDalquist> and released behavior now
[19:30:04 EDT(-0400)] <athena> i'll have to fix some stuff
[19:30:05 EDT(-0400)] <EricDalquist> so it can't change
[19:30:15 EDT(-0400)] <athena> i don't know why i thought it had the same defaults as the c tag
[19:30:21 EDT(-0400)] * athena is tempted to go complain to shawn
[19:30:26 EDT(-0400)] <EricDalquist> another great example why public API design is so important (smile)
[19:30:47 EDT(-0400)] <EricDalquist> the problem was not there in JSTL 1.0
[19:30:58 EDT(-0400)] <EricDalquist> because you couldn't use ${} unless you were in a tag
[19:31:04 EDT(-0400)] <EricDalquist> so c:out was your only option
[19:31:08 EDT(-0400)] <athena> right
[19:31:16 EDT(-0400)] <EricDalquist> the problem is 1.1 added the support to write it out anywhere in the page
[19:31:20 EDT(-0400)] <athena> yes
[19:31:27 EDT(-0400)] <EricDalquist> but they didn't think about the lack of default escaping
[19:31:28 EDT(-0400)] <athena> which is nicely convenient because i hate typing
[19:31:32 EDT(-0400)] <EricDalquist> yup
[19:32:00 EDT(-0400)]

<EricDalquist> so you're stuck doing <c:out value="$

Unknown macro: {foo}

"/> or $

Unknown macro: {fn}

[19:32:05 EDT(-0400)] <EricDalquist> I usually do #2
[19:32:13 EDT(-0400)] <EricDalquist> or at least try and remember to do #2
[19:32:28 EDT(-0400)] <athena> interesting - shawn says it was likely an oversight
[19:32:40 EDT(-0400)] <athena> talking to him about JSTL might explain why i thought it was otherwise then, i guess
[19:32:48 EDT(-0400)] <EricDalquist> yeah
[19:33:07 EDT(-0400)] <EricDalquist> it wouldn't have been too hard at the time to say that the default esacpe setting applies to EL evaluated outside of tags
[19:33:12 EDT(-0400)] <EricDalquist> but it was just missed
[19:33:17 EDT(-0400)] <athena> yeah
[19:33:25 EDT(-0400)] <athena> that was pretty much his impression as wel
[19:33:31 EDT(-0400)] <EricDalquist> and now will cause the horrors of content injection for eternety (tongue)
[19:33:31 EDT(-0400)] <athena> i guess he'd left for law school by that time though
[19:33:51 EDT(-0400)] <EricDalquist> so do our current AJAX callbacks require POST?
[19:34:09 EDT(-0400)] <EricDalquist> for adding/removing channels and modifying the layout?
[19:34:28 EDT(-0400)] <athena> i don't think so
[19:34:37 EDT(-0400)] <athena> i think either work
[19:34:49 EDT(-0400)] <athena> but that could easily be changed
[19:34:56 EDT(-0400)] <athena> that code hasn't really been touched much since 2.6
[19:35:06 EDT(-0400)] <EricDalquist> I'll file that as a bug for 3.1
[19:35:13 EDT(-0400)] <EricDalquist> since that is a potential security vulnerability
[19:35:31 EDT(-0400)] <EricDalquist> you could visit any other site and if you had a portal cookie that site could manipulate your portal layout (tongue)
[19:35:52 EDT(-0400)] <athena> is that not the case if it requires a post?
[19:36:00 EDT(-0400)] <EricDalquist> nope
[19:36:14 EDT(-0400)] <EricDalquist> because of same-domain their only option is to call them with a <script> tag in the dom
[19:36:19 EDT(-0400)] <EricDalquist> which can only be a GET
[19:36:34 EDT(-0400)] <EricDalquist> you can't do a full XMLHTTPReq do a different domain
[19:37:20 EDT(-0400)] <athena> what do you mean by full?
[19:37:59 EDT(-0400)] <EricDalquist> well can't do one at all
[19:38:00 EDT(-0400)] <EricDalquist> sorry
[19:38:05 EDT(-0400)] <athena> oh ok (smile)
[19:38:25 EDT(-0400)] <athena> i think you could probably still construct something that would post to that portal page
[19:38:27 EDT(-0400)] <EricDalquist> I believe you can only do a XHR to the domain that rendered the page
[19:38:30 EDT(-0400)] <athena> just maybe not w/o the user knowing
[19:38:47 EDT(-0400)] <EricDalquist> I don't think so
[19:38:52 EDT(-0400)] <athena> that should be correct, yes
[19:39:02 EDT(-0400)] <EricDalquist> well ...
[19:39:04 EDT(-0400)] <athena> why not just build a form and then submit it/
[19:39:05 EDT(-0400)] <athena> ?
[19:39:10 EDT(-0400)] <EricDalquist> you could have your page have an iframe
[19:39:16 EDT(-0400)] <EricDalquist> and the iframe clould have a form
[19:39:24 EDT(-0400)] <EricDalquist> and JS could submit that form in the hidden iframe
[19:39:25 EDT(-0400)] <EricDalquist> hrm
[19:39:29 EDT(-0400)] <EricDalquist> freaking JS
[19:39:33 EDT(-0400)] <EricDalquist> (tongue)
[19:39:34 EDT(-0400)] <athena> yep
[19:39:48 EDT(-0400)] <athena> i mean i guess it's fair to say that it's a little harder with a post, maybe
[19:39:54 EDT(-0400)] <EricDalquist> I guess I need to go read more on XSS tonight
[19:39:57 EDT(-0400)] <athena> but i think you could do it either way if you really wanted
[19:39:57 EDT(-0400)] <EricDalquist> yeah
[19:42:02 EDT(-0400)] <athena> at least it'd be difficult to manipulate that page
[19:42:06 EDT(-0400)] <athena> er, servlet
[19:42:09 EDT(-0400)] <athena> i mean not impossible
[19:42:12 EDT(-0400)] <EricDalquist> yeah
[19:42:15 EDT(-0400)] <athena> but not really convenient
[19:42:21 EDT(-0400)] <athena> the easiest thing would be to add content
[19:42:26 EDT(-0400)] <athena> anything else you need to know the node id for
[19:42:36 EDT(-0400)] <EricDalquist> so I think the solution here is that you have some sort of random token on the page
[19:42:54 EDT(-0400)] <EricDalquist> so when we render a portal page we stick in a hidden field with a random token
[19:43:07 EDT(-0400)] <EricDalquist> and that is used as a token in all of our AJAX callbacks?
[19:43:08 EDT(-0400)] <EricDalquist> crap
[19:43:12 EDT(-0400)] <EricDalquist> I need to read up on this more
[19:43:14 EDT(-0400)] <EricDalquist> ok
[19:43:16 EDT(-0400)] <EricDalquist> I'm going home
[19:43:23 EDT(-0400)] <EricDalquist> I'll probably be back on in a while
[19:43:31 EDT(-0400)] <athena> lol
[19:43:35 EDT(-0400)] <athena> go home, yes (smile)
[20:26:02 EDT(-0400)] * JASIGLogBot2 (n=PircBot@jasig.Princeton.EDU) has joined ##uportal
[20:26:02 EDT(-0400)] * Topic is 'http://uportal.pastebin.com/ - http://www.ja-sig.org/wiki/display/UPC/uportal+IRC+Logs' set by EricDalquist on 2008-02-27 12:32:13 EST(-0500)
[20:34:28 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[20:35:15 EDT(-0400)] <EricDalquist> so I was doing a bit more reading athena
[20:35:32 EDT(-0400)] <EricDalquist> what I was thinking of is actually a Cross-site request forgery
[20:35:35 EDT(-0400)] <EricDalquist> http://en.wikipedia.org/wiki/Cross-site_request_forgery
[20:35:56 EDT(-0400)] <EricDalquist> I'm pretty sure uPortal is safe from XSS (as a framework at least, portlets are on their own)
[20:36:19 EDT(-0400)] <EricDalquist> and I don;'t think any of our existing JSON feeds expose sensative information
[20:36:49 EDT(-0400)] <EricDalquist> so the only concern would be a CSRF where someone creates URLs that make changes to the user's layout or some such
[20:37:02 EDT(-0400)] <EricDalquist> which probably isn't a huge security issue, just a serious annoyance
[20:37:21 EDT(-0400)] <EricDalquist> so we probably want to fix it eventually but it doesn't half to be now
[20:38:02 EDT(-0400)] <athena> sounds good
[20:38:05 EDT(-0400)] <athena> glad we don't have major issues
[20:38:19 EDT(-0400)] <EricDalquist> yeah
[20:38:28 EDT(-0400)] <athena> the ajax stuff is part of why i've not really wanted to add a "reset my whole layout" function
[20:38:30 EDT(-0400)] <EricDalquist> and there are some relatively simple fixe
[20:38:37 EDT(-0400)] <EricDalquist> fixes*
[20:39:06 EDT(-0400)] <EricDalquist> the easiest is that we change any operation that makes a change to require POST
[20:39:19 EDT(-0400)] <EricDalquist> and then when the JS does the post it looks at the jsessionid cookie
[20:39:26 EDT(-0400)] <EricDalquist> and adds that value as a post parameter
[20:39:41 EDT(-0400)] <EricDalquist> the server can then verify if the session id param and the session id cookie match
[20:39:51 EDT(-0400)] <EricDalquist> since there is no way for an attacking site to ever find out the value of the jsessionid cookie
[20:40:11 EDT(-0400)] <EricDalquist> thats easily codable as a fitler to stick in front of any ajax callback
[20:40:17 EDT(-0400)] <EricDalquist> filter*
[20:40:34 EDT(-0400)] <athena> makes sense
[20:40:34 EDT(-0400)] <athena> (smile)
[20:40:50 EDT(-0400)] <EricDalquist> and that should be a fairly simple modification in the JS as well I imagine
[20:41:24 EDT(-0400)] <athena> totally
[20:41:35 EDT(-0400)] <athena> if it's not doing post now it could be in like 10s
[20:41:58 EDT(-0400)] <EricDalquist> even that would be a great change before 3.1 if you want to take a crack at it
[20:42:07 EDT(-0400)] <athena> sure i can do that
[20:42:22 EDT(-0400)] <athena> can do the post at the very least
[20:44:37 EDT(-0400)] <EricDalquist> I think HTTP 405 is the appropriate response then for anything non-POST
[20:47:35 EDT(-0400)] <athena> ok, that's fair
[20:47:54 EDT(-0400)] <athena> ok, i'm going to take a break for a while
[20:48:11 EDT(-0400)] <EricDalquist> no problem
[20:48:16 EDT(-0400)] <EricDalquist> I'm having fun cleaning (smile)
[20:48:19 EDT(-0400)] <athena> lol
[20:48:22 EDT(-0400)] <athena> fun indeed (smile)
[20:48:32 EDT(-0400)] <athena> i did a bunch of that over the weekend - really needed doing
[20:48:35 EDT(-0400)] <athena> i've been out of town so much
[20:48:37 EDT(-0400)] <athena> easy to get behind
[20:48:48 EDT(-0400)] <athena> vacuuming at 11:30 pm isn't good for my sleep schedule though
[20:48:51 EDT(-0400)] * athena buzzes
[20:49:06 EDT(-0400)] <EricDalquist> lol
[20:49:07 EDT(-0400)] <EricDalquist> yeah
[21:09:13 EDT(-0400)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has left ##uportal
[21:44:34 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[21:51:43 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined ##uportal