Du bist nicht angemeldet. Der Zugriff auf einige Boards wurde daher deaktiviert.

#1 16. Februar 2019 12:54

antibart
Server-Pate
Registriert: 14. Dezember 2010
Beiträge: 876

[CMSMS V2] [GELÖST] Front end users: Duplicate entry '0' for key 'PRIMARY'

Hallo,

seit dem Upgrade auf CMSMS 2.2.x wird beim Versuch, in FEU neue Gruppen/Benutzer anzulegen, immer die ID "0" vergeben, die zum einen ungültig ist, zum anderen natürlich das Anlegen weiterer Gruppen/Benutzer unmöglich macht:

Duplicate entry '0' for key 'PRIMARY'

Warum ist das so und wie kann ich es beheben?

debug sagt:

SELECT * FROM ssl_module_feusers_grouppropmap ORDER BY group_id,sort_key DESC

Debug: (0,118224) - (net usage: 7288760) - (peak: 7959656)

SELECT id FROM ssl_module_feusers_users WHERE username = 'username@domain.de' LIMIT  1

Was hat es mit dem LIMIT 1 auf sich? Heißt das, die ID ist auf 1 begrenzt und deswegen wird 0 vergeben?

Offline

#2 16. Februar 2019 13:13

nockenfell
Moderator
Ort: Lenzburg, Schweiz
Registriert: 09. November 2010
Beiträge: 2.927
Webseite

Re: [CMSMS V2] [GELÖST] Front end users: Duplicate entry '0' for key 'PRIMARY'

Kannst du mal schauen, was in den Tabellen

cms_module_feusers_users_seq
cms_module_feusers_groups_seq

steht? Das musst du im phpMyAdmin oder z.B. mit dem btAdminer Modul machen.

In diesen Tabellen wird der Primary-Key hinaufgezählt.


[dieser Beitrag wurde mit 100% recycled bits geschrieben]
Mein Blog  /   Diverse Links rund um CMS Made Simple
Module: btAdminer, ToolBox

Offline

#3 16. Februar 2019 13:50

antibart
Server-Pate
Registriert: 14. Dezember 2010
Beiträge: 876

Re: [CMSMS V2] [GELÖST] Front end users: Duplicate entry '0' for key 'PRIMARY'

Danke schonmal

nockenfell schrieb:

Kannst du mal schauen, was in den Tabellen

cms_module_feusers_users_seq
cms_module_feusers_groups_seq

steht? Das musst du im phpMyAdmin oder z.B. mit dem btAdminer Modul machen.

In diesen Tabellen wird der Primary-Key hinaufgezählt.

da war ich vorhin schon mal, aber das hat mir nicht so recht geholfen:

users_seq: 41
groups_seq: 46

Und das ist, wenn ich mich nicht irre, jeweils einen höher oder gleich der zuletzt angelegten noch gültigen ID (ich hatte zwischendurch die Misslungenen direkt aus der DB gelöscht, daher weiß ich es nicht 100%ig). Das müsste doch okay sein, oder? Oder sollte diese Ziffer immer identisch sein mit der jeweils höchsten ID unter groups und users?

EDIT: Seltsam ist auch, dass das User Passwort in der DB unter "salty" eingetragen ist, obwohl diese Anforderung in der FEU-Aministration dekativiert ist und das PW auch nicht gesalzen ist.

Kann es sein, dass der Versionssprung zu groß war?

Beitrag geändert von antibart (16. Februar 2019 14:11)

Offline

#4 16. Februar 2019 15:05

nockenfell
Moderator
Ort: Lenzburg, Schweiz
Registriert: 09. November 2010
Beiträge: 2.927
Webseite

Re: [CMSMS V2] [GELÖST] Front end users: Duplicate entry '0' for key 'PRIMARY'

Hm, eine wirkliche Idee habe ich im Moment nicht.
Grundsätzlich sollte das Update eines Modules so aufgebaut sein, dass alle Änderungen zwischen der Ursprungsversion und der aktuellen Version durchgeführt werden. Es ist dabei aber nicht auszuschliessen, dass dies nicht sauber programmiert oder getestet wurde.

Falls du kannst, wäre es schon eine Möglichkeit mit Zwischenversionen zu testen. Bei CG Modulen wie dem FEU könnte das aber schwierig sein, da dies jeweils nur eine kleine Spanne von CMSMS Versionen unterstützen.


[dieser Beitrag wurde mit 100% recycled bits geschrieben]
Mein Blog  /   Diverse Links rund um CMS Made Simple
Module: btAdminer, ToolBox

Offline

#5 16. Februar 2019 16:24

NaN
Moderator
Ort: Halle (Saale)
Registriert: 09. November 2010
Beiträge: 4.435

Re: [CMSMS V2] [GELÖST] Front end users: Duplicate entry '0' for key 'PRIMARY'

Was hat es mit dem LIMIT 1 auf sich? Heißt das, die ID ist auf 1 begrenzt und deswegen wird 0 vergeben?

Nein. Hat damit nichts zu tun. LIMIT bezieht sich auf SELECT. Genauer auf das Resultat von SELECT. Es bedeutet einfach nur, dass, egal wieviele Einträge bei SELECT gefunden werden, nur ein einziges Resultat zurückgegeben werden soll. D.h. sobald ein Eintrag gefunden wurde, hört er auf, weiterzusuchen. (Performance und so)

Von welcher Version hast Du das Upgrade gemacht?

FrontEndUsers verwendet keine seq-Tabellen mehr. (users_seq und groups_sec wären eh die falschen Tabellen - die sind für die backend-user) Stattdessen wird bei FEU mit AUTO-Increment gearbeitet. D.h. es dürften eigentlich never ever doppelte IDs existieren, weil die Datenbank bei neuen Einträgen den Wert für die IDs selbstständig hochzählt. D.h. der Fehler ist eher in der Datenbank zu finden. Vermutlich wurde beim Update das ID-Feld nicht erfolgreich in ein AUTO-Increment Feld geändert. Denn dazu wird mit ALTER TABLE gearbeitet. Diese Funktion ist aber aus Sicherheitsgründen bei vielen Hostern nicht vom CMS aus ausführbar. D.h. das muss direkt in der Datenbankadministration erfolgen. Ist nervig. Vor allem, weil FEU bei einem Fehler beim Update ohne einen Hinweis einfach stillschweigend weitermacht.

Schau also erstmal nach, ob AUTO_INCREMENT für das Feld ID in den Tabellen module_feusers_users, module_feusers_groups und module_feusers_properties angegeben ist. Also bei z.B. phpMyAdmin die Tabelle auswählen, dann oben im Menü auf "Struktur" - da wird dann nicht der Inhalt, sondern der Aufbau der Tabelle angezeigt. Und dort sollte für ID in der Spalte "Extra" AUTO_INCREMENT stehen. Wenn nicht, ändere die Felder von Hand. Einfach auf "bearbeiten" klicken und bei A_I einen Haken setzen.

Wenn die Felder auf AUTO_INCREMENT stehen, dann musst Du der Datenabank nur noch sagen, was denn der letzte Wert für die Spalte ID war. Dazu würde ich jeweils in den drei tabellen module_feusers_users, module_feusers_groups und module_feusers_properties schauen, welches die höchste verwendete ID war und dann bei phpMyAdmin unter dem Menüpunkt SQL folgendes eingeben:

ALTER TABLE [name der tabelle] AUTO_INCREMENT = [höchster wert der für ID verwendet wurde + 1]

Module: GBFilePicker, AdvancedContent
Sicherheit: Beispiel .htaccess-Datei
CMSms 1.12 unter PHP 7:
cmsms-1.12.3.zip (inoffiziell - komplett inkl. Installer)
CMSms 1.12 unter PHP 8:
cmsms-1.12.4.zip (inoffiziell - komplett inkl. Installer)

Offline

#6 17. Februar 2019 08:27

antibart
Server-Pate
Registriert: 14. Dezember 2010
Beiträge: 876

Re: [CMSMS V2] [GELÖST] Front end users: Duplicate entry '0' for key 'PRIMARY'

Vielen Dank für die ausführliche Antwort, NaN.

Manuell auf AUTO_IMCREMENT setzen konnte ich nur die Tabelle feusers_properties, bei den anderen stand die Tabelle feusers_belongs im Weg.

Query error:
#1833 - Cannot change column 'id': used in a foreign key constraint 'xxx_module_feusers_belongs_ibfk_1' of table 'dxxxxx.xxx_module_feusers_belongs'

Ich habe mich daher für eine andere Lösung entschieden. Da viele Nutzer ohnhin nur temporären Zugang benötigen und die Anzahl der Nutzer noch einigermaßen überschaubar war, habe ich auf das Upgrade verzichtet und einfach das Modul entfernt, neu installiert und den Seitenbetreiber genötigt, Gruppen und Nutzer neu anzulegen. Das geht wahrscheinlich schneller als die Umstrukturierung der Tabellen.

Allerdings habe ich nun einen Berechtigungsfehler 403 bei allen geschützten Bereichen. Ich kommt mir auch komisch vor, dass ich Gruppen in der Seitenverwaltung zwar markieren, die Auswahl aber nicht bestätigen kann. Klar kann ich einfach die Seite speichern - aber es gibt keine nachträgliche Kontrolle, ob und welche Auswahl getroffen wurde und ob die Freigabe funktioniert hat. Momentan fehlt die Berechtigung, egal ob ich eine Gruppe markiert habe oder nicht:

FEU BBCode-Test

Das Login selbst klappt aber. Gehe ich mit Browser back zurück auf die Anmeldeseite, kann ich meinen Anmeldestatus sehen.

EDIT: Sehe gerade im forge, dass es das Problem schon mal 2015 gab. Allerdings heißt es dort, dass es mit 2.1.1 repariert sein sollte.

Beitrag geändert von antibart (17. Februar 2019 09:46)

Offline

#7 19. Februar 2019 09:05

antibart
Server-Pate
Registriert: 14. Dezember 2010
Beiträge: 876

Re: [CMSMS V2] [GELÖST] Front end users: Duplicate entry '0' for key 'PRIMARY'

antibart schrieb:

Allerdings habe ich nun einen Berechtigungsfehler 403 bei allen geschützten Bereichen.

EDIT: Sehe gerade im forge, dass es das Problem schon mal 2015 gab. Allerdings heißt es dort, dass es mit 2.1.1 repariert sein sollte.

Und genau wie damals half bis dahin als Übergangslösung erstmal ein FEU-Downgrade.

Beitrag geändert von antibart (19. Februar 2019 09:06)

Offline