From a065e04d529da1d847b5062a12c46d916408bf32 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 21:46:22 -0500 Subject: update based on https://github.com/mdn/yari/issues/2028 --- .../index.html" | 66 ----- files/es/archive/add-ons/index.html | 8 - .../add-ons/observer_notifications/index.html | 155 ----------- .../index.html" | 54 ---- .../index.html" | 295 --------------------- 5 files changed, 578 deletions(-) delete mode 100644 "files/es/archive/add-ons/api_de_restauraci\303\263n_de_sesi\303\263n/index.html" delete mode 100644 files/es/archive/add-ons/index.html delete mode 100644 files/es/archive/add-ons/observer_notifications/index.html delete mode 100644 "files/es/archive/add-ons/permitir_sugerencias_en_los_plugins_de_b\303\272squeda/index.html" delete mode 100644 "files/es/archive/add-ons/versionado,_actualizaci\303\263n_y_compatibilidad_de_extensiones/index.html" (limited to 'files/es/archive/add-ons') diff --git "a/files/es/archive/add-ons/api_de_restauraci\303\263n_de_sesi\303\263n/index.html" "b/files/es/archive/add-ons/api_de_restauraci\303\263n_de_sesi\303\263n/index.html" deleted file mode 100644 index 237857bc2e..0000000000 --- "a/files/es/archive/add-ons/api_de_restauraci\303\263n_de_sesi\303\263n/index.html" +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: API de restauración de sesión -slug: Archive/Add-ons/API_de_restauración_de_sesión -tags: - - Complementos - - NecesitaRevisiónTécnica - - Todas_las_Categorías - - extensiones -translation_of: Archive/Add-ons/Session_store_API ---- -

Firefox 2 introduce el almacenamiento de sesiones, una nueva caracteristica que hace posible que las extensiones puedan fácilmente, guardar y restaurar datos a lo largo de sesiones de Firefox. Existe una API simple que permite que las extensiones accedan a la caracterìstica de almacenamiento de sesión.

-

Un escenario clave en el cual proveer esta caracteristica puede ser crucial para una extensión: Firefox 2 deja revertir el cerrado de pestañas. Para poder restaurar correctamente el estado de la extension cuando una pestaña es restaurada, necesita usar el metodo setTabValue() de la API de almacenamiento de sesion, para guardar la informaciòn que necesitarà para restaurar su estado, y luego invocar getTabValue() para obtener la configuraciòn previa cuando la pestaña es recuperada.

-

La API Almacenamiento de Sesion es implementada usando la interfaz nsISessionStore

-

Saber cuando restaurar

-

Cada vez que Firefox està por restaurar una pestaña, un evento de tipo SSTabRestoring es enviado. Si se quiere que la extensión sea capaz de restaurar los datos cuando las pestañas son restauradas, puede instalar un "centinela" como este:

-
function myExtensionHandleRestore(aEvent) {
-  Components.classes["@mozilla.org/consoleservice;1"].
-             getService(Components.interfaces.nsIConsoleService).
-             logStringMessage("restoring tabs");
-};
-
-document.addEventListener("SSTabRestoring", myExtensionHandleRestore, false);
-
-

Simplemente se debe reemplazar los contenidos de la función myExtensionHandleRestore() con cualquier cosa que se necesite hacer cuando la pestaña sea restaurada. En este ejemplo, nsIConsoleService es usado para desplegar un mensaje a la Consola.

-

Este evento es enviado justo antes de la restauracion de una pestaña. Un evento del tipo SSTabRestored es enviado después que la última pestaña ha sido restaurada.

-

El proceso de restauración de sesión

-

La secuencia exacta de eventos que ocurre cuando una sesión està siendo restaurada es:

-
  1. El estado de una sesión está a punto de ser restaurado. Esto puede ser al inicio del programa,o en respuesta a Deshacer Cerrar Pestaña, dado que las pestañas cerradas son restauradas como sesiones de una sola pestaña.
  2. Nuevas ventanas son abiertas como se requirieron (una por cada ventana que fue salvada durante el almacenamiento de sesión), y tanto cookies como la lista de pestañas recièn cerradas son restauradas.
    3. -
-

Después de esto, los siguientes pasos son seguidos por cada pestaña que està siendo restaurada:

-
  1. Se reutiliza una pestaña o se crea una nueva. En el último caso, el evento TabOpen es enviado.
  2. Los atributos persistentes XUL de la pestaña (aquellos que fueron salvados, debido a invocaciones de persistTabAttribute()) y permisos son restaurados.
  3. El evento SSTabRestoring es enviado.
  4. Se le ordena a la pestaña que cargue el URL que deberìa desplegar.
  5. Cuando la página ha terminado de cargar, los campos de texto y barras de desplazamiento son restaurados.
  6. Finalmente, el evento SSTabRestored es enviado.
    7. -
-

Si se quiere configurar permisos o manipular de alguna otra forma  una pestaña restaurada antes de que la página sea cargada, debería observar SSTabRestoring. Si se desea hacer algo después de que la pagina ha sido cargada, debería observar SSTabRestored.

-

Ambos eventos son siempre enviados por cada pestaña que està siendo restaurada. Se puede determinar cual pestaña esta siendo restaurada mirando el campo originalTarget del evento.

-

No existe una forma para determinar cuàndo ha sido restaurada la última pestaña, a menos que se determine cuantas pestañas necesitan ser restauradas y luego contar los eventos sSTabRestored.

-

Usando la API de almacenamiento de sesión

-

Esta sección provee algunos ejemplos de còmo usar la API de almacenamiento de sesión.

-

Guardando un valor con una pestaña.

-

El siguiente código adherirà un par llave/valor a una pestaña, asi-cuando èsta sea restaurada-, este par todavía estará asociada a ella.

-
 var ss = Components.classes["@mozilla.org/browser/sessionstore;1"].
-                             getService(Components.interfaces.nsISessionStore);
- var currentTab = getBrowser().selectedTab;
- var dataToAttach = "Yo quiero adherir esto";
- ss.setTabValue(currentTab, "nombre-llave-aqui", dataToAttach);
-
-

El código asigna el valor de la llave "nombre-llave-aqui" a dataToAttach. Se puede usar cualquier objeto JavaScript como datos.

-

Recuperar un valor guardado

-

Se puede recuperar un valor asociado a una pestaña en cualquier momento (ya sea mientras la pestaña este siendo restaurada o no), usando un código similar al siguiente:

-
 var ss = Components.classes["@mozilla.org/browser/sessionstore;1"].
-                             getService(Components.interfaces.nsISessionStore);
- var currentTab = getBrowser().selectedTab;
- var retrievedData = ss.getTabValue(currentTab, "nombre-llave-aqui");
-
-

Despuès  que el código ha sido ejecutado, la variable retrievedData contiene el valor guardado en la llave "nombre-llave-aqui". retrievedData está indefinida si no existe un valor guardado para ese nombre de llave.

-

Borrando un valor asociado a una pestaña

-

Para borrar un valor de una pestaña, se puede utilizar un código como el siguiente:

-
 var ss = Components.classes["@mozilla.org/browser/sessionstore;1"].
-                             getService(Components.interfaces.nsISessionStore);
- var currentTab = getBrowser().selectedTab;
- deleteTabValue(currentTab, "nombre-llave-aqui");
-
-

Comentarios

-

El guardado de valores de la ventana y las funciones de restauración, funcionan exactamente como las funciones basadas en pestañas con nombres similares.

-

Ver También:

-

nsISessionStore

-

diff --git a/files/es/archive/add-ons/index.html b/files/es/archive/add-ons/index.html deleted file mode 100644 index d1851bd7ee..0000000000 --- a/files/es/archive/add-ons/index.html +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: Add-ons -slug: Archive/Add-ons -translation_of: Archive/Add-ons ---- -

In progress. Archived add-ons documentation.

- -

diff --git a/files/es/archive/add-ons/observer_notifications/index.html b/files/es/archive/add-ons/observer_notifications/index.html deleted file mode 100644 index 571cebc9d4..0000000000 --- a/files/es/archive/add-ons/observer_notifications/index.html +++ /dev/null @@ -1,155 +0,0 @@ ---- -title: Notificaciones Observer -slug: Archive/Add-ons/Observer_Notifications -translation_of: Mozilla/Tech/XPCOM/Observer_Notifications ---- -

-

« AnteriorSiguiente »

-

- -

Sometimes you need your code to send a message to other parts of your code. For example, you might want to notify that a task is completed, and then several different actions must be performed. You could do that by calling all those functions directly, but XPCOM offers you a better and cleaner way to achieve that using observers and the observer service.

- -

An observer is an object that is responsible to observe (wait for) notifications and then to carry out subsequent actions. To create an observer, you need to implement the nsIObserver interface. The interface has only one method observe() which takes three parameters. The first parameter (subject) can be any XPCOM object, the second parameter is a notification topic, and the final parameter is a string that further describes the notification.

- -

This example code shows you what an implementation of the nsIObserver interface looks like:

- -
-
-
let testObserver = {
-  observe : function(aSubject, aTopic, aData) {
-    if (aTopic == "xulschoolhello-test-topic") {
-      window.alert("Data received: " + aData);
-    }
-  }
-}
-
-
- -

In order for this observer to work, you need to use the observer service that provides methods for you to add, remove, notify and enumerate observers.

- -

Adding an observer to the observer service is simple, invoking the addObserver method with three parameters. The first parameter is an observer object, the second parameter is a notification topic, and the third parameter is a boolean which indicates whether the observer service should hold a weak reference to the observer. You should normally set the third parameter to false.

- -
-
-
let observerService = Components.classes["@mozilla.org/observer-service;1"].
-    getService(Components.interfaces.nsIObserverService);
-
-observerService.addObserver(testObserver, "xulschoolhello-test-topic", false);
-
-
- -
-
-
You should come up with a notification topic that is unique so you know it will not conflict with Firefox or other extensions topics.
-
-
- -

To remove an observer for a specific topic, you use the removeObserver method. The method takes the observer object and notification topic as parameters.

- -
-
-
observerService.removeObserver(testObserver, "xulschoolhello-test-topic");
-
-
- -

After you have registered some observers to listen to a notification topic, you can then use the notifyObservers method to send a notification to all of them. The method takes three parameters. The first parameter can be any XPCOM object to pass to those observers (can be null), the second parameter is the notification topic and the last parameter is an additional string to pass to those observers (can be null).

- -
-
-
observerService.notifyObservers(null, "xulschoolhello-test-topic", "hello");
-
-
- -

Non-chrome to chrome communication

- -

Non-chrome to chrome communication is one of the main uses of observers. By non-chrome we mean JavaScript Code Modules or XPCOM. As we saw in previous sections, you can use JavaScript Code Module and XPCOM objects very easily from the chrome. But given that chrome is window-dependent and non-chrome objects are not, it's tricky to send a message to the chrome. You would have to invoke a method for the chrome objects in all windows. It's much easier to use observers in this case.

- -

Let's see the following example code on how to send out a notification from non-chrome code.

- -
-
-
/**
- * Notifies all the registered observers with the test notification topic.
- */
-notifyTest : function() {
-  let observerService = Components.classes["@mozilla.org/observer-service;1"].
-      getService(Components.interfaces.nsIObserverService);
-  let subject = Components.classes["@mozilla.org/supports-string;1"].
-      createInstance(Components.interfaces.nsISupportsString);
-
-  // assign some text to data attribute
-  subject.data = "This is a test.";
-  // notify all registered observers
-  observerService.notifyObservers(
-    subject, "xulschoolhello-test-topic", "hello");
-}
-
-
- -

In the notifyTest method, the notifyObservers call is used to notify all registered observers about the notification topic "xs-hw-test-topic". The input parameter is an instance of nsISupportsString with some text and the last input parameter is a string "Hello".

- -

In a chrome browser overlay file, we register an observer to listen to the notification topic "xs-hw-test-topic" when the window loads. Keep in mind that you have to remove observers that are not longer needed. Not doing so will result in memory leaks. Therefore, the registered observer is unregistered when the browser window is unloaded.

- -
-
-
/**
- * Controls the browser overlay for the Hello World extension.
- */
-XULSchoolChrome.BrowserOverlay = {
-  /* Observer service. */
-  _observerService : null,
-
-  /**
-   * Initializes this object.
-   */
-  init : function() {
-    this._observerService = Components.classes["@mozilla.org/observer-service;1"].
-       getService(Components.interfaces.nsIObserverService);
-    this._observerService.addObserver(this, "xulschoolhello-test-topic", false);
-  },
-
-  /**
-   * Unitializes this object.
-   */
-  uninit : function() {
-    this._observerService.removeObserver(
-      this, "xulschoolhello-test-topic");
-  },
-
-  /**
-   * Observes the registered notification topics.
-   * @param aSubject The nsISupports object associated with the notification.
-   * @param aTopic The notification topic.
-   * @param aData The additional string associated with the notification.
-   */
-  observe : function(aSubject, aTopic, aData) {
-    if (aTopic == "xulschoolhello-test-topic") {
-      aSubject.QueryInterface(Ci.nsISupportsString);
-      window.alert("Subject: " + aSubject.data);  // => "This is a test"
-      window.alert("Data: " + aData);  // => "Hello"
-    }
-  }
-}
-
-window.addEventListener(
-  "load", function() { XULSchoolChrome.BrowserOverlay.init(); }, false);
-window.addEventListener(
-  "unload", function() { XULSchoolChrome.BrowserOverlay.uninit(); }, false);
-
-
- -

In the observe method the notification topic is verified because you can have one observer listening to several topics. You may notice that we explicitly set the interface of the aSubject object to nsISupportsString using the QueryInterface method. This is because the first parameter of the observe method is typed as nsISupports (the generic interface, as seen before), therefore its properties and methods cannot be accessed unless the correct interface is set to it.

- -

When the notifyTest method is called, all observers registered with xulschoolhello-test-topic will get notified and display two alerts. If there are 2 Firefox windows open, the observer will be notified in both and the alerts will show up on both.

- -

You can always listen for multiple notification topics using the same observer. Also, be careful not to add the same observer to a notification topic more than once, otherwise the same code in the observer will be run several times when a notification is sent.

- -

Useful Firefox notifications

- -

We have covered sending and receiving custom notification topics using observers and the observer service. In Firefox, there are many built-in observer topics that you can observe as well. The Observer Notifications page lists some useful topics and is definitely worth spending time studying it.

- -

-

« AnteriorSiguiente »

-

- -

This tutorial was kindly donated to Mozilla by Appcoast.

diff --git "a/files/es/archive/add-ons/permitir_sugerencias_en_los_plugins_de_b\303\272squeda/index.html" "b/files/es/archive/add-ons/permitir_sugerencias_en_los_plugins_de_b\303\272squeda/index.html" deleted file mode 100644 index 7e5d1f33de..0000000000 --- "a/files/es/archive/add-ons/permitir_sugerencias_en_los_plugins_de_b\303\272squeda/index.html" +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: Permitir sugerencias en los plugins de búsqueda -slug: Archive/Add-ons/Permitir_sugerencias_en_los_plugins_de_búsqueda -tags: - - Plugins_de_búsqueda -translation_of: Archive/Add-ons/Supporting_search_suggestions_in_search_plugins ---- -

MozSearch admite sugerencias mientras el usuario escribe el la barra de búsqueda, Firefox 2 pregunta a la URL especificada por el plugins del motor de búsqueda para devolver sugerencias en tiempo real. -

Una vez que se ha obtenido la lista, se muestra en un cuadro emergente que aparece debajo de la barra de búsqueda, que permite al usuario seleccionar un término sugerido. Si el usuario continua escribiendo, se solicita una nueva lista de sugerencias al motor de búsqueda, y se muestra actualizada. -

Los plugins de Yahoo y Google incluidos en Firefox 2 admiten sugerencias de búsqueda. -

-

Implementar soporte para sugerencias en un plugin de búsqueda

-

Para soportar sugerencias, un plugin de búsquedaa necesita definir un elemento extra <Url> con su atributo type definido como "application/x-suggestions+json". (esto significa que los plugins con soporte para sugerencias tendrán dos elementos <Url>, siendo el otro la URL principal text/html.) -

Por ejemplo, el plugin de búsqueda de Yahoo tiene esta <Url>: -

-
<Url type="application/x-suggestions+json" template="http://ff.search.yahoo.com/gossip?output=fxjson&command={searchTerms}"/>
-
-

Si el usuario escribe "fir" en la barra de búsqueda, y se detiene, Firefox insertará "fir" en el lugar de {searchTerms} y consultará esa URL: -

-
<Url type="application/x-suggestions+json" template="http://ff.search.yahoo.com/gossip?output=fxjson&command=fir"/>
-
-

Los resultados son usados para construir el diálogo con la lista de sugerencias. -

Lee Creación de plugins MozSearch para conocer mas sobre como implementar un plugin de búsqueda. -

-

Implementar las sugerencias en el servidor

-

La mayor parte del trabajo para manipular las sugerencias de búsqueda es realmente implementada en el lado del servidor. Si eres desarrollador web, y quieres soportar las sugerencias de búsqueda, necesitas implementar el soporte para devolver las sugerencias en JavaScript Object Notation (JSON) dado un termino de búsqueda. -

Cuando el navegador desea obtener posibles resultados de un término de búsqueda, envia una solicitud HTTP GET a la URL especificada por el elemento <Url>. -

Tu servidor debe entonces decidir que sugerencias debe ofrecer usando los medios que vea necesarios, y construyedo un JSON que consista en al menos dos, y como mucho cuatro, elementos: -

-
query string -
El primer elemento en el JSON es la cadena de búsqueda original. Esto permite a Firefox verificar que la sugerencia concuerda con el término de búsqueda actual. -
-
completion list -
Un array de los términos sugeridos. El array debe estar entre corchetes. Por ejemplo: <tt>["termino 1", "termino 2", "termino 3", "termino 4"]</tt> -
-
descriptions -
Este elemento opcional es un array de descripciones de cada sugerencia en la completion list. Esto puede ser cualquier información que el motor de búsqueda quiera devolver para que se muestre en el navegador, como el numero de resultados disponibles para dicha búsqueda. -
-
Las descripciones no son soportadas en Firefox 2, y son ignoradas si alguna es espeficificada.
-
query URLs -
Este elemento opcional es un array de URLs alternativas para cada sugerencia de la completion list. Por ejemplo, si quieres ofrecer un enlace a un mapa en vez de simplemente un resultado de búsqueda para una sugerencia, puedes devolver una URL a un mapa en este array. -
-
Si no especificas una URL para la petición, la petición por defecto se manda por defecto al elemento <Url> definido en la descripción XML del plugin. -
-
Las query URLs no son soportadas en Firefox 2, y son ignoradas.
-

Por ejemplo, si el término a buscar es "fir", y no necesitas devolver descripciones o urls alternativas, puedes devolver el siguiente JSON: -

-
["fir", ["firefox", "first choice", "mozilla firefox"]]
-
-

Date cuenta que en este ejemplo, solo se especifican la query string y el completion array, sin especificar los elementos opcionales. -

Tu completion list puede incluir tantas sugerencias como quieras, aunque debe mantenerse manejable, dado que los datos se estarán actualizando en tiempo real mientras el usuario está escribiendo una palabra. Además, el método que usas para elegir las sugerencias depende de ti. -

-
-
diff --git "a/files/es/archive/add-ons/versionado,_actualizaci\303\263n_y_compatibilidad_de_extensiones/index.html" "b/files/es/archive/add-ons/versionado,_actualizaci\303\263n_y_compatibilidad_de_extensiones/index.html" deleted file mode 100644 index 45a3a213ca..0000000000 --- "a/files/es/archive/add-ons/versionado,_actualizaci\303\263n_y_compatibilidad_de_extensiones/index.html" +++ /dev/null @@ -1,295 +0,0 @@ ---- -title: 'Versionado, actualización y compatibilidad de extensiones' -slug: 'Archive/Add-ons/Versionado,_actualización_y_compatibilidad_de_extensiones' -tags: - - Complementos - - Todas_las_Categorías - - extensiones - - páginas_a_traducir -translation_of: 'Archive/Add-ons/Extension_Versioning,_Update_and_Compatibility' ---- -

Las versiones de extensiones

- -

Las extensiones deberán especificar su versión utilizando la herramienta para el formato de versión. En general son unas cadenas de caracteres cortadas por un punto, algunos ejemplos:

- - - -

Como determinan la compatibilidad las aplicaciones

- -

Al instalar extensiones/complementos las aplicaciones (programas) comprueban las entradas targetApplication en el archivo de instalación (install.rdf) de la extensión. La identificación (ID) de una entrada debe coincidir con la ID de la aplicación. Además, el número de versión de la aplicación debe encontrarse dentro del rango definido en minVersion y maxVersion.

- -

Si la aplicación tiene una entrada targetApplication pero es para una versión incompatible, la aplicación intentará obtendrá información actualizada sobre su compatibilidad del archivo updateURL.

- -

Si el archivo de instalación tiene entradas en targetPlatform, la plataforma utilizada para instalar la aplicación debe aparecer listada en ella o se cancelará la instalación.

- -

En las aplicaciones basadas en Gecko 1.9 se puede utilizar una entrada targetApplication con una ID toolkit@mozilla.org; minVersion, y maxVersion que coincidan con la versión de la aplicación. Esto permitirá garantizar que la extensión se podrá instalar en cualquier aplicación basada en Toolkit.

- -

Cancelar el control de compatibilidad

- -

Para la evaluación de extensiones se puede hacer que la aplicación ignore los controles de compatibilidad durante la instalación. Lo único que hay que hacer es crear la preferencia extensions.checkCompatibility y darle valor False.

- -

Antes de la versión 1.5 de Firefox, se podía utilizar la preferencia app.extensions.version para que la aplicación ignorase su versión e instalar así extensiones de otra forma incompatibles.

- -

Elección de minVersion y maxVersion

- -

minVersion y maxVersion deberían especificar las diferentes versiones de la aplicación que se han probado. No se debe introducir un valor maxVersion superior a la versión disponible ya que no se saben qué cambios podrían introducirse en su interfaz de programación (API) y de usuario. Con la actualización de compatibilidad no hace falta publicar una versión nueva completa de la extensión, sólo habrá que aumentar su maxVersion.

- -

Generalmente, en maxVersion es permitido sustituir el número de versión secundario de la aplicación por un asterisco '*', por ejemplo: 2.0.0.* significaría que admite cualquier actualización secundaria de la versión 2 de la aplicación. Normalmente, la aplicación suele sugerir al autor de extensiones con qué parte de la versión conviene más hacer lo antedicho.

- -

El asterisco '*' no representa una versión por sí mismo. En realidad el * representa un número infinitamente alto, por lo que es más sensato usarlo en maxVersion que en minVersion ya que no suele producir el efecto deseado.

- -

Comprobación automática de actualización de extensiones

- -

Periódicamente, las aplicaciones buscarán actualizaciones de las extensiones instaladas recuperando el archivo updateURL. La información recuperada puede servir para notificar al usuario que existe una actualización de la extensión e informar a la aplicación de las nuevas versiones compatibles con la extensión.

- -

Actualizaciones de compatibilidad

- -

Durante la comprobación automática de actualizaciones, las aplicaciones buscan nuevas versiones e información actualizada sobre la compatibilidad de la versión instalada de una extensión. Esto quiere decir que si el manifiesto de la actualización incluye una entrada para la versión actual de la extensión instalada y el targetApplication de la entrada especifica un maxVersion mayor, la aplicación utilizará este valor en lugar del especificado en el archivo install.rdf de la extensión. Esto puede causar que se activen extensiones que estaban desactivadas por ser incompatibles y que se instalen aquellas que normalmente no se instalarían.

- -

Formato RDF de actualización

- -

Si alberga uno mismo el archivo updateURL del complemento será necesario devolver la información de la versión en un formato RDF. Encontrará un ejemplo de manifiesto de actualización más abajo. Muestra información sobre dos versiones diferentes de la extensión para la 'id' foobar@developer.mozilla.org. Las versiones incluidas son 2.2 y 2.5, y cada una especifica la compatibilidad con las versiones de Firefox 1.5 a 2.0.0.*. Para la versión 2.2 se utiliza un enlace de actualización https mientras que para la 2.5 es un enlace regular http con un 'hash' para verificar el archivo recuperado.

- -

Es importante recuperar correctamente la descripción RDF inicial del atributo 'about'. Permite saber de que complemento se trata:

- - - -

urn:mozilla:theme:<id>

- - - -

En cualquiera de los ejemplos siguientes, la secuencia ordenada de las versiones dentro del elemento <RDF:Seq> es importante, con las versiones más nuevas después que las más antiguas. No hay que escribir todas las versiones intermedias si la última es suministrada.

- -
<?xml version="1.0" encoding="UTF-8"?>
-
-<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
-         xmlns:em="http://www.mozilla.org/2004/em-rdf#">
-
-  <!-- Esta forma de descripción incluye toda la
-       información de actualización y compatibilidad
-       para un simple complemento con la id
-       foobar@developer.mozilla.org.
-       Un único archivo RDF admite listados con
-       información de varios complementos. -->
-  <RDF:Description about="urn:mozilla:extension:foobar@developer.mozilla.org">
-    <em:updates>
-      <RDF:Seq>
-
-        <!-- Cada "li" es una versión diferente
-             del mismo complemento -->
-        <RDF:li>
-          <RDF:Description>
-            <em:version>2.2</em:version> <!-- Esto
-           es el número de la versión del complemento -->
-
-            <!-- Un targetApplication para cada aplicación
-                 compatible con el complemento -->
-            <em:targetApplication>
-              <RDF:Description>
-                <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
-                <em:minVersion>1.5</em:minVersion>
-                <em:maxVersion>2.0.0.*</em:maxVersion>
-
-                <!-- Dice donde hay que ir para descargar
-                     esa versión del complemento -->
-                <em:updateLink>https://www.mysite.com/foobar2.2.xpi</em:updateLink>
-
-                <!-- Una página sobre lo nuevo
-                     de esta actualización -->
-                <em:updateInfoURL>http://www.mysite.com/updateinfo2.2.xhtml</em:updateInfoURL>
-              </RDF:Description>
-            </em:targetApplication>
-          </RDF:Description>
-        </RDF:li>
-
-        <RDF:li>
-          <RDF:Description>
-            <em:version>2.5</em:version>
-            <em:targetApplication>
-              <RDF:Description>
-                <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
-                <em:minVersion>1.5</em:minVersion>
-                <em:maxVersion>2.0.0.*</em:maxVersion>
-                <em:updateLink>http://www.mysite.com/foobar2.5.xpi</em:updateLink>
-                <um:updateHash>sha1:78fc1d2887eda35b4ad2e3a0b60120ca271ce6e6</em:updateHash>
-              </RDF:Description>
-            </em:targetApplication>
-          </RDF:Description>
-        </RDF:li>
-
-      </RDF:Seq>
-    </em:updates>
-
-    <!-- Una firma sólo es necesaria en el caso de haber
-         incluido un 'updateKey' en el archivo de
-         instalación 'install.rdf' del complemento. -->
-    <em:signature>MIGTMA0GCSqGSIb3DQEBBQUAA4GBAMO1O2gwSCCth1GwYMgscfaNakpN40PJfOWt
-                  ub2HVdg8+OXMciF8d/9eVWm8eH/IxuxyZlmRZTs3O5tv9eWAY5uBCtqDf1WgTsGk
-                  jrgZow1fITkZI7w0//C8eKdMLAtGueGfNs2IlTd5P/0KH/hf1rPc1wUqEqKCd4+L
-                  BcVq13ad</em:signature>
-  </RDF:Description>
-</RDF:RDF>
-
- -

Mucha gente prefiere este formato alternativo (se ha quitado mucha información en este ejemplo para ver mejor la estructura básica):

- -
<?xml version="1.0" encoding="UTF-8"?>
-
-<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
-         xmlns:em="http://www.mozilla.org/2004/em-rdf#">
-
-  <!-- Esta forma de descripción incluye toda la
-       información de actualización y compatibilidad
-       para un simple complemento con la id
-       foobar@developer.mozilla.org.
-       Un único archivo RDF admite listados con
-       información de varios complementos. -->
-  <RDF:Description about="urn:mozilla:extension:foobar@developer.mozilla.org">
-    <em:updates>
-      <RDF:Seq>
-        <!-- El atributo de recurso apunta a una entrada
-             de descripción 'about' que está más abajo.
-             La uri actual puede ser cualquier cosa -->
-        <RDF:li resource="urn:mozilla:extension:foobar@developer.mozilla.org:2.2"/>
-        <RDF:li resource="urn:mozilla:extension:foobar@developer.mozilla.org:2.5"/>
-      </RDF:Seq>
-    </em:updates>
-    <em:signature>MIGTMA0GCSqGSIb3DQEBBQUAA4GBAMO1O2gwSCCth1GwYMgscfaNakpN40PJfOWt
-                  ub2HVdg8+OXMciF8d/9eVWm8eH/IxuxyZlmRZTs3O5tv9eWAY5uBCtqDf1WgTsGk
-                  jrgZow1fITkZI7w0//C8eKdMLAtGueGfNs2IlTd5P/0KH/hf1rPc1wUqEqKCd4+L
-                  BcVq13ad</em:signature>
-  </RDF:Description>
-
-  <!-- Esto es lo mismo que la descripción con
-       'li' del ejemplo anterior -->
-  <RDF:Description about="urn:mozilla:extension:foobar@developer.mozilla.org:2.2">
-    <em:version>2.2</em:version>
-
-    <!-- El contenido de esta parte se ha quitado -->
-
-  </RDF:Description>
-  <RDF:Description about="urn:mozilla:extension:foobar@developer.mozilla.org:2.5">
-    <em:version>2.5</em:version>
-
-    <!-- El contenido de esta parte se ha quitado -->
-
-  </RDF:Description>
-</RDF:RDF>
-
- -

Facilitar detalles sobre las actualizaciones

- -

- -

En general

- -

Podemos dar a conocer a los usuarios las novedades incluidas en la versión actualizada de nuestro complemento. El usuario al recibir una notificación de que hay una nueva versión puede ver de un vistazo esa información que contiene las mejoras y los arreglos de cualquier problema de seguridad.

- -

Para que así sea, hay que agregar una entrada updateInfoURL en el manifiesto de actualización (ver el ejemplo de encima). La página de esta URL será recuperada y mostrada, al usuario, fuera del contexto normal de una página web por lo cual su contenido es mucho más "limpio", lo que significa que hay muy pocas opciones de formatos y que las secuencias de órdenes e imágenes no están permitidas. Como regla general, sólo se admite el uso de las etiquetas siguientes (cualquier otra cosa se ignorará):

- - - -

Dentro de las listas se usará la etiqueta habitual 'li' para cada ítem de la lista.

- -

Dentro de las etiquetas 'h1', 'h2', 'h3', 'p' y 'li' se utilizará:

- - - -

La página de información recuperada debe ser completamente válida en XHTML, y entregada con el tipo MIME application/xhtml+xml.

- -

Para poder personalizar el texto según la configuración regional/local del usuario se colocará %APP_LOCALE% en updateInfoURL para que esta información esté incluida en la URL, o bien cualquier otras cadenas de substitución admitidas por updateURL, pero no es tan funcional.

- -

Lo que ve el usuario final

- -

El contenido de updateInfoURL será mostrado al usuario en una pantalla del complemento, con una lista de todas las actualizaciones disponibles. Entonces, el usuario puede hacer clic en el botón "Mostrar la información" y la verá a la derecha. (El botón cambiará a "Esconder la información")

- -

Image:Example_updateInfoURL2.PNG

- -

Asegurando las actualizaciones

- -

- -

Gecko 1.9 has added additional requirements designed to protect users from man-in-the-middle attacks and the like during add-on updates. In the install.rdf of the already installed add-on updateURL must be specified in one of the following ways:

- - - -

Si se especifica una actualización de clave/firma (updateKey) en el archivo de instalación ( install.rdf), hay que incluir una firma digital en el manifiesto de actualización sino la información será rechazada.

- -

In the update manifest delivered from the updateURL the updateLink must be specified in one of the following ways:

- - - -

Any entries in the update manifest that do not meet one of those two requirements will be ignored when checking for new versions.

- -

Note that https links to sites with invalid certificates or that redirect to http sites will fail for both the update.rdf and updateLink cases.

- -

Los cifrados de actualización

- -

Al fin de verificar la integridad del XPI descargado se puede proveer una entrada updateHash (cifrado de actualización) junto a updateLink. Este debe ser un cifrado generado desde los datos del fichero según un algoritmo admitido ('sha1', 'sha256', 'sha384' y 'sha512'). El algoritmo de cifrado utilizado debe anteponerse y separarse del cifrado en sí con ':'.

- -
  <em:updateHash>sha1:78fc1d2887eda35b4ad2e3a0b60120ca271ce6e6</em:updateHash>
-
- -

El valor updateHash, debe empezar con la cadena del algoritmo de cifrado, es un error común quitar ese prefijo al poner un valor nuevo en updateHash:\nsha1:78fc1d2887eda35b4ad2e3a0b60120ca271ce6e6"

- -

Además el cifrado del archivo descargado y el cifrado especificado también deben coincidir, sino dará un error.

- -

Varias herramientas permiten generar un cifrado:

- -

Diversas variantes de Unix incluyen: sha1sum, sha256sum y demás. Los usuarios de Windows pueden utilizar HashTab para un uso interactivo (fuera de compilación). Tienen también las utilidades para Win (aparte de los clásicos como Cygwin), las cuales son buenas para un uso no-interactivo:

- -
sha1sum ARCHIVO
-
- -

Además de md5deep que es múlti-plataforma

- -
sha1deep FILE
-
- -

OpenSSL también genera cifrado:

- -
openssl sha1 FILE
-
- -

Para los usuarios de Windows, HashTab es una extensión shell... un simple clic da valores de cifrado para cualquier archivo.

- -

Aquí hay además un bug de mejoras sobre como insertar a McCoy la generación automática de cifrado en archivos XPI.

- -

Y todos los lenguajes (de programación) populares lo ofrecen, por ejemplo: Python, Perl: CPAN Digest, PHP

- -

Firmar el manifiesto de actualización

- -

- -

If you wish to serve your update RDF over regular http, Gecko 1.9 based applications will require that you digitally sign the update manifest to ensure that it's information isn't tampered with between you creating it and applications retrieving it. The McCoy tool should be used to sign the update RDF.

- -

The technical details of the signing mechanism are beyond the scope of this document however the basics are as follows:

- -

The add-on author creates a public/private RSA cryptographic key pair.

- -

The public part of the key is DER encoded and then base 64 encoded and added to the add-on's install.rdf as an updateKey entry.

- -

When the author creates the update rdf file a tool is used to sign it using the private part of the key. Roughly speaking the update information is converted to a string, then hashed using a sha512 hashing algorithm and this hash is signed using the private key. The resultant data is DER encoded then base 64 encoded for inclusion in the update rdf as an em:signature entry.

-- cgit v1.2.3-54-g00ecf