Re: CORS performance
+1 to Anne's suggestion. The current design is pretty terrible for API performance. I think a request to / with OPTIONS or something, with a response that requires some server side logic (like return the random number UA just sent) is pretty darn secure. cheers dev On 17 February 2015 at 11:24, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Feb 17, 2015 at 8:18 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: Individual resources should not be able to declare policy for the whole server, ... With HSTS we gave up on that. HTTP/1.1 rather has `OPTIONS *` for that, which would require a new kind of preflight request. And if the whole server is fine with cross-origin requests, I am not sure there is much of a point trying to lock it down by restricting request headers or methods. Yeah, I wasn't sure whether those should all be listed. Maybe simply declaring you're fluent in CORS in a unique way is sufficient. -- https://annevankesteren.nl/
Re: Security use cases for packaging
Maybe the code from the downloaded package has to be run from a local origin like chrome://*. Doesn't the same issue that Chris raised still exist? You need a unit of isolation that says only code signed with this public key runs in this isolation compartment. Chrome extensions have that model. Whether we achieve this via origins, COWLs, or origin+key as the identifier, is a separate question, but Chris' high level bit remains true. cheers dev
Re: A URL API
If you really don't want to care what happened before, either do a clearParameter every time first, or define your own setParameter that just clears then appends. Append/clear is a cleaner API design in general imo, precisely because you don't have to worry about colliding with previous activity by default. A set/clear pair means that you have to explicitly check for existing data and handle it in a way that isn't completely trivial. I am not saying remove append - I am saying that just also have set, with the semantics that if you use set, its equivalent to clear;append Attempting to relegate same-name params to second-tier status isn't a good idea. It's very useful for far more than the old services that are also accessed via basic HTML forms that you stated earlier. I am not sure about that - I think a modern API design would be to just send multiple values as an array (maybe CSV or TSV). Consider how JSON values are encoded - do you have multiple values to denote arrays? neither is this the case in XML (afaik). This semantic of multiple yet different values for the same parameter is just confusing, and as you said a mess for server side. I am less optimistic than you are that it will be fixed. cheers devdtta ~TJ
Re: A URL API
2) I've added two flavors of appendParameter. The first flavor takes a DOMString for a value and appends a single parameter. The second flavor takes an array of DOMStrings and appends one parameter for each array. This seemed better than using a variable number of arguments. -1 I really want the setParameter method - appendParameter now requires the developer to know what someone might have done in the past with the URL object. this can be a cause of trouble as the web application might do something that the developer doesn't expect , so I specifically want the developer to opt-in to using appendParameters. I know clearParameter is a method - but this is not the clear separation between the '2 APIs' that we talked about earlier in the thread. I remember reading about how some web application frameworks combine ?q=aq=b to q=ab at the server side, whereas some will only consider q=a and some will only consider q=b. This is such a mess - the developer should have to specifically opt-in to this. cheers devdatta 3) I've added a clearParameter method. Defining these methods required some low-level URL manipulation that's not actually defined anywhere (AFAIK), so I've added a reference to my work-in-progress draft about parsing and canonicalizing URLs. Adam On Tue, Sep 21, 2010 at 3:40 PM, Ojan Vafai o...@chromium.org wrote: appendParameter/clearParameter seems fine to me. On Wed, Sep 22, 2010 at 2:53 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Sep 20, 2010 at 11:56 PM, Adam Barth w...@adambarth.com wrote: Ok. I'm sold on having an API for constructing query parameters. Thoughts on what it should look like? Here's what jQuery does: http://api.jquery.com/jQuery.get/ Essentially, you supply a JSON object containing the parameters. They also have some magical syntax for specifying multiple instances of the same parameter name. I like the easy of supplying a JSON object, but I'm not in love with the magical syntax. An alternative is to use two APIs, like we current have for reading the parameter values. jQuery's syntax isn't magical - the example they give using the query param name of 'choices[]' is doing that because PHP requires a [] at the end of the query param name to signal it that you want multiple values. It's opaque, though - you could just as easily have left off the '[]' and it would have worked the same. The switch is just whether you pass an array or a string (maybe they support numbers too?). I recommend the method be called append*, so you can use it both for first sets and later additions (this is particularly useful if you're just looping through some data). This obviously would then need a clear functionality as well. ~TJ
Re: A URL API
or any webservice that likes to have lots of query parameters - Google Search for example. In general, why would you not want a robust way to make complicated queries - those who are making simple queries and prefer simple one liners can continue using it. On 20 September 2010 23:42, Darin Fisher da...@chromium.org wrote: On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 9/20/10, Julian Reschke julian.resc...@gmx.de wrote: On 20.09.2010 18:56, Garrett Smith wrote: [...] Requests that don't have lot of parameters are often simple one-liners: url = /getShipping/?zip= + zip + pid= + pid; That's exactly the kind of code that will fail once pid and zip contain things you don't expecz. What XHRs have complicated URL with a lot of query parameters? What XHRs? IOW, what are the cases where an XHR instance wants to use a lot o query params? Probably when speaking to a HTTP server designed to take input from an HTML form. -Darin
Re: A URL API
+1 for 2 APIs - this whole multiple parameters with the same value is too annoying imho and unnecessary for new web services . It should be there only for old services that are also accessed via basic HTML forms cheers devdatta On 20 September 2010 23:56, Adam Barth w...@adambarth.com wrote: Ok. I'm sold on having an API for constructing query parameters. Thoughts on what it should look like? Here's what jQuery does: http://api.jquery.com/jQuery.get/ Essentially, you supply a JSON object containing the parameters. They also have some magical syntax for specifying multiple instances of the same parameter name. I like the easy of supplying a JSON object, but I'm not in love with the magical syntax. An alternative is to use two APIs, like we current have for reading the parameter values. Adam On Mon, Sep 20, 2010 at 11:47 PM, Devdatta Akhawe dev.akh...@gmail.com wrote: or any webservice that likes to have lots of query parameters - Google Search for example. In general, why would you not want a robust way to make complicated queries - those who are making simple queries and prefer simple one liners can continue using it. On 20 September 2010 23:42, Darin Fisher da...@chromium.org wrote: On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 9/20/10, Julian Reschke julian.resc...@gmx.de wrote: On 20.09.2010 18:56, Garrett Smith wrote: [...] Requests that don't have lot of parameters are often simple one-liners: url = /getShipping/?zip= + zip + pid= + pid; That's exactly the kind of code that will fail once pid and zip contain things you don't expecz. What XHRs have complicated URL with a lot of query parameters? What XHRs? IOW, what are the cases where an XHR instance wants to use a lot o query params? Probably when speaking to a HTTP server designed to take input from an HTML form. -Darin
Re: A URL API
On 21 September 2010 00:47, Ojan Vafai o...@chromium.org wrote: How about setParameter(name, value...) that takes var_args number of values? Alternately, it could take either a DOMString or an ArrayDOMString for the value. I prefer the var_args. What happens when I do setParameter('x','a','b','c'); and now want to add another - I will have to do weird things like getting the parameter via getAllParameter and then append to the array and function.call or something like that doesn't look very nice according to me - I like the separation into 2 APIs because I think that makes the common case of single parameter values clean and robust cheers devdatta Also, getParameterByName and getAllParametersByName seem unnecessarily wordy. How about getParameter/getParameterAll to match querySelector/querySelectorAll? Putting All at the end is admittedly awkward, but this is the uncommon case, so I'm OK with it for making the common case less wordy. Ojan On Tue, Sep 21, 2010 at 4:56 PM, Adam Barth w...@adambarth.com wrote: Ok. I'm sold on having an API for constructing query parameters. Thoughts on what it should look like? Here's what jQuery does: http://api.jquery.com/jQuery.get/ Essentially, you supply a JSON object containing the parameters. They also have some magical syntax for specifying multiple instances of the same parameter name. I like the easy of supplying a JSON object, but I'm not in love with the magical syntax. An alternative is to use two APIs, like we current have for reading the parameter values. Adam On Mon, Sep 20, 2010 at 11:47 PM, Devdatta Akhawe dev.akh...@gmail.com wrote: or any webservice that likes to have lots of query parameters - Google Search for example. In general, why would you not want a robust way to make complicated queries - those who are making simple queries and prefer simple one liners can continue using it. On 20 September 2010 23:42, Darin Fisher da...@chromium.org wrote: On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 9/20/10, Julian Reschke julian.resc...@gmx.de wrote: On 20.09.2010 18:56, Garrett Smith wrote: [...] Requests that don't have lot of parameters are often simple one-liners: url = /getShipping/?zip= + zip + pid= + pid; That's exactly the kind of code that will fail once pid and zip contain things you don't expecz. What XHRs have complicated URL with a lot of query parameters? What XHRs? IOW, what are the cases where an XHR instance wants to use a lot o query params? Probably when speaking to a HTTP server designed to take input from an HTML form. -Darin
Re: A URL API
Perhaps appendParameter(x, a, b, c) ? where appendParameter is the second API - separate from setParameter? so appendParmeter(x',a,b,c); setParameter(x,a) would result in ?x=a and without the second function call it would be ?x=ax=bx=c I am fine with this. cheers devdatta Adam
Re: A URL API
hi Is the word 'hash' for fragment identifiers common? I personally prefer the attribute being called 'fragment' or 'fragmentID' over 'hash' - its the standard afaik in all the RFCs. regards devdatta On 19 September 2010 15:47, João Eiras joao.ei...@gmail.com wrote: That would be different behavior than what Location and HTMLAnchorElement do; they unescape various componenents. Is the benefit worth the divergence? As a side note, an out-of-document HTMLAnchorElement already provides most of the functionality of this interface. Things it can't do: - Resolve a relative URL against no base at all (probably not very useful since the interface can only represent an absolute URL). - Resolve against an arbitrary base (maybe you could do it awkwardly using base tag tricks). - Read or write the lastPathComponent or origin without further parsing (should origin really be writable? That's kind of weird...) - Read search parameters conveniently without parsing. It might be nice to provide the parts of this that make sense on HTMLAnchorElement and Location, then see if a new interface really pulls its weight. I idea too. I would rather extend Location to include these features, so they would be immediately available in links and the location object. And make Location into a constructor new Location(url, base)
Re: A URL API
1) There are now two methods for getting at the URL parameters. The and none for setting them? cheers devdatta 2) The origin attribute is now readonly. Once I wired up the origin attribute to the actual definition of how to compute the origin of a URL, it became obvious that we don't want to support assigning to the attribute. In particular, it doesn't seems particularly meaningful to assign the string null to the attribute even though that's a perfectly reasonable value for the attribute to return. 3) I've added definitions for what the interface actually does. In response to folks who think we should add these APIs to HTMLAnchorElement and Location, I agree. Currently, the draft is written to refer to HTML5 for the definitions of the common elements, but we could easily reverse that dependency or incorporate this API into HTML5. Adam
Re: A URL API
hi You mean you didn't mention that I drafted a much better one over two years ago? Garrett : could you send a link to your ES4 draft/proposal ? My simple google skills couldn't find it. thanks devdatta And you felt this API was worth mentioning? My criticism is spot-on and appropriate. Cursory, dismissive and thoughtless replies are as inappropriate and counterproductive as flippant messages I'm seeing in my inbox. And I'm not about to be pigeonholed or scapegoated into being the bad guy here. Make sense? That said, Garrett's right. My arguments are supported by the reasons that I provided; nothing more, nothing less. Garrett
[cors] Protecting benign but buggy client side code
Hi The CORS specification in its current form seems to be very concerned about increasing attack surface of benign servers (the preflight request etc. concern). Seeing [1] I am concerned about the other case - benign clients and malicious cross origin servers. for the tl;dr crowd - my (possibly wrong) summary of the attack facebook.com loads content using the stuff after a '#' in a URL, thus facebook.com/#profile.php loads content from facebook.com/profile.php using XHR. a URL like facebook.com/#evil.com/evil.php , with evil.com configured to AccessControlAllowOrigin * could result in HTML injection. It seems that over here facebook is a benign server that some time in the past assumed that XHR can only be same origin, and with the introduction of cross origin XHR is suddenly vulnerable to XSS. In general, a client needs to 'add' stuff to its js to be safe after the introduction of XHR. This isn't ideal. Regards devdatta [1] http://m-austin.com/blog/?p=19
Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?
Because it's undesirable to prevent the browser from sending cookies on an img request, Why ? I can understand why you can't do it today - but why is this undesirable even for new applications? Ad tracking ? ~devdatta On 7 July 2010 16:11, Charlie Reis cr...@chromium.org wrote: On Wed, Jul 7, 2010 at 4:04 PM, Mark S. Miller erig...@google.com wrote: On Wed, Jul 7, 2010 at 1:09 PM, Charlie Reis cr...@chromium.org wrote: [...] That's unfortunate-- at least for now, that prevents servers from echoing the origin in the Access-Control-Allow-Origin header, so servers cannot host public images that don't taint canvases. The same problem likely exists for other types of requests that might adopt CORS, like fonts, etc. Why would public images or fonts need credentials? Because it's undesirable to prevent the browser from sending cookies on an img request, and the user might have cookies for the image's site. It's typical for the browser to send cookies on such requests, and those are considered a type of credentials by CORS. Charlie I believe the plan is to change HTML5 once CORS is somewhat more stable and use it for various pieces of infrastructure there. At that point we can change img to transmit an Origin header with an origin. We could also decide to change CORS and allow the combination of * and the credentials flag being true. I think * is not too different from echoing back the value of a header. I would second the proposal to allow * with credentials. It seems roughly equivalent to echoing back the Origin header, and it would allow CORS to work on images and other types of requests without changes to HTML5. Thanks, Charlie -- Cheers, --MarkM
Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?
hmm, I think I quoted the wrong part of your email. I wanted to ask why would it be undesirable to make CORS GET requests cookie-less. It seems the argument here is reduction of implementation work. Is this the only one? Note that even AnonXmlHttpRequest intends to make GET requests cookie-less. Regards devdatta I meant undesirable in that it will require much deeper changes to browsers. I wouldn't mind making it possible to request an image or other subresource without cookies, but I don't think there's currently a mechanism for that, is there? And if there's consensus that user agents shouldn't send cookies at all on third party subresources, I'm ok with that, but I imagine there would be pushback on that sort of proposal-- it would likely affect compatibility with existing web sites. I haven't gathered any data on it, though. The benefit to allowing * with credentials is that it lets CORS work with the existing browser request logic for images and other subresources, where cookies are currently sent with the request. Charlie On 7 July 2010 16:11, Charlie Reis cr...@chromium.org wrote: On Wed, Jul 7, 2010 at 4:04 PM, Mark S. Miller erig...@google.com wrote: On Wed, Jul 7, 2010 at 1:09 PM, Charlie Reis cr...@chromium.org wrote: [...] That's unfortunate-- at least for now, that prevents servers from echoing the origin in the Access-Control-Allow-Origin header, so servers cannot host public images that don't taint canvases. The same problem likely exists for other types of requests that might adopt CORS, like fonts, etc. Why would public images or fonts need credentials? Because it's undesirable to prevent the browser from sending cookies on an img request, and the user might have cookies for the image's site. It's typical for the browser to send cookies on such requests, and those are considered a type of credentials by CORS. Charlie I believe the plan is to change HTML5 once CORS is somewhat more stable and use it for various pieces of infrastructure there. At that point we can change img to transmit an Origin header with an origin. We could also decide to change CORS and allow the combination of * and the credentials flag being true. I think * is not too different from echoing back the value of a header. I would second the proposal to allow * with credentials. It seems roughly equivalent to echoing back the Origin header, and it would allow CORS to work on images and other types of requests without changes to HTML5. Thanks, Charlie -- Cheers, --MarkM
Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?
It's not just implementation effort-- as I mentioned, it's potentially a compatibility question. If you are proposing not sending cookies on any cross-origin images (or other potential candidates for CORS), do you have any data about which sites that might affect? Its not clear to me on how it would affect sites. It would be like the user cleared his cache and made a request. regards devdatta Personally, I would love to see cross-origin subresource requests change to not using cookies, but that could break existing web sites that include subresources from partner sites, etc. Is there a proposal or discussion about this somewhere? In the mean time, the canvas tainting example in the spec seems difficult to achieve. Charlie On Wed, Jul 7, 2010 at 5:05 PM, Devdatta Akhawe dev.akh...@gmail.com wrote: hmm, I think I quoted the wrong part of your email. I wanted to ask why would it be undesirable to make CORS GET requests cookie-less. It seems the argument here is reduction of implementation work. Is this the only one? Note that even AnonXmlHttpRequest intends to make GET requests cookie-less. Regards devdatta I meant undesirable in that it will require much deeper changes to browsers. I wouldn't mind making it possible to request an image or other subresource without cookies, but I don't think there's currently a mechanism for that, is there? And if there's consensus that user agents shouldn't send cookies at all on third party subresources, I'm ok with that, but I imagine there would be pushback on that sort of proposal-- it would likely affect compatibility with existing web sites. I haven't gathered any data on it, though. The benefit to allowing * with credentials is that it lets CORS work with the existing browser request logic for images and other subresources, where cookies are currently sent with the request. Charlie On 7 July 2010 16:11, Charlie Reis cr...@chromium.org wrote: On Wed, Jul 7, 2010 at 4:04 PM, Mark S. Miller erig...@google.com wrote: On Wed, Jul 7, 2010 at 1:09 PM, Charlie Reis cr...@chromium.org wrote: [...] That's unfortunate-- at least for now, that prevents servers from echoing the origin in the Access-Control-Allow-Origin header, so servers cannot host public images that don't taint canvases. The same problem likely exists for other types of requests that might adopt CORS, like fonts, etc. Why would public images or fonts need credentials? Because it's undesirable to prevent the browser from sending cookies on an img request, and the user might have cookies for the image's site. It's typical for the browser to send cookies on such requests, and those are considered a type of credentials by CORS. Charlie I believe the plan is to change HTML5 once CORS is somewhat more stable and use it for various pieces of infrastructure there. At that point we can change img to transmit an Origin header with an origin. We could also decide to change CORS and allow the combination of * and the credentials flag being true. I think * is not too different from echoing back the value of a header. I would second the proposal to allow * with credentials. It seems roughly equivalent to echoing back the Origin header, and it would allow CORS to work on images and other types of requests without changes to HTML5. Thanks, Charlie -- Cheers, --MarkM