Jim,

I think you're correct about this to some extent, as cross-domain
protection is likely built into Javascript security.  However, I think
you can construct domain values that are a subset of the page's URL, so
you could set a cookie with a domain of either www.mydomain.com or
mydomain.com, either of which is valid if you're page came from
www.mydomain.com/somepath.  In this example, you should be able to
construct two different cookies with different domain values and the
same key.  So, how does Qooxdoo manage this potential overlap.  In the
traditional request/response architecture, the browser determines which
cookies to send based on the requested page address.  I just wondered
how Qooxdoo retrieves cookies from the browser environment and if it can
handle this type of situation.

Regardless, I'm more concerned about any limitations on the timing of
setting and getting cookie values, as well as the issue with an array of
cookie values versus a single cookie value.  I believe the lack of
support for returning an array of values for a specific cookie key may
be a problem.

Thanks,

   Gene





On Thu, 2009-07-09 at 13:20 -0700, Jim Hunter wrote:

> Please correct me if I am wrong, but you can not set or get a cookie
> for a 'domain' that you are not on. If your URL says
> www.mydomain.com/somepath you can not set or get values for the domain
> www.not_mydomain.com, this violates a number of security constraints
> in the browser. 
> 
> 
> Jim
> 
> 
> On Thu, Jul 9, 2009 at 11:39 AM, Gene Amtower <[email protected]>
> wrote:
> 
>         I haven't looked at this class in Qooxdoo yet, but this
>         discussion raises some questions in my mind that the API doc
>         doesn't address, due mainly to the difference between a
>         client/server code approach and a fully client-side code
>         approach.
>         
>         I've used cookies extensively with the traditional
>         request/response page load approach, allowing info to be
>         passed between successive page displays.  In working with
>         cookies this way, I always had to set cookie objects before
>         any part of the webpage response was sent to the browser to
>         allow the cookie values to be submitted in the response
>         headers, and new cookies were not available in my server-side
>         code until the "next" page request event in my server-side
>         code.  In addition, I always set "path" and "domain" values
>         matching the server URL to identify the cookie's scope to the
>         browser and allow pertinent cookies to be sent as a part of
>         the request object back to the server.  The cookies were
>         available server-side through environment variables that are
>         created during the request phase.
>         
>         Since Qooxdoo code is running at the client end, I suspect
>         many of these constraints don't exist.  Are there any timing
>         limitations to using cookies within the Qooxdoo app code?  Or
>         can they be set at any time and are they available through
>         "get" immediately after creating them through "set"?  
>         
>         What is the impact of using various "domain" or "path" values
>         when setting a cookie within the Qooxdoo app?  Do the "domain"
>         and "path" strings need to match the source URL for the
>         Qooxdoo app page, or do they have less meaning in a client-
>         side implementation like Qooxdoo?
>         
>         Also, I noticed that the "get" method doesn't use anything
>         beyond the "key" value of the cookie.  So, if there's no
>         restriction on the value of the "domain" and "path" parameters
>         when setting a cookie, how is the use of different "domain" or
>         "path" values impacted by the lack of a "domain" or "path"
>         parameter in the "get" method?  In the request/response
>         approach, only one of them would actually be sent in the
>         request based on these cookie parameters.  But in Qooxdoo,
>         what if I set two different cookies with different "domain" or
>         "path" values but the same "key" value?  Which will I get
>         through the "get" method, or does the "set" method
>         implementation prevent two separate cookies being set this
>         way?
>         
>         Finally, I seem to remember that I could create multiple
>         cookies with the same "key" and they would then be returned as
>         an array of values for that "key".  I don't see any support in
>         the qx.bom.Cookie class for anything more than a single
>         key=>value pair.  Do I remember this incorrectly, or is the
>         Qooxdoo qx.bom.Cookie class just not as comprehensive as maybe
>         it could be?
>         
>         Thanks,
>         
>            Gene
>         
>         
>         On Thu, 2009-07-09 at 19:32 +0200, Andreas Ecker wrote: 
>         
>         > Hi,
>         > 
>         > qx.bom.Cookie is rather a thin convenience wrapper for regular 
> cookie
>         > handling in the browser. So there isn't all too much to document. 
> See
>         > the API viewer for a short  documentation of its 3 methods get, set,
>         > del:
>         > http://demo.qooxdoo.org/devel/apiviewer/index.html#qx.bom.Cookie
>         > 
>         > Additionally, any documentation of cookie handling in browsers 
> should
>         > get you started,
>         > 
>         > Andreas
>         > 
>         > 
>         > 
>         > 
>         > On Thu, 2009-07-09 at 15:30 +0200, Martin Wittemann wrote:
>         > > Hello Narasimha,
>         > > 
>         > > Yes, it would be the best way to use the qx.bom.Cookie class for 
> such  
>         > > a requirement. But im sorry, we don't have a written 
> documentation.  
>         > > The only thin I can offer are some unit tests [1] and a demo [2]. 
>  
>         > > Thats all we have currently. I hope that helps a litte.
>         > > 
>         > > Best,
>         > > Martin
>         > > 
>         > > [1] 
> http://qooxdoo.svn.sourceforge.net/viewvc/qooxdoo/trunk/qooxdoo/framework/source/class/qx/test/bom/Cookie.js?revision=18626&view=markup
>         > > 
>         > > [2] 
> http://qooxdoo.svn.sourceforge.net/viewvc/qooxdoo/trunk/qooxdoo/application/demobrowser/source/class/demobrowser/demo/bom/Cookie.js?revision=17234&view=markup
>         > > 
>         > > 
>         > > Am 09.07.2009 um 13:31 schrieb patkar_n001:
>         > > 
>         > > >
>         > > > Hi,
>         > > >
>         > > > In our Qooxdoo application, we want to share data among 
> different  
>         > > > javascript
>         > > > pages. We want to set variables on a button click of a page and 
> these
>         > > > variables should be accessible by other pages.
>         > > >
>         > > > We have thought of using the Cookies for achieving this. Please 
> let  
>         > > > me know
>         > > > if there is a better way of handling this in Qooxdoo. Also the  
>         > > > requirement
>         > > > is that if we refresh the page the variables should retain the 
> values.
>         > > >
>         > > > There is a class available in Qooxdoo qx.bom.Cookie, if you can 
>  
>         > > > point to
>         > > > some documentation, that will be great help.
>         > > >
>         > > > Warm regards,
>         > > > Narasimha
>         > 
>         > 
>         > 
>         > 
>         > 
> ------------------------------------------------------------------------------
>         > Enter the BlackBerry Developer Challenge  
>         > This is your chance to win up to $100,000 in prizes! For a limited 
> time, 
>         > vendors submitting new applications to BlackBerry App World(TM) 
> will have
>         > the opportunity to enter the BlackBerry Developer Challenge. See 
> full prize  
>         > details at: http://p.sf.net/sfu/Challenge
>         > _______________________________________________
>         > qooxdoo-devel mailing list
>         > [email protected]
>         > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>         
>         
>         
> ------------------------------------------------------------------------------
>         Enter the BlackBerry Developer Challenge
>         This is your chance to win up to $100,000 in prizes! For a
>         limited time,
>         vendors submitting new applications to BlackBerry App World
>         (TM) will have
>         the opportunity to enter the BlackBerry Developer Challenge.
>         See full prize
>         details at: http://p.sf.net/sfu/Challenge
>         _______________________________________________
>         qooxdoo-devel mailing list
>         [email protected]
>         https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>         
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________ qooxdoo-devel mailing list 
> [email protected] 
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to