Revise Core Gadget Section 7 for 2.5?
ddumont
- libs
- An absolute relative URL that points to any JavaScript files necessary to satisfy the features specified in /ModulePrefs/Require and /ModulePrefs/Optional (Section 4.1.1.1) elements in the Gadget.
- Seeing as how Shindig doesn't implement this correctly at all right now (working on fixing that), and the fact that there's no mention of what exactly the old url was relative TO, I can't see how this will really impact anyone.
- Can we fix this for 2.5?
James M Snell
do we have any examples of it's use? I need something more concrete
for the rewrite
On Wed, Apr 11, 2012 at 11:29 AM, ddumont <ddu...@us.ibm.com> wrote:
> http://opensocial-resources.googlecode.com/svn/spec/2.0.1/Core-Gadget.xml#ContentRedirect
>
> I'd like to alter the language in this section to change this sentence in
> the following way (removed added)
>
> libsAn absolute relative URL that points to any JavaScript files necessary
> to satisfy the features specified in /ModulePrefs/Require and
> /ModulePrefs/Optional (Section 4.1.1.1) elements in the Gadget.
> Seeing as how Shindig doesn't implement this correctly at all right now
> (working on fixing that), and the fact that there's no mention of what
> exactly the old url was relative TO, I can't see how this will really
> impact anyone.Can we fix this for 2.5?
>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/eoikp0sF-iYJ.
> To post to this group, send email to
> opensocial-an...@googlegroups.com.
> To unsubscribe from this group, send email to
> opensocial-and-gadg...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
Dan Dumont
For shindig this would be something like //server.com/js/core:rpc:blah.js
We also send a parent with the location of the container server, but that param isn't in the spec. I think we can slightly alter the wording here and just send the whole url to the js file without having to add another param formally in the spec.
Matt F.
.
> To unsubscribe from this group, send email to
> For more options, visit this group at
>
--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To post to this group, send email to opensocial-and-gadgets-spec@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadgets-spec+unsub...@googlegroups.com.
For more options, visit this group at
James M Snell
the 3.0 draft... it would be good to get something into 2.5 also tho.
>> > opensocial-an...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > opensocial-and-gadg...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "OpenSocial and Gadgets Specification Discussion" group.
>> To post to this group, send email to
>> opensocial-an...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> opensocial-and-gadg...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/vypxhUZs33wJ.
>
> To post to this group, send email to
> opensocial-an...@googlegroups.com.
> To unsubscribe from this group, send email to
> opensocial-and-gadg...@googlegroups.com.
Matt F.
>> > To unsubscribe from this group, send email to
>> > For more options, visit this group at
>> > http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "OpenSocial and Gadgets Specification Discussion" group.
>> To post to this group, send email to
>> To unsubscribe from this group, send email to
>> For more options, visit this group at
>> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/vypxhUZs33wJ.
>
> To post to this group, send email to
> To unsubscribe from this group, send email to
Ryan Baxter
Dan Dumont
+1 for me in the 1 url camp. But like I said, this implementation won't preclude there being multiple, in the case that the multi-url camp wins in the end. :)
.
>> > opensocial-an...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > opensocial-and-gadg...@googlegroups.com.
>> > For more options, visit this group at
>> >
http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>>
>> --
>> You received this message because you are subscribed to the Google
Groups
>> "OpenSocial and Gadgets Specification Discussion" group.
>> To post to this group, send email to
>> opensocial-an...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> opensocial-and-gadg...@googlegroups.com.
>> For more options, visit this group at
>>
http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>>
>>
> --
> You received this message because you are subscribed to the Google
Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To view this discussion on the web visit
>
https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/vypxhUZs33wJ.
>
> To post to this group, send email to
> opensocial-an...@googlegroups.com.
> To unsubscribe from this group, send email to
> opensocial-and-gadg...@googlegroups.com.
> For more options, visit this group at
>
http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
--
You received this message because you are subscribed to the Google Groups
"OpenSocial and Gadgets Specification Discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/7tkJM1Y5IEsJ.
To post to this group, send email to opensocial-an...@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
James M Snell
One URL makes the most sense as anything beyond that simply becomes to unwieldly to pass around in a query string. The other alternative, if multiple uris are required, is to use Link headers in the request to identify the lib urls... E.g.
GET /foo HTTP/1.1
Link: <http://...>;rel="lib"
With one lib link per uri to include. It provides a relatively simple alternative.
Franklin, Matthew B.
Reply-To: OpenSocial and Gadgets Discussion <opensocial-an...@googlegroups.com>
Date: Thu, 12 Apr 2012 16:48:52 -0700
To: OpenSocial and Gadgets Discussion <opensocial-an...@googlegroups.com>
Subject: Re: [osgs] Revise Core Gadget Section 7 for 2.5?
One URL makes the most sense as anything beyond that simply becomes to unwieldly to pass around in a query string. The other alternative, if multiple uris are required, is to use Link headers in the request to identify the lib urls... E.g.
GET /foo HTTP/1.1
Link: <http://...>;rel="lib"
With one lib link per uri to include. It provides a relatively simple alternative.
Be it a list or not, there still wouldn't be anything stopping shindig from using only 1 url. So that's how I'm going to implement it in shindig.
+1 for me in the 1 url camp. But like I said, this implementation won't preclude there being multiple, in the case that the multi-url camp wins in the end. :)
From: Ryan Baxter <rbax...@gmail.com>
To: opensocial-an...@googlegroups.com,
Date: 04/12/2012 08:24 AM
Subject: Re: [osgs] Revise Core Gadget Section 7 for 2.5?
Sent by: opensocial-an...@googlegroups.com
When I read 3.4,
"..retrieving core and feature-linked JavaScript.."
makes it sound like the JS should be retrieved in one request.
On Wednesday, April 11, 2012 8:52:38 PM UTC-4, Matt F. wrote:
What about
"An absolute URL from which the container MUST serve a single file containing all JavaScript code required to satisfythe features specified in /ModulePrefs/Require and /ModulePrefs/Optional (Section 4.1.1.1) elements in the Gadget. "
Though after re-reading section 3.4, it appears the intent was a list of URLs.....
On Wednesday, April 11, 2012 8:42:22 PM UTC-4, James M Snell wrote:
I've started to work up a clarification on that particularpoint in
James M Snell
are a number of concerns that would need to be addressed.
For one, using the query string approach, the caching model is a bit
cleaner... using the Link header approach, we'd have to rely on the
use of Vary in the response to address caching of the responses...
e.g.
GET /foo HTTP/1.1
Link: <http://example.org/test.js>; rel="lib-script",
<http://example.org/test2.js>; rel="lib-script",
HTTP/1.1 200 OK
Content-Type: text/html
Vary: Link
<html>
<head>
<script src="http://example.org/test.js" />
<script src="http://example.org/test2.js" />
</head>
<body>
...
</body>
</html>
This is workable, but we would just need to be aware and there are
some user agents that do not handle Vary properly.
- James
James M Snell
spotted one fairly significant challenge with the libs approach. Dan
and I discussed it a bit offline and came up with a recommendation for
dealing with it that requires adding a bit of language in the spec...
Here's the issue: Suppose I have a gadget that uses remote content.. e.g.
<Module>
<ModulePrefs>
<Require feature="foo" />
</ModulePrefs>
<Content type="url" href="http://example.org" />
</Module>
This will trigger the container to send a request to the remote server
that includes a libs parameter to specify the javascript the remote
server should include in the response to load the features... e.g.
http://example.org?libs=http://container.org/feature:foo:core.js
The expectation is that example.org is expected to include the script
identified by the libs parameter in the returned HTML. e.g.
<html><head><script src="http://container.org/feature:foo:core.js"
/>...</html>
The problem with this approach is that it is wide open for a
man-in-the-middle script injection attack. That is, someone can
intercept the request and append a new script to the request...
http://example.org?libs=http://container.org/feature:foo:core.js&libs=http://evil.com/evil.js
If example.org blindly includes whatever scripts it is given without
verifying that it can trust the origin of the script, then we have a
major issue.
To address this concern, I recommend adding the following to the
core-gadget spec:
1. Strong language recommending that the remote site verify that it
can trust the origin of any scripts it is asked to include
2. Adding language that says that container SHOULD use signed fetch
with ALL proxied and redirected content by default (e.g. for all
<Content type="url" href="..."/> and <Content type="html" href="..."
/> cases. This would require dev's to explicitly switch off signed
request with authz="none" if that's what they really want.
Thoughts?
Franklin, Matthew B.
-Matt
>-----Original Message-----
>From: opensocial-an...@googlegroups.com [mailto:opensocial-
>and-gadg...@googlegroups.com] On Behalf Of James M Snell
>Sent: Friday, April 13, 2012 2:27 PM
>To: opensocial-an...@googlegroups.com
>Subject: Re: [osgs] Revise Core Gadget Section 7 for 2.5?
>
>>> link header is definitely compelling for 3.0 though.
>/vypxhUZs33wJ.
>>>> >
>>>> > To post to this group, send email to
>>>> > opensocial-an...@googlegroups.com.
>>>> > To unsubscribe from this group, send email to
>>>> > opensocial-and-gadg...@googlegroups.com.
>>>> > For more options, visit this group at
>>>> > http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>Groups
>>>> "OpenSocial and Gadgets Specification Discussion" group.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-
>To post to this group, send email to opensocial-and-gadgets-
>sp...@googlegroups.com.
>To unsubscribe from this group, send email to opensocial-and-gadgets-
>spec+uns...@googlegroups.com.
