Seeing some odd behaviour in Chrome, and not sure if it's expected behaviour when using appcache, or just Chrome.
It's a single-page app, powered by our RestAPI, it works fine when the RestAPI is being requested under HTTP, however as soon as we change the url to be the HTTPS version then it stops working. There's not a lot (i.e. any) information in Chrome's console as to why it decides to stop working.
We've managed to narrow it down to the NETWORK section in the appcache file, the only way we can get it to work is to use the * wildcard, which we don't want to do, as that bypasses the whole point of the appcache, and reduces security (from my understanding from reading the docs etc).
We've tried any and all variations of the API url (as in combinations of it with wildcards in various relevant locations), but none seem to work (even a https://* doesn't allow a successful request).
Any experienced know what's going on at all?
Thanks
Need a bit of clarification (see my comment), but in the meantime:
The NETWORK behaviour of the manifest is really there to, according to the spec, make "the testing of offline applications simpler", by reducing the difference between online and offline behaviour. In reality, it just adds another gotcha.
By default, anything that isn't explicitly in the manifest (listed in the manifest file), implicitly part of the cache (a visited page that points to the manifest), or covered by a FALLBACK prefix, will fail to load, even if you're online, unless the url is listed in the NETWORK section or the NETWORK section lists *.
Wildcards don't have special meaning in the NETWORK section, if you list http://whatever.com/* it will allow requests to that url, as an asterisk is a valid character in a url. The only special case is a single *, which means "allow the page to make network requests for any resources that aren't in the cache".
Basically, using * in NETWORK isn't a security risk, in fact it's probably what you want to do, every AppCache site I've built uses it.
I drew this flow chart to try and explain how appcache loads pages and resources:
Related
I'm referring to the "Internal UUID" value that's visible in about:debugging, which is different from the extension ID that is specified in manifest.json for web extensions.
In my testing, this is a different value for each installation of the addon.
I'd like to set this to a predictable value because it is used as the origin (e.g. moz-extension://guid) for communication APIs like postMessage. It'd be a good indicator for whether a message received by a web app is from an authorized extension vs. some other extension or page.
In Chrome, the origin seems to be stable across different installations of an extension, so I'd like to see if it's possible to achieve the same thing with Firefox.
The internal UUID is deliberately created per installation of an extension, to avoid fingerprinting, you can see a longer discussion at https://bugzil.la/1372288
However, I think you're misunderstanding the purpose of the Origin header, it lets your web app and browser work together to prevent a class of cross-site scripting attacks. But by itself, it doesn't really give your web app a reliable indicator of the origin of the request (that is, any non-browser client can easily construct an HTTP request with an arbitrary value in the Origin header)
I'm developing a Google Sheets add-on. The add-on calls an API. In the API configuration, a url like https://longString-script.googleusercontent.com had to be added to the list of urls allowed to make requests from another domain.
Today, I noticed that this url changed to https://sameLongString-0lu-script.googleusercontent.com.
The url changed about 3 months after development start.
I'm wondering what makes the url to change because it also means a change in configuration in our back-end every time.
EDIT: Thanks for both your responses so far. Helped me understand better how this works but I still don't know if/when/how/why the url is going to change.
Quick update, the changing part of the url was "-1lu" for another user today (but not for me when I was testing). It's quite annoying since we can't use wildcards in the google dev console redirect uri field. Am I supposed to paste a lot of "-xlu" uris with x from 1 to like 10 so I don't have to touch this for a while?
For people coming across this now, we've also just encountered this issue while developing a Google Add-on. We've needed to add multiple origin urls to our oauth client for sign-in, following the longString-#lu-script.googleusercontent.com pattern mentioned by OP.
This is annoying as each url has to be entered separately in the authorized urls field (subdomain or wildcard matching isn't allowed). Also this is pretty fragile since it breaks if Google changes the urls they're hosting our add-on from. Furthermore I wasn't able to find any documentation from Google confirming that these are the script origins.
URLs are managed by the host in various ways. At the most basic level, when you build a web server you decide what to call it and what to call any pages on it. Google and other large content providers with farms of servers and redundant data centers and everything are going to manage it a bit differently, but for your purposes, it will be effectively the same in that ... you need to ask them since they are the hosting provider of your cloud content.
Something that MIGHT be related is that Google rolled out some changes recently dealing with the googleusercontent.com domain and picassa images (or at least was scheduled to do so.) So the google support forums will be the way to go with this question for the freshest answers since the cause of a URL change is usually going to be specific to that moment in time and not something that you necessarily need to worry about changing repeatedly. But again, they are going to need to confirm that it was something related to the recent planned changes... or not. :-)
When you find something out you can update this question in case it is of use to others. Especially, if they tell you that it wasn't a one time thing dealing with a change on their end.
This is more likely related to Changing origin in Same-origin Policy. As discussed:
A page may change its own origin with some limitations. A script can set the value of document.domain to its current domain or a superdomain of its current domain. If it sets it to a superdomain of its current domain, the shorter domain is used for subsequent origin checks.
For example, assume a script in the document at http://store.company.com/dir/other.html executes the following statement:
document.domain = "company.com";
After that statement executes, the page can pass the origin check with http://company.com/dir/page.html
So, as noted:
When using document.domain to allow a subdomain to access its parent securely, you need to set document.domain to the same value in both the parent domain and the subdomain. This is necessary even if doing so is simply setting the parent domain back to its original value. Failure to do this may result in permission errors.
If I include in my application cache manifest:
/example.html
and this redirects to
https://s3.amazonaws.com/longURL/example.html?dynamicauthenticationparameters
will this work?
The current draft HTML5 specification seems to be silent on redirects for content files (as opposed to the manifest itself) apart from referring to a manual redirect flag, which apparently is set but (as far as I can tell) never actually used.
(The intention is to avoid proxying some S3 content, but to still make it available offline using the cache mechanism. JavaScript and LocalStorage would presumably be a workaround if the above can't be done).
Any pointers to the relevant part of a spec and/or current browser implementation behavior would be helpful.
The current specification now states that if the resource is redirected to a different origin, then this is treated as a failure and the local cached copy (or fallback) is used instead.
In section 5.6.4 of http://www.w3.org/TR/2011/WD-html5-20110525/offline.html it states that:
Redirects are fatal because they are either indicative of a network
problem (e.g. a captive portal); or would allow resources to be added
to the cache under URLs that differ from any URL that the networking
model will allow access to, leaving orphan entries; or would allow
resources to be stored under URLs different than their true URLs. All
of these situations are bad.
So sadly you can't serve some pages from Amazon S3 or Cloudfront.
I'm writing an application, which becomes "useful" once user is browsing certain url.
I want to add feature to my application, that it will be automatically launched once user browses this url, I was thinking of writing some sort of watchdog to trigger it.
My question is, whether there is a generic way to get notified when user browses to urls, I want to support at least IE and FireFox, chrome and safari is nice to have.
I read about DDE and WWW_RegisterURLEcho, but from what I understand it's not supported by FireFox, and also little sample I wrote didn't work with IE as well.
Thank you in advance
some more questions **
Do Url Monikers and Asynchronous Pluggable Protocols help me here ? Is it supported by FireFox ?
If you have control over the website, you could have it write a cookie to the computer. Then have your application monitor for that cookie.
You can implement this in many ways and at many different layers.
At the highest level, you could implement a browser plugin. There is no cross-browser solution at this layer that will let you write the code once and work for every browser. On the easy end of the spectrum, Firefox, you could implement it entirely as a Javascript + XUL plugin and use built-in XPCom interfaces (nsIProcess) for launching your helper process. For IE you would need to write a COM, C++ and win32 BHO that handles DWebBrowserEvents2::BeforeNavigate2. This is the hardest thing to do. There are mechanisms for Safari, Chrome and other webbrowsers that you could use to achieve this same behavior, with varying degrees of difficulty.
At the next level you could implement an HTTP proxy, similar to Fiddler2, that redirects all HTTP traffic through your local proxy first. Each browser has a different way of configuring its proxy settings, but they're all basically registry settings or config files.
At the most basic level you could just snif all IP traffic going out of the machine, similar to the way Wireshark does it, and just look for http requests to your URL. This is probably more difficult to code, but would work for all browsers without any special per-browser configuration stuff going on. You may need to write a driver. I dunno, I've never done work at this level in the stack.
I am designing a web application which is a tie in to my iPhone application. It sends massively large URLs to the web server (15000 about.) I was using NearlyFreeSpeech.net, but they only support URLS up to 2000 characters. I was wondering if anybody knows of web hosting that will support really large URLs? Thanks, Isaac
Edit: My program needs to open a picture in Safari. I could do this 2 ways:
send it base64 encoded in the URL and just echo the query parameters.
first POST it to the server in my application, then the server would send back a unique ID after storing the photo in a database, which I would append to a URL which I would open in Safari which retrieved the photo from the database and delete it from the database.
You see, I am lazy, and I know Mobile Safari can support URI's up to 80 000 characters, so I think this is a OK way to do it. If there is something really wrong with this, please tell me.
Edit: I ended up doing it the proper POST way. Thanks.
If you're sending 15,000 character long URLs, in all likelyhood:
alt text http://img16.imageshack.us/img16/3847/youredoingitwronga.jpg
Use something like an HTTP POST instead.
The limitations you're running up against aren't so much an issue with the hosts - it's more the fact that web servers have a limit for the length of a URL. According to this page, Apache limits you to around 4k characters, and IIS limits you to 16k by default.
Although it's not directly answering your question, and there is no official maximum length of a URL, browsers and servers have practical limits - see http://www.boutell.com/newfaq/misc/urllength.html for some details. In short, since IE (at least some versions in use) doesn't support URLs over 2,083 characters, it's probably wise to stay below that length.
If you need to just open it in Safari, and the server doesn't need to be involved, why not use a data: URI?
Sending long URIs over the network is basically never the right thing to do. As you noticed, some web hosts don't support long URIs. Some proxy servers may also choke on long URLs, which means that your app might not work for users who are behind those proxies. If you ever need to port your app to a different browser, other browsers may not support URIs that long.
If you need to get data up to a server, use a POST. Yes, it's an extra round trip, but it will be much more reliable.
Also, if you are uploading data to the server using a GET request, then you are vulnerable to all kinds of cross-site request forgery attacks; basically, an attacker can trick the user into uploading, say, goatse to their account simply by getting them to click on a link (perhaps hidden by TinyURL or another URL shortening service, or just embedded as a link in a web page when they don't look closely at the URL they're clicking on).
You should never use GET for sending data to the server, beyond query parameters that don't actually change anything on the server.