[12:59:08 CDT(-0500)] <EricDalquist> freaking javascript
[12:59:09 CDT(-0500)] <EricDalquist> http://directwebremoting.org/blog/joe/2007/03/05/json_is_not_as_safe_as_people_think_it_is.html
[12:59:55 CDT(-0500)] <athena> evil
[13:00:17 CDT(-0500)] <athena> probably still need to talk about what we want to do for REST feed security
[13:00:28 CDT(-0500)] <EricDalquist> I'm doing more looking into CSRF protection for a portlet I'm working on here
[13:00:38 CDT(-0500)] <EricDalquist> and finding all sorts of badness that can be done
[13:00:42 CDT(-0500)] <athena> :/
[13:00:56 CDT(-0500)] <EricDalquist> primarily because JS is so flexible
[13:01:09 CDT(-0500)] <athena> yeah
[13:14:09 CDT(-0500)] <EricDalquist> hrm ok I re-read that looks like if you do true json
[13:14:10 CDT(-0500)] <EricDalquist> and have {} be your top level element the data is safe
[13:14:11 CDT(-0500)] <EricDalquist> it isn't safe when the top level element is an []
[13:14:25 CDT(-0500)] <athena> gotcha
[13:14:30 CDT(-0500)] <athena> don't know that it's even possible to make it unsafe using the spring json view then
[13:14:37 CDT(-0500)] <EricDalquist> I don't think it is
[13:14:39 CDT(-0500)] <athena> yeah
[13:14:40 CDT(-0500)] <athena> think the view requires a map
[13:14:49 CDT(-0500)] <EricDalquist> http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/servlet/view/json/MappingJacksonJsonView.html#setPrefixJson(boolean)
[13:14:50 CDT(-0500)] <EricDalquist> interesting feature
[13:18:02 CDT(-0500)] <EricDalquist> interesting, another mitigation approach is to look for "Content-Type: application/json" in the request
[13:18:12 CDT(-0500)] <EricDalquist> that is never set by a browser when making a request from a <script> tag
[13:18:26 CDT(-0500)] <EricDalquist> and in that case just throw a 400 class error
[13:28:16 CDT(-0500)] <athena> interesting
[13:28:32 CDT(-0500)] <athena> that seems like a workable approach
[13:28:55 CDT(-0500)] <athena> i like these solutions that don't seem to impact things like cachine
[13:28:57 CDT(-0500)] <athena> er, caching
[13:33:43 CDT(-0500)] <EricDalquist> yeah
[13:36:43 CDT(-0500)] <EricDalquist> the only down side of that one is trying to view the JSON response directly in a browser would get you the unauthorized error
[13:43:09 CDT(-0500)] <athena> hm, which one would?
[13:43:33 CDT(-0500)] <EricDalquist> the server checking the accept or content-type headers on the requet
[13:44:01 CDT(-0500)] <EricDalquist> the point of it is to make sure your JS always sets the json content type and accept headers
[17:35:35 CDT(-0500)] <rickard> holdorph: You there?
[17:36:06 CDT(-0500)] <holdorph> partially 
(somewhat busy in another window, but will respond here as I'm able)
[17:36:39 CDT(-0500)] <rickard> Ok. Sorry to bother you, but I'm stuck on an XSL/XPath issue that you might be able to help me with.
[17:37:43 CDT(-0500)] <rickard> <xsl:for-each select="tab[starts-with(@externalId, $SOME_VARIABLE)]>
[17:38:24 CDT(-0500)] <rickard> This loops over all tab elements whose externalId attribute starts with $SOME_VARIABLE. This works.
[17:40:21 CDT(-0500)] <rickard> In the for-each, I then have to check if there are tab elements that start with the externalId of the current element in the loop.
[17:40:24 CDT(-0500)] <rickard> For this, I have:
[17:40:32 CDT(-0500)] <rickard> <xsl:variable name="CURRENT_TAB" select="@externalId"/>
[17:41:41 CDT(-0500)] <rickard> <xsl:variable name="HAS_SUBTABS" select="count(../tab[starts-with(@externalId, $CURRENT_TAB)) > 0"/>
[17:42:02 CDT(-0500)] <rickard> This also works. However, is there a way to get rid of the CURRENT_TAB variable?
[17:43:20 CDT(-0500)] <rickard> If I just replace it into the query, it would result in:
[17:43:31 CDT(-0500)] <rickard> <xsl:variable name="HAS_SUBTABS" select="count(../tab[starts-with(@externalId, @externalId)) > 0"/>
[17:43:37 CDT(-0500)] <holdorph> i'm sorry, but XSL is not my strong point, and given that my XSL is so weak, I don't know any of uPortal's XSL. but maybe athena who's logged into the channel will see the question. she does more with it then I do.
[17:43:51 CDT(-0500)] <rickard> Alright, no problem. Thanks anyway.
[17:44:07 CDT(-0500)] <athena> hyea
[17:44:10 CDT(-0500)] <athena> er, heya
[17:44:25 CDT(-0500)] <athena> i don't think there's a way to delete a variable in XSLT
[17:44:31 CDT(-0500)] <rickard> Hi
[17:44:54 CDT(-0500)] <rickard> Well, not delete. I'm just curious if I can "optimize" my code to not use the CURRENT_TAB variable.
[17:45:10 CDT(-0500)] <athena> oh, i see now
[17:45:18 CDT(-0500)] <athena> errrr
[17:45:21 CDT(-0500)] <athena> i'd probably just leave it
[17:45:24 CDT(-0500)] <rickard> 
[17:45:35 CDT(-0500)] <athena> what you have is probably pretty optimized by XSLT's standards, unfortunately
[17:45:42 CDT(-0500)] <athena> that may be the most readable solution
[17:45:47 CDT(-0500)] <rickard> True
[17:45:52 CDT(-0500)] * athena hates using XSLT variables
[17:46:02 CDT(-0500)] <rickard> I just have a bunch of variables and wanted to clean it up a bit if possible.
[17:46:21 CDT(-0500)] <rickard> I'll ask in #xml. Maybe they have some ideas.
[17:46:33 CDT(-0500)] <athena> sounds like an excellent solution
General
Content
Integrations