Werte aus options.js in content.js?

Servus

Langsam werd ich wahnsinnig...

Kann man gespeicherte Werte eines AddOns (hier: Icon-Farbe) wirklich nur über das Message-API in ein content-Script überführen?

Gegeben ist ein Wert in einem Array (config.marker.farbe), der sich über eine options.html und darin eingebundene options.js verändern lässt. Die eigentliche Veränderung funktioniert, da sich in der options.html die Darstellung entspechend der Vorgabe im select-Feld verändert. Aber wenn ich dann eben diesen Wert (wie geschrieben: config.marker.farbe) in einem content-Script benutze, ist es noch der Ausgangswert. Die Veränderung kommt im content-Script nicht an.

Muss man jetzt wirklich über das Message-API eine (asynchrone...) Anfrage an die backend.js stellen, um den Wert zu erhalten?

Wenn ja, habe ich noch ein Problem: Bei kurzen Tests gerade eben schien es so, als käme die Änderung des Werts auch in der backend.js nicht an. Die spuckte mir nämlich gerade bei console.log(config.marker.farbe) den ursprünglich definierten Wert aus.

Zur Erklärung: Das content-Script (inject.js) schiebt bei Passwort-Feldern ein Icon ins Input-Feld, welches bei Mausklick ein generiertes Passwort in eben dieses Feld schickt. Die eigentliche "injection" funktioniert tadellos. Das Icon erscheint nur bei Passwort-Feldern, ein Mausklick führt dazu, dass eine in "api.js" enthaltene Funktion aufgerufen wird, und das Passwort landet im Input-Feld. Alles so wie es soll. Aber mein Versuch eine Möglichkeit anzubieten, dem Icon eine andere Farbe zuzuweisen, scheitert daran, dass das content-Script scheinbar nichts von der Farbänderung mitbekommt. Übrigens auch nicht bei extra neu geladenen Seiten.

Ich dachte bisher immer, dass sowohl Hintergrundscript als auch eventuelle API- und Optionsscripte sich denselben "Variablen-Raum" teilen. Von content-Scripten gar nicht zu reden. Aber obwohl die Änderungen in der options.html scheinbar funktionieren, kommen sie weder in background.js noch in content.js an.

Um Fehlern vorzubeugen habe ich die originale Zuweisung in der api.js gerade auf den Fall beschränkt, wenn die Variable noch nicht existiert:

if (!config.marker.farbe) {...};

Aber daran scheint es auch nicht zu liegen. Laut MDN kann man zwischen background und content-Scripten Nachrichten austauschen, aber dazu müsste die eigentliche Änderung erstmal im background-Script ankommen...

Wo liegt mein Denkfehler? Danke schon mal für Tipps!

Zitat von EffPeh

Es ist relativ schwer für mich, dazu etwas zu sagen, so ganz ohne Code.

Ist eigentlich ganz simpel gehalten. Die manifest.json:

{ 
  "description": "Passwortgenerator",
	"manifest_version": 2,
	"name": "PWGen",
	"version": "0.5alpha",
	"icons": {
		"24": "icons/icon_blue.svg",
		"32": "icons/icon_blue.svg"    
	},  

  "developer": {
		"name": "DAUFahnder"
	},
  "background": {
    "scripts": ["resource/api.js", "content/background/background.js"]
  },

  "web_accessible_resources": ["icons/marker_black.svg", "icons/marker_blue.svg", "icons/marker_green.svg", "icons/marker_pink.svg", "icons/marker_red.svg", "icons/marker_yellow.svg"],

  "content_scripts": [
    {
      "js": ["resource/api.js", "content/injects/inject.js"],
      "css": ["content/injects/inject.css"], 
      "matches": ["<all_urls>"],
      "all_frames": true
    }
  ],

	"permissions": [
		"<all_urls>",
    "activeTab",
    "tabs",
    "storage",
    "contextMenus"    
	],


  "browser_action": {
		"default_icon": "icons/icon_blue.svg",
		"default_title": "PWGen 0.1alpha",
		"default_popup": "content/popup/popup.html",
		"browser_style": false
	},

  "options_ui": {
    "page": "content/options/options.html",
    "browser_style": false,
    "open_in_tab": true
  },

	"applications": {
		"gecko": {
			"id": "PWGen@daufahnder",
			"strict_min_version": "60.0"
		}
	}
}

Die api.js mit dem betreffenden Abschnitt. Übrigens nicht in einer Funktion eingemauert sondern wirklich "global" definierte Variable.

var PWGen_Config = [];
  PWGen_Config.Sprache = "de";
  PWGen_Config.Marker = [];
  if (!PWGen_Config.Marker.Farbe) {PWGen_Config.Marker.Farbe = "blue"};
  console.log (PWGen_Config.Marker.Farbe);                                                  // -> blue

Die options.js macht nach einem change-event folgendes:

Zitat

PWGen_Config.Marker.Farbe = getID("PWGenOptions_Einstellungen_InputMarkerFarbe").value;
console.log (PWGen_Config.Marker.Farbe);// je nach Änderung z.B. -> pink

Aber bis dahin wusste die options.js schon von dem Wert "blue". Ich speichere die Optionen zwar später mal, wenn ich mich mit dem asynchronen Kram auseinander gesetzt habe ;), aber eigentlich sollte das doch auch ohne Umweg über den Storage funktionieren. Immerhin kommt der Startwert "blue" ja überall an, also müsste es doch auch möglich sein ihn in der options.js "global" für alle zu ändern. Aber offensichtlich mache ich da einen Denkfehler.

Zitat

Mir stellt sich da aber zunächst einmal die Frage: Definierst du deine config.marker.farbe in der option.js nur, oder speicherst du die auch tatsächlich im storage ab? Und wenn ja, ist auch die entsprechende permisson gegeben?

Ich definiere die in der api.js (s.o.), derzeit ohne Umweg über den Storage, und ändere den Wert dann in der options.js. Was in eine Richtung klappt, in die andere aber nicht. Ich stelle mit eine Webextension einfach so vor, dass da ein HTML-Dokument ist mit einer relativ großen JavaScript-Umgebung. Alle Scripte greifen auf die selbe Umgebung zu und wenn eine Variable irgendwo geändert wird, dann gilt das für die gesammte Umgebung. Ich würde es ja noch verstehen, wenn die content.js nichts von den Änderungen mitbekäme, die content-Scripte scheinen da etwas abgeschottet zu sein, aber wie gesagt selbst die background.js merkt nichts.

Aber der Einfachheit halber: https://github.com/DAUFahnder/PWGen

Zitat von EffPeh

Ja, nee, da hast du wirklich einen Denkfehler.
Denn wenn du deine Optionen aufrufst und eine Einstellung machst, ist die doch weg, sobald die Datei wieder geschlossen wird. Und natürlich auch sämtliche Vars, die du dort evtl. definiert hast.

Hm... mit anderen Worten, die eigentlich ja permanent laufende background.js reicht nicht um sicher zu stellen, das veränderte Variablen im Speicher verbleiben, sehr lästig. Aber gut, wenn mans weiss kann man ja den Umweg über den Storage gehen :).

Bleibt noch die Frage: Wenn ich in der options.js die Änderungen in den Storage schicke, kann ich den dann direkt im content-Script abrufen? Oder muss ich wirklich den Umweg über browser.runtime.sendMessage gehen, um das dann aus der background.js zu beantworten weil das content-Script keinen Zugriff auf denselben Storage-Bereich bekommt?

MDN schreibt das für mich nicht 100% klar. Oder mein Englisch ist schlechter als ich dachte ;).

EDIT: Übrigens, dieser asynchrone Kram ist..lästig. Man kann nicht einfach sagen "Variable X hat den Wert Y aus dem Speicher." Man muss sagen "Variable X hat den Wert Y aus dem Speicher sobald der Speicher geantwortet hat. Und wehe Du vergisst auf die Antwort zu warten".

So nachvollziehbar die Vorteile auch sind, für Laien wie mich macht es das nicht einfacher ;).

EDIT 2: Ich hab' was wichtiges vergessen: DANKE!

Zitat von EffPeh

Nee, das ist so to say live. Zumindest funktioniert das bei meiner Extension so. Kannst du ja selbst testen. Wenn du da z.B. das Theme wechselst, ist das direkt ersichtlich. Schau's dir einfach mal in Ruhe an.

Sorry, nein. Du nutzt schlicht keine Content-Scripte. Deine content.js bezieht sich nur auf die content.html, welche den Export anbietet. Das ist aber ohnehin eine AddOn-Datei und daher nicht den Einschränkungen unterworfen die mein eigentliches Problem sind.

Aber ich habe immerhin inzwischen eine Lösung für mein Problem gefunden: Ich speichere die Optionen nicht mehr direkt in der options.html und der damit verbundenen options.js, sondern lasse die options.js die Daten an die background.js weiterreichen, welche sie dann speichert. Damit liegen alle Daten dort wo sie ohnehin gebraucht werden. Da man vom Hintergrund-Script aus problemlos mit dem Content-Script reden kann, auch Event-gesteuert (neu laden, tab aktiviert, Storage geändert...), kann ich dem Content-Script immer passend die Daten zuschicken die es braucht.

Ich finde diesen mehrfachen Umweg zwar etwas umständlich - und mache vielleicht auch bloss irgendwo einen Fehler der mir nicht klar ist - aber die background.js läuft laut MDN immerhin permanent solange das AddOn aktiv ist und arbeitet auch immer in derselben Umgebung - es gibt sie also nur einmal pro Browser-Sitzung - sie sollte also Daten die sie selbst verändert auch wieder korrekt abfragen können. Denn egal wie ich den Storage in der options.js veränderte, die Änderung kam nie im Hintergrund-Script an; lästig.

Egal, jetzt klappts. Bleibt bloss noch die Integration der Optionen. Und das auch noch so flexibel, dass man Optionen auf Wunsch pro Domain getrennt anlegen kann. Und da auch noch auf Wunsch getrennt für mehr als eine Identität... und natürlich so flexibel, dass sich die Anzahl der Domains und Identitäten flexibel anpassen lassen. Wo war doch gleich die Speicher-Grenze für AddOns :-??:wink:

Immerhin, mein baldiger Urlaub dürfte nicht langweilig sein ;).

Zitat von EffPeh

Es geht doch auch gar nicht darum, wo ich die storage-API nutze, sondern wie. Und was diese API angeht, besteht hier keinerlei Einschränkung für Content scripts.

Es ist also, nach meinem Verständnis, völlig überflüssig, den Umweg über die background.js zu gehen. :wink:

Mir hat das jetzt keine Ruhe gelassen, also habe ich die letzten Tage weiter getestet. Es mag ja sein, dass Content-Scripte Zugriff auf dieses API haben, aber für mich scheint es mindestens so, dass sie nicht im selben "Raum" arbeiten.

Wenn ich im Content-Script folgendes mache:

const defaultSettings = {
    farbe: "pink",
};


function restoreOptions() {
    browser.storage.local.get(defaultSettings)
        .then(settings => {
	document.getElementById("test").value = settings.farbe;
    }, error => setStatus(`Error: ${error}`));

Wird der Inhalt natürlich zu "pink" geändert. Ändere ich dann aber innerhalb der Optionen eben diesen Wert:

function saveOptions(e) {
    var settings = {
        farbe: "schwarz"
    };
    browser.storage.local.set(settings)
        .then(() => setStatus("Optionen gespeichert."));
    e.preventDefault();
}

bleibt es bei pink. Schicke ich den Wert für Farbe aber von der background.js ins Content-Script:

[event browser.tabs.onActivated]

    browser.storage.local.get(defaultSettings)
      .then(settings => {
      	browser.tabs.sendMessage(
        	tab.id,
	        {farbe: settings.farbe}
      	).then(response => {
        	console.log("Message from the content script:");
	        console.log(response.response);
      	}).catch(onError);
      });

Kommt der korrekte (zuvor in den Optionen geänderte) Wert im Content-Script an. Obwohl der Storage-Zugriff beide Male derselbe ist (imho..).

Also entweder mache ich im Content-Script einen Fehler der die korrekte Verarbeitung vermasselt (durchaus möglich!) oder Content-Script und die anderen AddOn-Scripte haben getrennte Storage-Scopes.

Ich habe ab Mitte Juli Urlaub, dann sollte ich das AddOn zumindest soweit funktionstüchtig bekommen, dass ich es anderen zum Testen zumuten kann. Eventuell findet dann ja jemand den Fehler den ich unbemerkt produziere und der die korrekte Verarbeitung im Content-Script vermasselt.

Anm.: Ich habe in obigen Schnippseln jetzt nicht jede genutzte Funkton ausgeschrieben. setStatus z.B. ist eine separate Funktion, die in den Optionen ein entsprechendes span-Element mit Inhalt füttert. Das Prinzip sollte aber klar sein.

Zitat von EffPeh

Falls du tatsächlich in deinen Optionen für die Farbe "schwarz" verwendest, musst du dich nicht wundern, denn diesen Schlüsselwert gibt es gar nicht. (Es gibt nur "black".) Also wird die Farbangabe ignoriert.

Es gibt im Grunde jede beliebige Farbe weil ich die Zuweisung nicht als CSS-Code vornehme. Ich füge jeder Seite per Content-Script ein zusätzliches Element hinzu. Genauer ein "img". Das wird pauschal erstmal mit "display: none" eingebaut, ist also im Normalfall nicht sichtbar. Erst wenn ein Input mit dem Type "password" gehovert wird oder selbiges den Focus bekommt, wird das img-Element mit einigen Tricks am Ende des Input-Feldes aufgepappt:
[attachment=0]1.png[/attachment]
Das AddOn "InFormEnter+" macht es ebenso, wenn auch auf andere Art (imho deutlich umständlicher, aber ich bin ja auch kein Programmierer). Daher kam ja meine Idee dazu.

Die "Farbe" wird im Attribut "src" benutzt. Je nach User-Einstellung gibt es also ein pinkes img, ein rotes, ein gelbes... . Daher sind nicht die CSS-Farbcodes von Bedeutung sondern die Benennung meiner Marker-SVGs. Und da gibt es derzeit sehr wohl ein "schwarz".

Zitat

Ansonsten kann ich zu den Code-Snippets nicht wirklich viel sagen, weil mir der Kontext fehlt. Falls du aber in deinem Content-Script den Code so wie er da steht verwendest, ist es - aus meiner Sicht, eben ohne Kontext - klar, das bei jedem Aufruf die Farbe wieder auf "pink" gesetzt wird. Egal, was du in deinen Optionen festlegst.

Wie gesagt, siehe oben. Zumal es aus dem background-Script heraus ja auch funktioniert. Läge es tatsächlich an der Bezeichnung, dürfte auch das nicht klappen.

Zitat

Ich verstehe auch nicht, warum überhaupt in einem Content-Script Optionen gesetzt werden. Das erschliesst sich mir hier nicht. Nach meinem Verständnis werden Optionen eben in einer option.js definiert und dann - bei Bedarf - in anderen Scripten abgerufen.

Wo definiere ich in Content-Scripten eine Option? Ich gebe Standards vor, nutze dieses Array zur Abfrage im Storage und wenn sich im Storage ein anderer Wert findet wird natürlich der benutzt. Das machst Du übrigens nicht anders, nur dass bei dir die Standard-Vorgaben direkt in der Funktion definiert sind, ich habe das bloss als Konstante ausgelagert. Das dient der Sicherstellung, dass abgefragte Werte immer existieren, auch wenn sie in den Optionen nicht explizit gesetzt wurden. Denn das Content-Script soll ja arbeiten auch ohne dass man irgendwelche Optionen jemals gesehen hat.

Wie gesagt: Läge es an irgendwelchen Bezeichnungen, dürfte es nie funktionieren. Es funktioniert aber nur im Content-Script nicht korrekt. Ist aber am Ende auch egal. Die Variante mit dem Senden der Optionen aus dem Hintergrundscript heraus hat durchaus Vorteile.

Zitat von EffPeh

Sorry, aber das kann ich ja nicht wissen. Das geht nicht aus deinem Post bzw. dem Code hervor. :wink:

Ja, da hast Du wohl recht. Andererseits ist der Dateninhalt für das eigentliche Problem (Content-Scripte arbeiten in einem anderen Scope oder ich bin blind und sehe den Fehler nicht) auch vollkommen egal.

Zitat

Äähm, hier...

Da definiere ich Standard-Werte in einem zur Storage-Abfrage benutzten Array. Aber ich hätte es zugegeben dazu schreiben müssen. Wenn ich das nämlich nicht mache, und die Storage-Abfrage läuft ins Leere, erscheint nur der übliche img-Platzhalter da der Fuchs versucht ein svg zu laden welches nicht existiert: "marker_undefined.svg" gibts halt nicht ;). "value" nutze ich im obigen Schnippsel nur, weil es kürzer ist als die tatsächliche Nutzung.

Zitat

Wie gesagt, ich kann anhand einiger Schnipsel nicht die Struktur deines Scripts erfassen und kann also höchstens Vermutungen anstellen.

Verständlich. Ich will hier auch nicht gerade den kompletten Code veröffentlichen, das wäre Overkill. Und der derzeitige Stand auf Github ist rettungslos veraltet - müsste ich mal aktuallisieren.

Zitat

Wie auch immer: Ich habe dir mal auf die Schnelle eine Extension erstellt, die zeigt, wie man storage-Werte live aus einem Content-Script heraus nutzen kann. Vielleicht hilft dir das weiter.
Das Script basiert auf dem borderify-Beispiel, welches nicht weiter macht, als dem body-Tag einer Website einen Rahmen zu verpassen. Ich habe allerdings nun Optionen hinzugefügt, mit denen man die Farbe ändern kann. Ändert man die Farbe in den Optionen, wird auch die Rahmenfarbe auf Webseiten live übernommen. :wink:
optionTest.zip

Danke. Aber beim Installationsversuch über about:debugging -> Zitat vom Fuchs:

Zitat

There was an error during installation: Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.directoryEntries]

Aber: Ich glaub' Dir, dass es eigentlich funktioniert. Also gehe ich davon aus, dass ich in meiner Variante irgendwo einen Fehler hatte. Da ich den aber nicht finde und eine Sicherung meiner Tests auch nicht existiert, bleib ich mal bei meiner Lösung. Die tuts ja problemlos. Und sollte bei den geringen Datenmengen auch kein Leistungsproblem sein.

Nachtrag, weil mir gerade ein Licht aufgegangen ist :idea: :

Ich hatte ein riesen Verständnis-Problem was browser.storage.local.get() betrifft. Der Fehler lag in meinem System der Abfrage, welches noch von localStorage.getItem() kommt, welches zwingend einen Bezeichner für das Datum braucht welches man haben will. Immerhin, so lernt man auch :oops: .

EffPeh, vielen Dank nochmal, so eine Diskussion ist hilfreich wenn man den Baum vor lauter Wald nicht erkennt :klasse: .

Zitat von DAUFahnder

Verständlich. Ich will hier auch nicht gerade den kompletten Code veröffentlichen, das wäre Overkill. Und der derzeitige Stand auf Github ist rettungslos veraltet - müsste ich mal aktuallisieren.

So, ich habe gebastelt:
[attachment=0]PWGen.zip[/attachment]

Bitte beachten: Bis auf die Marker-Farbe sind sämtliche Optionen faktisch funktionslos. Sie werden gespeichert, haben aber keinerlei Auswirkungen. Das einzige was tatsächlich funktioniert ist das Popup über den Button. Und wie ich gerade gesehen habe, funktioniert da das Häkchen für die Sonderzeichen nicht. Vermutlich weil ich inzwischen an den Variablen gedreht habe oder die Abfrage schlicht noch fehlt :).

Auch der gesetzte Marker macht nichts, was man als Nutzer bemerkt. Er spuckt lediglich in der Browser-Konsole die ID des betreffenden HTML-Elements aus. Das ist nur für mich zum Testen. Mit anderen Worten: Das Paket soll nur zeigen was ich geplant habe. Selbst die Variablen, IDs etc sind derzeit noch Overkill. Die Bezeichner dienen mir derzeit noch als Hilfe um zu sehen was falsch läuft, die werden in der finalen Fassung noch zusammen gekürzt und den Konventionen angepasst.

Falls also jemand Tipps hat, was man machen könnte... :lol::lol::lol:

Gute Nacht!

Zitat von EffPeh

Eine funktionierende Grundversion wäre natürlich auch mal nicht schlecht, denn momentan wird lediglich ein Passwort generiert. Wobei ich aus dem wenigen, was man dieser Extension bisher entnehmen kann (und ich meine nicht den Code - den ackere ich nicht durch ), nicht wirklich schlau werde. Es wäre vielleicht nicht verkehrt, wenn du auch mal genau beschreibst, was dieses AddOn eigentlich machen soll. Offensichtlich wird ein Passwort generiert. Okay. Dabei sind aber für mich viele Dinge unklar:
- Was habe ich unter "Masterpasswort" und "Nutzer" zu verstehen? Bezieht sich das auf die Website, die ich gerade besuche? Oder ist das auf die Extension bezogen?

Masterpasswort ist am Ende dasselbe Prinzip wie ein Masterpasswort für das Firefox-Profil: Damit werden die verschlüsselten Daten gesichert und es wird verhindert, dass ein zweiter Nutzer am selben Fuchs (Besucher z.B.) sich einfach so irgendwo mit den Daten des Gastgebers anmelden kann.
"Nutzer" meint den Benutzernamen einer beliebigen Webseite. Ich melde mich hier als "DAUFahnder" an, also wäre auf https://www.camp-firefox.de mein Nutzername "DAUFahnder". Allerdings wird es die Möglichkeit geben, für Seiten mehrere Identitäten anzugeben. PWGen fragt dann nach welche genutzt werden soll wenn für die betreffende Adresse mehrere hinterlegt sind. So könnte ich also für https://www.camp-firefox.de also einerseits ein PW für den Nutzer "DAUFahnder" generieren lassen, als auch z.B. für "Westfale". Das AddOn selbst könnte ich theoretisch mit mehreren Nutzern versehen, aber eigentlich ist das durch das Masterpasswort überflüssig. Wenn man mehrere Nutzer will, speichert man das MasterPW nicht permanent ab sondern lässt jedes Mal nachfragen. Da es sowohl zur Verschlüsselung der Daten dient als auch in den Passwort-Hash selbst mit einfliesst (s.u.) könnte man sich so beliebig viele vollständig getrennte Identitäten anlegen.

Zitat

- Was ist das mit dieser "laufenden Nummer"? Wozu ist das gut? Muss ich da als User irgendetwas einstellen?

PWGen erzeugt ein Passwort für eine Seite als Hash. Dabei fliessen diverse Dinge in den Ursprungsstring ein, darunter neben der Hostadresse, dem Nutzernamen und dem Masterpasswort auch diese laufende Nummer. Gedacht ist das, um bei Bedarf mal das Passwort zu wechseln. Wird die Nummer einfach um 1 erhöht, ändert sich der Hash und damit natürlich das Passwort. Man kann also auf dem Formular zum Ändern des Passworts leicht das alte eingeben, erhöht die Nummer um 1 und bekommt sofort das neue Passwort für beide Felder (im Regelfall muss man das neue PW ja noch wiederholen). Und ja, PWGen wird sich merken, wenn man für Nutzernamen X auf Webseite Y die Nummer um 1 erhöht hat und wird das dann in Zukunft automatisch machen. Diese Anforderung "neues Passwort" wird später im Kontextmenu des Markers auftauchen und bei Auswahl wird die Nummer um 1 erhöht, das PW generiert und ins Passwortfeld verfrachtet. Klickt man dann im Feld für Passwortwiederholung auf Passwort einfügen, weiss PWGen noch, dass die Nummer erhöht wurde und fügt automatisch das neue Passwort ein.

Letztlich dient die Nummer als Lösung für zwei Probleme: Man kann schnell und einfach neue Passwörter generieren, bekommt aber trotzdem schnell und einfach das alte Passwort jederzeit wieder wenn man es braucht. Wie geschrieben vor allem, um bei einer Passwortänderung das alte trotzdem eingeben zu können, wie es viele Webseiten verlangen.

Das Schöne am Grundsystem ist: Man muss sich nur noch ein Passwort merken (das MasterPW) und hat trotzdem für jede Webseite ein anderes Passwort das man schnell und leicht heraus finden kann wenn man es denn doch mal braucht. Wieviele Menschen vergessen wohl ihre Passwörter weil sie den Passwortspeicher ihres Browsers benutzen? Und wieviele davon haben keine Ahnung, dass sie im Notfall durchaus an ihre Passwörter kämen weil der Fuchs sie auf expliziten Wunsch anzeigen kann?

Zitat

- Was ist mit dem erzeugten Passwort? In welcher Form merkt sich die Extension das? Merkt (sich) die Extension, wenn ich den Wert der Ausgabe manuell ändere?

Die Passwörter selbst müssen nicht gespeichert werden. Ein Hash erzeugt aus denselben Vorgaben immer dasselbe Ergebnis. Zumal Firefox selbst einen Passwortspeicher enthält und wozu das Rad neu erfinden.

Die Extension merkt sich in der Grundeinstellung jede Änderung der Vorgaben pro Domain. Gibt man einen anderen Benutzernamen an und lässt ein Passwort generieren, speichert PWGen auch diese Vorgaben und fragt beim nächsten Besuch der Seite, welcher Nutzer es denn sein soll. Theoretisch kann man sich mit zig Identitäten auf derselben Seite anmelden und PWGen fragt immer brav an, welchen Namen davon man denn Heute benutzen will und dank Masterpasswort kann Ehefrau nicht die Anmeldungen von Ehemann sehen und umgekehrt. Löschen von Daten ist natürlich vorgesehen.

Das einzige was mich derzeit noch dran hindert, die Optionen wirklich effektiv einzubauen und PWGen zu veröffentlichen, ist der Datenex- und import. Es muss eine Möglichkeit geben, sich sämtliche gespeicherten Daten ausgeben zu lassen. Denn merken kann man sich die nicht und man will ja vielleicht mal den Browser wechseln oder seinen Rechner neu aufsetzen. Vermutlich wird es da die Möglichkeit geben, statt der gespeicherten Daten "nur" die Passwörter ausgeben zu lassen. Da ein ReImport angedacht ist, brauche ich zwei Export-Formate: Einmal als einfache HTML-Datei die man sich ausdrucken kann (relativ einfach) und einmal im json-Format, damit ein Import für einen neuen Firefox möglich ist. Das json-Format braucht dann aber nicht die Passwörter selbst sondern "nur" die hinterlegten Daten.

Ein Frustpunkt war das Speichersystem: Ich brauchte eine Lösung, um vollkommen variabel Daten pro Domain zu speichern ohne vorher zu wissen welche Domains es sind. Und dann auch noch die Lösung, um pro Domain mehrere Nutzer zu ermöglichen, ebenfalls ohne vorher zu wissen wie die Namen lauten werden. Ich habs nicht so mit Programmierung (weshalb Hash- und Verschlüsselungsfunktionen auch nicht von mir sind), musste mich also durchtesten. Das klappt aber inzwischen problemlos.

Zitat von EffPeh

Wobei ich eben nicht weiss, ob deine Extension sich die Änderung auch merkt.

Wird sie machen, ja. Sonst wäre es auch witzlos.