View Issue Details

IDProjectCategoryView StatusLast Update
0000256GORM[Adventure PHP Framework] Bugpublic2015-10-11 12:26
ReporterGeneral CrimeAssigned ToChristianAchatz 
PriorityurgentSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version[Adventure PHP Framework] 2.1.1 
Target Version[Adventure PHP Framework] 3.0.2Fixed in Version[Adventure PHP Framework] 3.0.2 
Summary0000256: Beim laden von Objekten über "loadObjectByID", "loadObjectByTextStatement" loadObjectByStatement" ist Mehrfachausgabe möglich.
DescriptionWenn ich zb. im UMGT loadUserByEMailAndPassword aufrufe gibt mir die untergeordnete Funktion "loadUserByEMail" ggf. mehr als 1 User zurück wenn die E-Mail mehrfach vorhanden ist. Da ich jedoch von ausgehe das ich immer nur 1 Objekt laden möchte sollte ein "limit 1" im GORM bei den besagten Funktionen eingebaut werden.

Das UMGT ist ja nicht so gebaut das nur eine E-Mail existieren darf was sin macht wenn auch Einträge ohne E-Mail existieren.
Additional InformationDas UMGT prüft hierbei auch nichtmal zu welcher Applikation der User gehört!?
Tagsdatabase, gorm
Codereferenz: ([Datei]:[Zeile])

Activities

ChristianAchatz

2015-09-01 20:56

administrator   ~0000584

Hallo GeneralCrime,

ich habe mir die Implementierung genauer angesehen und auch einen Test durchgeführt. Ergebnis: ich erhalte für loadUserByEMailAndPassword() nur einen Benutzer. Szenario:

Datenbank:

ID DisplayName EMail Username
29 123, Test test123@example.com test123-2
28 123, Test test123@example.com test123-1


Controller:

$user = $umgt->loadUserByEMailAndPassword('test123@example.com', 'test123');


Ergebnis:

[APF\modules\usermanagement\biz\model\UmgtUser ObjectName="User", UserID="29", DisplayName="123, Test", FirstName="Test", LastName="123", StreetName="NULL", StreetNumber="NULL", ZIPCode="NULL", City="NULL", EMail="test123@example.com", Phone="NULL", Mobile="NULL", Username="test123-2", Password="$2a$07$32481e9d7369cd34bc15duoG.58ECLMn3yBLsyLnBQH7QWNa6dUBK", DynamicSalt="32481e9d7369cd34bc15d69e7352c3ca", CreationTimestamp="2015-09-01 20:46:53", ModificationTimestamp="0000-00-00 00:00:00"]

Aus Sicht der Implementierung ist das auch nachvollziehbar, da loadUserByEMailAndPassword() intern loadUserByEMail() aufruft, diese wiederum loadObjectByTextStatement(), die lediglich ein Objekt von der Datenbank per fetchData() abholt (siehe \APF\modules\genericormapper\data\GenericORMapper::loadObjectByTextStatement()).

Bei loadObjectByID() wird intern ebenfalls nur ein Datum von der Datenbank abgeholt:

return $this->mapResult2DomainObject($objectName, $this->dbDriver->fetchData($result));

Insofern sehe ich auch da keinen offensichtlichen Fehler.

Magst du mir kurz auf die Sprünge helfen oder vielleicht ein Beispiel posten, bei dem es schief geht? Danke! :)

General Crime

2015-09-02 10:01

developer   ~0000585

Last edited: 2015-09-02 10:09

View 2 revisions

Leider sehe ich nicht genau welches Passwort du genutzt hast da das"-1" "-2" fehlte.
Versuch dich aber mal in dem Account der ID 28 ein zu loggen.

PS: Achso das war der Benutzername.
Sind bei beiden Accounts die Passwörter gleich? wenn nicht wette ich das Du nicht in den ID28 Acocunt rein kommst.

ChristianAchatz

2015-09-03 21:01

administrator   ~0000586

Hi,

genau, das "-1 und "-2" sind die Benutzer-Namen. Passwörter wurden explizit gleich gewählt - ja.

Du hast Recht, mit Account 28 kann ich mich nicht einloggen. Das liegt an dieser Stelle in der Tat an der Implementierung, die nicht darauf vorbereitet ist, dass die Selektion über E-Mail und Passwort mehrere Benutzer ergeben kann. Soweit ist die Implementierung aber konsistent, dass ich immer den 29er bekomme.

Die Frage ist nun: ist das ein Fehler oder eine Grauzone bei der Anforderung. Ich kann das nicht abschließend für mich beantworten, da ein Login ja möglich ist, nur ggf. mit einem anderen Benutzer als ich zunächst erwarte.

Mit 0000248 wurde jedenfalls die Anmeldung im UMGT mit einer bereits vorhandenen E-Mail verhindert. Wird die UMGT-Anmelde-Komponente eingesetzt, so ist damit das Problem an sich gelöst. Bestehen bleibt das Problem natürlich trotzdem, wenn du per UMGT-API einfach zwei gleiche Benutzer anlegst.

Welches Problem stellt das aktuelle Verhalten in deinem Anwendungsfall denn dar? Wäre 0000248 eine Lösung?

General Crime

2015-09-03 21:54

developer   ~0000587

Last edited: 2015-09-03 21:57

View 2 revisions

Naja ich stelle mir jetzt die Anwendung des UMGT mit 2 Applicationen vor wo dann ggf. 2 User gleiche User existieren könnten.

Derzeit habe ich einen Pizza Lieferdienst dieser hat sowohl die Daten vom Personal beim Bestellen als auch die Daten die Kunden ggf. über die Webseite eintragen und sich einen Account erstellen. (Bei Sichtung werden diese durch ein Scrippt zusammengelegt).

Habe hier derzeit 2 Gruppen 1. Personal und 2.Kunde und das Login dahingehend geändert das er nur Kunden sucht.

Die Daten die das Personal hat können ggf. aber auch vom Kunden stammen nur das er keinen festen Account haben möchte aber die E-Mail ist dann ja bekannt und der Kunde wird dennoch gespeichert als (Von Personal angelegt). Dann will derselbe Kunde wirklich einen Account haben und dann kommt es vor das ich 2 mal die Adresse habe solange bis diese zusammen gelegt werden. Da ich bei der Registrierung nur schaue ob es bereits einen Account (vom Kunden angelegt) mit der E-Mail gibt.

Ich könnte natürlich beim erstellen vom Kunden schon ggf. die Accounts zusammenlegen bzw den ersten umschreiben bisher hab ich aber gedacht das es auch zu Fehlern kommen kann man hat ja auch mal (blöde Kunden) die ein und die selbe Adresse nehmen aber sich woanders befinden zb. bei einem Freund.

PS: Derzeit ist das Login auch so geändert das er nur "Vom Kunden erstellte Accounts" durchsucht. Ich denke jetzt mehr zu der Application zu die im Login keinerlei rolle spielt wenn sie das würde könnte man das auch über Application regeln anstelle von Gruppen.

ChristianAchatz

2015-09-04 10:52

administrator   ~0000588

Hi,

die Zuordnung von Benutzern zu Applikationen schaue ich mir nochmal an, das wäre in der Tat ein Bug.

Danke für die Erläuterung deines Anwendungsfalls. Das ist in Tat tricky. Wenn ich alles richtig verstanden habe kannst du das UMGT vermutlich nicht direkt nutzen, da es beim Login nicht auf die Zugehörigkeit von Gruppen oder Rollen prüft. Das wäre entweder eine Funktionalität, die du on-top implementieren kannst oder ein neues Feature des UMGT.

Gefühlsmäßig würde ich sagen, dass es nicht zuviel Aufwand bedeuten dürfte das zu implementieren, da du vom UmgtManager den GORM beziehen und dort eine entsprechende Anfrage stellen kannst. Evtl. kannst du auch den UmgtManager erweitern und die erweiterte Version in deiner Applikation nutzen. Das geht mit der Erzeugung per DI-Service relativ smart.

Auch anbieten kann ich dir, aus der Anforderung ein neues Feature zu definieren und wir beide/du oder ich implementieren das für 3.1 direkt im APF.

ChristianAchatz

2015-09-08 08:34

administrator   ~0000609

Hi,

bin noch nicht weiter gekommen. Melde mich mit mehr Details so bald als möglich!

ChristianAchatz

2015-09-15 10:30

administrator   ~0000611

Sorry, hab es immer noch nicht geschafft. Habs aber nicht vergessen. :)

General Crime

2015-09-15 12:52

developer   ~0000612

Sorry das ich mich erst jetzt melde hab aber wieder etwas mehr um die Ohren und kann mich derweil nur auf Fehlerfinden konzentrieren. Darum grad etwas mau.

Ich hab alle meine Themen in Beobachtung und werde demnächst auch noch was dazu machen.

ChristianAchatz

2015-09-16 20:21

administrator   ~0000613

Hallo GeneralCrime,

nun bin ich endlich dazu gekommen, mir das anzusehen. Deine Analyse war absolut korrekt, die Zuordnung zu einer Applikation wurde nicht geprüft. Ich habe das nun im Commit https://github.com/AdventurePHP/code/commit/2b2ef3a6d23a8969b0b2eb6e7d2f558b1f6d8c54 hinzugefügt. Einen Snapshot mit den Änderungen kannst du dir entweder unter http://files.adventure-php-framework.org/snapshot/apf-3.0.2-snapshot-php5.tar.gz oder https://github.com/AdventurePHP/code/archive/release-3.0.zip herunterladen.

Melde dich gerne mit weiteren Erkenntnissen, dann können wir das Thema weiter verfolgen.

ChristianAchatz

2015-10-11 12:25

administrator   ~0000618

Habe den Teil des Bug der erledigt war nun 3.0.2 zugewiesen. Solltest du noch weitere Erkenntnisse haben, lass uns das gerne in einem weiteren Bug beheben.

Issue History

Date Modified Username Field Change
2015-08-27 14:55 General Crime New Issue
2015-08-30 22:17 General Crime Tag Attached: database
2015-08-30 22:17 General Crime Tag Attached: gorm
2015-09-01 20:56 ChristianAchatz Note Added: 0000584
2015-09-01 20:56 ChristianAchatz Assigned To => ChristianAchatz
2015-09-01 20:56 ChristianAchatz Status new => feedback
2015-09-02 10:01 General Crime Note Added: 0000585
2015-09-02 10:01 General Crime Status feedback => assigned
2015-09-02 10:09 General Crime Note Edited: 0000585 View Revisions
2015-09-03 21:01 ChristianAchatz Note Added: 0000586
2015-09-03 21:54 General Crime Note Added: 0000587
2015-09-03 21:57 General Crime Note Edited: 0000587 View Revisions
2015-09-04 10:52 ChristianAchatz Note Added: 0000588
2015-09-08 08:34 ChristianAchatz Note Added: 0000609
2015-09-15 10:30 ChristianAchatz Note Added: 0000611
2015-09-15 12:52 General Crime Note Added: 0000612
2015-09-16 20:21 ChristianAchatz Note Added: 0000613
2015-10-11 12:24 ChristianAchatz Fixed in Version => 3.0.2
2015-10-11 12:24 ChristianAchatz Target Version => 3.1
2015-10-11 12:25 ChristianAchatz Note Added: 0000618
2015-10-11 12:25 ChristianAchatz Status assigned => resolved
2015-10-11 12:25 ChristianAchatz Resolution open => fixed
2015-10-11 12:26 ChristianAchatz Target Version 3.1 => 3.0.2