The way it works is:
* On a privileged app manifest (it has to be privileged, otherwise it doesn't work) set a redirects key. * The "from" is the complete URI you want to intercept. Let's call this URI_A * The "to" is a relative URI (relative to the app) you want it redirected to. Let's call this REL_URI_B * When the app opens a URI that returns a 302 URI_A, it will be intercepted and app://yourapp/REL_URI_B will be loaded instead. * Any other type of access to URI_A (document.location.href=URI_A for example) will *not* be intercepted. Best, Antonio On 02/07/2013 21:27, Michael Bishop wrote: Maybe I'm thinking about this wrong. I'd thought that in the "redirects" manifest entry, the "from" references the web-page that has been requested to be opened and that it doesn't need to actually exist because within the app instance, it is now aliased to the "to" entry. So, when the app loads http://MichaelPro.local/~mbishop/index.html, and the server at MichaelPro.local asks it to redirect to the "from" entry, I've been expecting the app to open the "to" entry. Is that not the case then? Is there some sample code that shows how this works? _ michael On Tuesday, July 2, 2013 at 13:52 PM, Fabrice Desre wrote: I think that we still consider http://MichaelPro.local/~mbishop/index.html as the redirection source, hence failing to match. Fabrice On 07/02/2013 10:34 AM, Michael Bishop wrote: Oops. That's a good catch. I changed that and checked it in. I was really hoping that was the issue but the behavior is still the same. Darn! I've filed a bug for this: https://bugzilla.mozilla.org/show_bug.cgi?id=889356 _ michael On Tuesday, July 2, 2013 at 13:27 PM, Fabrice Desre wrote: On 07/02/2013 08:18 AM, Michael Bishop wrote: This is very strange. I set up a local web server and made sure it correctly redirected to the page specified in the "redirects" manifest entry. Still no dice. So, hitting the "redirect" button will open up the address: http://MichaelPro.local/~mbishop/index.html curl returns this for that address… HTTP/1.1 302 Found Date: Tue, 02 Jul 2013 15:09:36 GMT Server: Apache/2.2.22 (Unix) DAV/2 mod_ssl/2.2.22 OpenSSL/0.9.8x Location: http://firefoxos.non-existent-domain-asdfg.com/authenticated.html Content-Type: text/html; charset=iso-8859-1 So, I'm expecting the app to then attempt to open http://firefoxos.non-existent-domain-asdfg.com/authenticated.html Which is listed in the manifest as: "redirects": [ {"from": "https://firefoxos.test-oauth.non-existent-domain-asdfg.com/authenticated.html";<https://firefoxos.test-oauth.non-existent-domain-asdfg.com/authenticated.html>, "to": "/redirects/authenticated.html"} ] And then I'm expecting the app to redirect to: /redirects/authenticated.html Instead, I get that "about:// is not loading properly"<about://isnotloadingproperly> A difference this time is that the header in the app shows (pardon my ascii graphic): [x] | http://michaelpro.local So that has changed. Is there a better way for me to test this or is something really wrong? Your redirect is declared for https://XXX but you load http://XXX. That doesn't match. Fabrice -- Fabrice Desré b2g team Mozilla Corporation -- Fabrice Desré b2g team Mozilla Corporation _______________________________________________ dev-b2g mailing list [email protected]<mailto:[email protected]> https://lists.mozilla.org/listinfo/dev-b2g ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
