Domino 9 und frühere Versionen > ND8: Entwicklung

String "vergisst" Zeichen in LotusScript

<< < (4/7) > >>

eknori:
Es ist zum Mäusemelken. Ein Fix hat zunächst funktioniert. Ich habe den Wert in eine andere glob. Variable ausserhalb der UserInfo geschrieben. Bei der Anlage weiterer User war dann ( erwartungsgemäß ) nicht nur UserInfo.Password fehlerhaft, sondern auch diese neue Variable.
Ich kann das absolut nicht mehr nachvollziehen.

Nochmal. das Problem taucht nur bei einem Kunden ( = Installation ) auf und kann auf KEINEM anderen vergleichbaren System auch nur ansatzweise nachvollzogen werden.

Peter Klett:
D.h. Userinfo.Password war korrekt, dann wurde das in eine weitere Variable geschrieben, dort kam der Inhalt korrekt an. Während der weiteren Verarbeitung wurden beide Variablen, also Userinfo.Password UND die globale Variable verändert?

Bist Du sicher, dass die globale Variable nicht nur ein Zeiger auf die Userinfo.Password war?

eknori:

--- Code: ---szPassword = CreatePassword( ...

UserInfo.Password = szPassword
pwdSave = szPassword

--- Ende Code ---

thkn777:
Ich habe seltsamerweise zuerst an sowas gedacht wie
- Option Base 0 bzw. 1
- Call by Reference

Ich weiß - total verrückt, aber es ist ja auch ein verrücktes Problem ;)

OK, fangen wir hier an:


--- Zitat von: eknori am 21.05.14 - 13:39:29 ---Ich habe den Wert in eine andere glob. Variable ausserhalb der UserInfo geschrieben. Bei der Anlage weiterer User war dann ( erwartungsgemäß ) nicht nur UserInfo.Password fehlerhaft, sondern auch diese neue Variable.
--- Ende Zitat ---

#1
Was ist createPassword(..) denn für eine Funktion? Worauf ich hinauswill: woher bekommt sie die Daten und wie verarbeitet sie diese? Kann in dieser Funktion überhaupt ein String mit NUL am Anfang generiert werden?

#2
Falls ja: Kommt der String mit NUL am Anfang evtl. von createPassword? Sprich:


--- Code: ---szPassword = CreatePassword( ...

print "-->" & szPassword & "<--"
UserInfo.Password = szPassword
print "-->" & UserInfo.Password & "<--"
pwdSave = szPassword
print "-->" & pwdSave & "<--"

--- Ende Code ---

ergibt was? Das wird oben schon verneint, aber wenn es das nicht ist, dann:

#3
Getter und Setter. Vielleicht wird über den Lebenszyklus von UserInfo ja Password mehrfach gesetzt oder sonst irgendwie verändert? Getter und Setter bauen, aus Password ein Private pPassword machen und im Getter und Setter jeden Zugriff mitloggen. Du sagtest, die Applikation sei SEHR komplex. Da kann eine Menge schiefgehen...

#4
Datenübergabe im weiteren Sinne. Wird UserInfo oder Teile davon in irgendeiner Form abgespeichert, ex. ein NotesDocument (und wenn auch nur in-memory), wird es exportiert, wird Password im/exportiert (egal warum)? Findet dabei ggf. eine Veränderung statt, die man allein durch LotusScript nicht erklären kann? Ich glaube Dein erstes Posting so verstanden zu haben, daß da allerhand passiert...

Ich denke in die Richtung von Character Sets, unterschiedlichen Datenbank-Settings (Oracle, DB2, whatever), etwas, das in der Lotus Notes Umgebung nicht unmittelbar beeinflußbar ist und das nur auf diesem System (warumauchimmer) anders ist.

Für "Konsumenten" des Paßworts wäre es natürlich auch ganz toll zu wissen, was diese meinen, bekommen zu haben.

#5
Der Kunde hat andere 64bit Systeme im Einsatz, wo das funktioniert? Auch migrierte? Bei Euren Versuchen, die Situation nachzubauen, habt Ihr den alten 32bit Zustand zuerst hergestellt, dann migriert und dann geguckt?

Will sagen - evtl. ist alter Ballast oder das Fehlen davon ein Problem. Irgendeine DLL hat eine andere Version, irgendeine Library ist vom anderen Release-Stand... usw.

Gibt es irgendwelche Unterschiede von diesem Server zu anderen? Physischer Server vs. virtueller, andere SW-Releases, weniger/mehr/andere Zusatzsoftware bzw. Dienste etc.

#6
Wenn es nur um den Notes-Server geht - beim Kunden dieses System außer Betrieb nehmen und den gleichen Notes-Server (quasi 1:1) komplett neu aufsetzen. Wenn Ihr das Problem nicht reproduzieren konntet, dann löst eine funktionale 1:1 Kopie dieses Servers auf anderem Blech bzw. einer anderen VM das Problem?

#7

--- Zitat von: eknori am 21.05.14 - 09:06:39 ---..in der Chiffrierungsroutine kommt aber nur " 7vcHGY5Wc6vzLMj" an...

--- Ende Zitat ---

Was für eine Chiffrierungsroutine? Ist nur diese vom NUL-Problem betroffen? Wie kommt das Paßwort zu dieser Routine? D.h. *eigentlich* ist alles ok, nur in dieser Routine kommt ein falscher Wert an? Ist das auch Lotus Script? Könnte man da eine andere Form der Datenübergabe testen?

Bei Chiffrieren denke ich an eine externe Funktion (nicht nativ LS), bei deren Aufruf etwas schiefgeht.


Viel Erfolg,
Th.

Werner Götz:
Hallo Ulrich,
wenn ich mir so überlege, was da im Speicher passiert, müsste der Fehler an einer anderen Stelle zu suchen sein. Und zwar im Zusammenhang mit der Variable, die im Hauptspeicher VOR dem Passwort steht.
Wird diese Variable über eine DLL gesetzt, die ans Ende der Variable ein NUL setzt? Könnte es vielleicht passieren, dass das in diesem Fall Speicher der nächsten Variable überschreibt?

Als Test hierzu würde ich also mal vorschlagen, vor und hinter Deinen Member eine weitere Variable aufzunehmen und mit einigen Leerzeichen vorzubesetzen.

Ist die Vermutung richtig und obiger work around behebt den Fehler sollte man natürlich trotzdem noch nach der schuldigen Routine suchen! Hier könnte ich mir den Fehler so vorstellen, dass bei einem 32 Bit System Variablen richtig initialisiert wurden, beim 64 Bit System die größere Wortlänge aber "einen Strich durch die Rechnung macht".

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete