You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Cassie Doll (JIRA)" <ji...@apache.org> on 2008/01/23 02:36:35 UTC
[jira] Created: (SHINDIG-32) cookies.js should not be under a goog.
namespace.
cookies.js should not be under a goog. namespace.
-------------------------------------------------
Key: SHINDIG-32
URL: https://issues.apache.org/jira/browse/SHINDIG-32
Project: Shindig
Issue Type: Improvement
Components: Javascript
Reporter: Cassie Doll
Assignee: Kevin Brown
The cookies.js file needs to be renamespaced to something else. It would also be helpful if it was moved into a feature so that other features could depend on it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SHINDIG-32) cookies.js should not be under a goog. namespace.
Posted by Cassie <do...@apache.org>.
how is a gadget supposed to use the opensocial-samplecontainer then? the
samplecontainer is simply a special version of opensocial-.. i suppose we
could call is opensocial-0.0 or something if you really want to.
opensocial-reference needs to be a feature because of the way feature
dependencies are set up. both opensocial-0.6 and opensocial-0.7 etc will
rely on it. if you give me a way to reference the opensocial reference js
code from the javascript directory that's fine but right now it has to be a
feature because of what you wrote :)
state can not be stored in the parent site because of how opensocial works
right now (ie all of opensocial is put into that iframe, and the state files
modify what is inside the iframe.) i suppose i could change it to use ifpc
but that is just a silly amount of work. this use case should be supported.
it isn't wrong in any way and there are certainly other features that could
come up that might want to do things in this fashion. i understand it will
be easier later, but it isn't easier right now.
why can't i just have some cookies? this data is not secure, it does not
matter if it gets wiped and is purely for convenience. i can't use setprefs
in this case because the pref is not defined in the gadget xml and is added
dynamically. if you give me the ability to add prefs outside of the gadget
xml spec then that would be fine.
if i can't get cookies in a nice way, like i said before, i will just have
to copy cookies.js into the feature itself. that is just silly. it doesn't
need to be part of the spec at all, but it needs to be accessible.
- Cassie
On Wed, Jan 23, 2008 at 12:24 PM, Kevin Brown <et...@apache.org> wrote:
> opensocial-samplecontainer and opensocial-reference shouldn't be features
> either (the feature dependency should be "opensocial-0.6" or "
> opensocial-0.7",
> or whatever we actually have support for), it should be a gadget, and
> state
> should be stored in the parent site. Right now this means you'd have to
> use
> inter frame communication to pass the data, but when/if we get an
> SignedDataServlet in place the open social code can use that to just do an
> XHR.
>
> You may want to save cookies, but we explicitly don't do it on purpose,
> because it's a big security vulnerability. You can never rely on cookies
> being available between page renders (on igoogle the domain changes every
> time you move a gadget on your page and on orkut the domain changes every
> month or so), and when gadgets are cajoled writing cookies will be
> disabled
> completely. Gadget developers are told to use setprefs for storing data
> (and
> with open social we'll have the infinitely more robust appdata to rely
> on).
> The parent site may store / read cookies to implement setprefs and
> appdata,
> but actual cookie interaction is intentionally not a part of the gadget
> spec
> for these reasons.
>
> ~Kevin
>
> On Jan 23, 2008 9:57 AM, Cassie <do...@apache.org> wrote:
>
> > I was the one who wanted cookies.
> > I disagree that you will never want to save cookies from within the
> > iframe.
> > I need to do it from within the iframe in the sample container (for the
> > state file) and so it seems like we should come up with a clean way to
> do
> > this. (I also don't think it is too far fetched that other libraries may
> > need it in the future but we can table that for now)
> >
> > I can of course copy the cookies.js code into the sample container
> > features
> > folder but that is just a gross code duplication issue. Is there a way I
> > can
> > reference the cookies.js file from within the samplecontainer
> feature.xmlas
> > it stands right now?
> >
> > - Cassie
> >
> >
> >
> > On Wed, Jan 23, 2008 at 9:50 AM, John Hjelmstad (JIRA) <ji...@apache.org>
> > wrote:
> >
> > >
> > > [
> > >
> >
> https://issues.apache.org/jira/browse/SHINDIG-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561746#action_12561746
> > ]
> > >
> > > John Hjelmstad commented on SHINDIG-32:
> > > ---------------------------------------
> > >
> > > This was a quick hack used to get the JS Container code in quickly.
> I'll
> > > be removing it over time.
> > >
> > > > cookies.js should not be under a goog. namespace.
> > > > -------------------------------------------------
> > > >
> > > > Key: SHINDIG-32
> > > > URL:
> https://issues.apache.org/jira/browse/SHINDIG-32
> > > > Project: Shindig
> > > > Issue Type: Improvement
> > > > Components: Javascript
> > > > Reporter: Cassie Doll
> > > > Assignee: Kevin Brown
> > > > Original Estimate: 1h
> > > > Remaining Estimate: 1h
> > > >
> > > > The cookies.js file needs to be renamespaced to something else. It
> > would
> > > also be helpful if it was moved into a feature so that other features
> > could
> > > depend on it.
> > >
> > > --
> > > This message is automatically generated by JIRA.
> > > -
> > > You can reply to this email to add a comment to the issue online.
> > >
> > >
> >
>
Re: [jira] Commented: (SHINDIG-32) cookies.js should not be under a goog. namespace.
Posted by Kevin Brown <et...@apache.org>.
opensocial-samplecontainer and opensocial-reference shouldn't be features
either (the feature dependency should be "opensocial-0.6" or "opensocial-0.7",
or whatever we actually have support for), it should be a gadget, and state
should be stored in the parent site. Right now this means you'd have to use
inter frame communication to pass the data, but when/if we get an
SignedDataServlet in place the open social code can use that to just do an
XHR.
You may want to save cookies, but we explicitly don't do it on purpose,
because it's a big security vulnerability. You can never rely on cookies
being available between page renders (on igoogle the domain changes every
time you move a gadget on your page and on orkut the domain changes every
month or so), and when gadgets are cajoled writing cookies will be disabled
completely. Gadget developers are told to use setprefs for storing data (and
with open social we'll have the infinitely more robust appdata to rely on).
The parent site may store / read cookies to implement setprefs and appdata,
but actual cookie interaction is intentionally not a part of the gadget spec
for these reasons.
~Kevin
On Jan 23, 2008 9:57 AM, Cassie <do...@apache.org> wrote:
> I was the one who wanted cookies.
> I disagree that you will never want to save cookies from within the
> iframe.
> I need to do it from within the iframe in the sample container (for the
> state file) and so it seems like we should come up with a clean way to do
> this. (I also don't think it is too far fetched that other libraries may
> need it in the future but we can table that for now)
>
> I can of course copy the cookies.js code into the sample container
> features
> folder but that is just a gross code duplication issue. Is there a way I
> can
> reference the cookies.js file from within the samplecontainer feature.xmlas
> it stands right now?
>
> - Cassie
>
>
>
> On Wed, Jan 23, 2008 at 9:50 AM, John Hjelmstad (JIRA) <ji...@apache.org>
> wrote:
>
> >
> > [
> >
> https://issues.apache.org/jira/browse/SHINDIG-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561746#action_12561746
> ]
> >
> > John Hjelmstad commented on SHINDIG-32:
> > ---------------------------------------
> >
> > This was a quick hack used to get the JS Container code in quickly. I'll
> > be removing it over time.
> >
> > > cookies.js should not be under a goog. namespace.
> > > -------------------------------------------------
> > >
> > > Key: SHINDIG-32
> > > URL: https://issues.apache.org/jira/browse/SHINDIG-32
> > > Project: Shindig
> > > Issue Type: Improvement
> > > Components: Javascript
> > > Reporter: Cassie Doll
> > > Assignee: Kevin Brown
> > > Original Estimate: 1h
> > > Remaining Estimate: 1h
> > >
> > > The cookies.js file needs to be renamespaced to something else. It
> would
> > also be helpful if it was moved into a feature so that other features
> could
> > depend on it.
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
>
Re: [jira] Commented: (SHINDIG-32) cookies.js should not be under a goog. namespace.
Posted by Cassie <do...@apache.org>.
(ps, it says the reporter is Cassie Doll on the issue)
On Wed, Jan 23, 2008 at 9:57 AM, Cassie <do...@apache.org> wrote:
> I was the one who wanted cookies.
> I disagree that you will never want to save cookies from within the
> iframe. I need to do it from within the iframe in the sample container (for
> the state file) and so it seems like we should come up with a clean way to
> do this. (I also don't think it is too far fetched that other libraries may
> need it in the future but we can table that for now)
>
> I can of course copy the cookies.js code into the sample container
> features folder but that is just a gross code duplication issue. Is there a
> way I can reference the cookies.js file from within the samplecontainer
> feature.xml as it stands right now?
>
> - Cassie
>
>
>
>
> On Wed, Jan 23, 2008 at 9:50 AM, John Hjelmstad (JIRA) <ji...@apache.org>
> wrote:
>
> >
> > [
> > https://issues.apache.org/jira/browse/SHINDIG-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561746#action_12561746]
> >
> > John Hjelmstad commented on SHINDIG-32:
> > ---------------------------------------
> >
> > This was a quick hack used to get the JS Container code in quickly. I'll
> > be removing it over time.
> >
> > > cookies.js should not be under a goog. namespace.
> > > -------------------------------------------------
> > >
> > > Key: SHINDIG-32
> > > URL: https://issues.apache.org/jira/browse/SHINDIG-32
> > > Project: Shindig
> > > Issue Type: Improvement
> > > Components: Javascript
> > > Reporter: Cassie Doll
> > > Assignee: Kevin Brown
> > > Original Estimate: 1h
> > > Remaining Estimate: 1h
> > >
> > > The cookies.js file needs to be renamespaced to something else. It
> > would also be helpful if it was moved into a feature so that other features
> > could depend on it.
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> >
> >
>
Re: [jira] Commented: (SHINDIG-32) cookies.js should not be under a goog. namespace.
Posted by Cassie <do...@apache.org>.
I was the one who wanted cookies.
I disagree that you will never want to save cookies from within the iframe.
I need to do it from within the iframe in the sample container (for the
state file) and so it seems like we should come up with a clean way to do
this. (I also don't think it is too far fetched that other libraries may
need it in the future but we can table that for now)
I can of course copy the cookies.js code into the sample container features
folder but that is just a gross code duplication issue. Is there a way I can
reference the cookies.js file from within the samplecontainer feature.xml as
it stands right now?
- Cassie
On Wed, Jan 23, 2008 at 9:50 AM, John Hjelmstad (JIRA) <ji...@apache.org>
wrote:
>
> [
> https://issues.apache.org/jira/browse/SHINDIG-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561746#action_12561746]
>
> John Hjelmstad commented on SHINDIG-32:
> ---------------------------------------
>
> This was a quick hack used to get the JS Container code in quickly. I'll
> be removing it over time.
>
> > cookies.js should not be under a goog. namespace.
> > -------------------------------------------------
> >
> > Key: SHINDIG-32
> > URL: https://issues.apache.org/jira/browse/SHINDIG-32
> > Project: Shindig
> > Issue Type: Improvement
> > Components: Javascript
> > Reporter: Cassie Doll
> > Assignee: Kevin Brown
> > Original Estimate: 1h
> > Remaining Estimate: 1h
> >
> > The cookies.js file needs to be renamespaced to something else. It would
> also be helpful if it was moved into a feature so that other features could
> depend on it.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
[jira] Commented: (SHINDIG-32) cookies.js should not be under a
goog. namespace.
Posted by "John Hjelmstad (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561746#action_12561746 ]
John Hjelmstad commented on SHINDIG-32:
---------------------------------------
This was a quick hack used to get the JS Container code in quickly. I'll be removing it over time.
> cookies.js should not be under a goog. namespace.
> -------------------------------------------------
>
> Key: SHINDIG-32
> URL: https://issues.apache.org/jira/browse/SHINDIG-32
> Project: Shindig
> Issue Type: Improvement
> Components: Javascript
> Reporter: Cassie Doll
> Assignee: Kevin Brown
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The cookies.js file needs to be renamespaced to something else. It would also be helpful if it was moved into a feature so that other features could depend on it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SHINDIG-32) cookies.js should not be under a
goog. namespace.
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Brown reassigned SHINDIG-32:
----------------------------------
Assignee: (was: Kevin Brown)
> cookies.js should not be under a goog. namespace.
> -------------------------------------------------
>
> Key: SHINDIG-32
> URL: https://issues.apache.org/jira/browse/SHINDIG-32
> Project: Shindig
> Issue Type: Improvement
> Components: Javascript
> Reporter: Cassie Doll
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The cookies.js file needs to be renamespaced to something else. It would also be helpful if it was moved into a feature so that other features could depend on it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-32) cookies.js should not be under a
goog. namespace.
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561667#action_12561667 ]
Kevin Brown commented on SHINDIG-32:
------------------------------------
Yes on fixing the naming (assuming that we're keeping this file in the reference container), but no on making it a feature (except possibly as a container-only feature, even though shindig doesn't support serving container javascript in the in memory container). Cookies should never be saved on the generated iframes. I'm not really sure who was responsible for this file in the first place.
> cookies.js should not be under a goog. namespace.
> -------------------------------------------------
>
> Key: SHINDIG-32
> URL: https://issues.apache.org/jira/browse/SHINDIG-32
> Project: Shindig
> Issue Type: Improvement
> Components: Javascript
> Reporter: Cassie Doll
> Assignee: Kevin Brown
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The cookies.js file needs to be renamespaced to something else. It would also be helpful if it was moved into a feature so that other features could depend on it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.