Sicherheitssystem Contenido 4.3.2.1b

[emergence]

tja hab mir nen schönen tag daraus gemacht mir das sicherheitssystem zu geben und bin aus einer paar kleinigkeit nicht schlau geworden.

die aufsplittung in con_area und con_actions ist ja ne nette geschichte, aber könnt ihr das ein klein wenig mehr dokumentieren ?? (ne einarbeitungsphase von 3-4 stunden |-( )

tabelle: con_actions
bei con_actions gibts ja die spalte "alt_name" kann mir einer sagen was die codes darin zu bedeuten haben ? manchmal sind sie da manchmal nicht. muster läßt sich da keins rauslesen (ich würd's rauskicken).

dann "location" -> erfüllt welche funktion? (wird nur einmal benutzt)

ach ja wenns "name" schon gibt wieso stehen dort teilweise auch ziffern drin ?? erhöht die lesbarkeit des quellcodes ungemein.
have_perm_area_action("con", "con_changetemplate") ist ja noch verständlich aber andere konstruktionen sind ein graus...

"idaction" hat das nen grund warum die durchnummerierung so seltsam ist, oder wird dieser teil auch zum aufrufen der funktion verwendet ??

"idarea" ist mir soweit klar aber wieso ist in con_area "idarea" der primärschlüssel ??

ne bereinigung der beiden tabellen wäre dringend notwendig. ne erweiterung des sicherheitssystems wäre dann ein leichtes, aber so is es ein krampf.

habe heute nur mal spass halber die fehler in upload ausgebessert, mit ner besseren doku der db tabellen wäre dies ja wirklich easy gewesen zu korrigieren.

ach ja bei den gruppen: da bis jetzt ja immer zwei datei löschen vorhanden waren, und ihr es lt. bugtracker korrigiert habt, habt ihr sicher nicht vergessen die berechtigung für rmdir (sprich Verzeichniss löschen) einzubauen oder ??

ne frage noch zum letzten punkt: wie funktioniert die sortierreihenfolge innerhalb der gruppen ?? ich hab dann den hut draufgeschmissen.

wie auch immer schönes wochenende...

[emergence]

fertig - die durchnummerierung und zuordnung waren an sich kein problem

aber der quellcode von contenido schluckt nur diese aufräum aktion nicht.
da anscheinen aufrufe direkt per idarea, idaction ausprogrammiert wurden.

echt toll

70% funktionieren normal
andere dinge wie die begrüssungsseite und untermenüs bei artikel gehen nicht.

wäre toll wenn diese aufrufe im quellcode von contenido mal korrigiert werden würden.

[timo]

tja hab mir nen schönen tag daraus gemacht mir das sicherheitssystem zu geben und bin aus einer paar kleinigkeit nicht schlau geworden.

Da hast du dasselbe Problem wie wir . Der Code basiert auf einer alten Version, und wohl niemand außer der Autor weiß, was genau da passiert.

tabelle: con_actions
bei con_actions gibts ja die spalte "alt_name" kann mir einer sagen was die codes darin zu bedeuten haben ? manchmal sind sie da manchmal nicht. muster läßt sich da keins rauslesen (ich würd's rauskicken).

Eigentlich ein Überbleibsel aus alten Zeiten. Früher wurden Aktionen nur mit Nummern identifiziert, während der Umstellung wurde es zwecks kompatibilität dringelassen.

dann "location" -> erfüllt welche funktion? (wird nur einmal benutzt)

Gute Frage Tut aber IMHO auch nicht weh, wenn's drinbleibt.


ach ja wenns "name" schon gibt wieso stehen dort teilweise auch ziffern drin ?? erhöht die lesbarkeit des quellcodes ungemein.
have_perm_area_action("con", "con_changetemplate") ist ja noch verständlich aber andere konstruktionen sind ein graus...

"idaction" hat das nen grund warum die durchnummerierung so seltsam ist, oder wird dieser teil auch zum aufrufen der funktion verwendet ??

idaction ist der Primary Key und wird durch die PHPLIB-Sequence aktualisiert. Wenn Lücken drin sind, dann liegt das daran, daß alte Aktionen entfernt wurden.

"idarea" ist mir soweit klar aber wieso ist in con_area "idarea" der primärschlüssel ??

Warum nicht?

ne bereinigung der beiden tabellen wäre dringend notwendig. ne erweiterung des sicherheitssystems wäre dann ein leichtes, aber so is es ein krampf.

Was genau möchtest du denn erweitern? Ich vermeide (auch bei weiterentwicklungen) weitestgehend modifikationen an dem Rechtesystem, weil es, wie du schon sagtest, ziemlich gruselig ist.

ne frage noch zum letzten punkt: wie funktioniert die sortierreihenfolge innerhalb der gruppen ?? ich hab dann den hut draufgeschmissen.

Welche "Sortierreihenfolge"?

[/quote]

[emergence]

Da hast du dasselbe Problem wie wir . Der Code basiert auf einer alten Version, und wohl niemand außer der Autor weiß, was genau da passiert.

das ist immer schlecht...

tabelle: con_actions | spalte "alt_name"
Eigentlich ein Überbleibsel aus alten Zeiten. Früher wurden Aktionen nur mit Nummern identifiziert, während der Umstellung wurde es zwecks kompatibilität dringelassen.

also fliegts irgendwann mal raus...

idaction ist der Primary Key und wird durch die PHPLIB-Sequence aktualisiert. Wenn Lücken drin sind, dann liegt das daran, daß alte Aktionen entfernt wurden.

interessant PHPLIB-Sequence übernimmt die aktualisierung, heisst das, dass die funktionen via PHPLIB funktionen aufgerufen werden ?

Was genau möchtest du denn erweitern? Ich vermeide (auch bei weiterentwicklungen) weitestgehend modifikationen an dem Rechtesystem, weil es, wie du schon sagtest, ziemlich gruselig ist.

ansich wäre es interessant in weiterer folge plugins ins sicherheitssystem mit einzubinden und weitere funktionalitäten(für bestimmte benutzer) zur verfügung zu stellen.

ne frage noch zum letzten punkt: wie funktioniert die sortierreihenfolge innerhalb der gruppen ?? ich hab dann den hut draufgeschmissen.

Welche "Sortierreihenfolge"?

okay, frage hat sich erübrigt...

[timo]

tabelle: con_actions | spalte "alt_name"
Eigentlich ein Überbleibsel aus alten Zeiten. Früher wurden Aktionen nur mit Nummern identifiziert, während der Umstellung wurde es zwecks kompatibilität dringelassen.

also fliegts irgendwann mal raus...

Ja, sehr warscheinlich. Ich würde aber erst mit der 4.6.x damit rechnen, da in der 4.5.x (Development-Tree für die 4.6.x, der demnächst eröffnet wird) noch viele Änderungen geplant sind.

idaction ist der Primary Key und wird durch die PHPLIB-Sequence aktualisiert. Wenn Lücken drin sind, dann liegt das daran, daß alte Aktionen entfernt wurden.

interessant PHPLIB-Sequence übernimmt die aktualisierung, heisst das, dass die funktionen via PHPLIB funktionen aufgerufen werden ?

So ähnlich - die Sequence wird über $db->next_id() geliefert und gleichzeitig aktualisiert. Das ist aber konsistent im ganzen System so gehandhabt.

Was genau möchtest du denn erweitern? Ich vermeide (auch bei weiterentwicklungen) weitestgehend modifikationen an dem Rechtesystem, weil es, wie du schon sagtest, ziemlich gruselig ist.

ansich wäre es interessant in weiterer folge plugins ins sicherheitssystem mit einzubinden und weitere funktionalitäten(für bestimmte benutzer) zur verfügung zu stellen.

Das haben wir damit gelöst, daß man an Benutzer frei definierbare entities hängen kann (siehe Tabelle con_user_prop und con_group_prop).

ich hab ja die beiden tabellen neu mittels eines scripts erstellt, (etwas sortiert) funktioniert nur nicht einwandfrei vielleicht wollt ihr es ja übernehmen..

Verstehe ich grade nicht so ganz - obwohl in beiden Tabellen (actions und areas) id's ausgelassen wurden, sehe ich das nicht als kritisch an - ich finde das "aufräumen" wesentlich schlimmer (im Bezug auf die kompatibilität mit alten Funktionen, die noch mit Nummern arbeiten).

[timo]

Achja, was ich noch vergaß:

Die Tabellen "con_user_prop" und "con_group_prop" sollte man über die dazugehörigen Klassen "User" und "Group" bearbeiten. Beispiel:

$user = new User;
$user->loadUserByUsername("example");

$user->setUserProperty("editing","wysiwyg-editor","spaw");
$user->setUserProperty("editing","use-wysiwyg","true");

In den nächsten Contenido-Versionen (also nach der 4.4) werden wir im Backend auch über diese "Properties" pro User und Gruppe Einstellungen erlauben (quasi eine mini-Registry), die bisher nicht möglich sind (z.b. könnte sich ein Benutzer selbst auswählen, welchen Editor er möchte oder ob er überhaupt den WYSIWYG angezeigt haben möchte).

Grüße,
Timo

[emergence]

alles klar soweit...

jetzt ist mir aber noch ne kleinigkeit aufgefallen in con_area
gibts zweimal als name news_send
einmal bei parent 0 somit als hauptkategorie
und einmal als parent news als subkategorie von news

ähm würd sagen das dies ein fehler ist.
oder ist dies beabsichtigt wenn ja warum ?

[timo]

Da hast du verdammt recht

Der letzte Eintrag mit ID Nummer 59 sieht falsch aus, bestätigen kann ich das leider im Moment nicht. Ich würde es aber drinlassen, da (sobald die Plugins funktionieren) der Newsletter als Plugin gebaut wird.

Grüße,
Timo

[emergence]

na toll, jetzt habe ich endlich die dateizuordnung kapiert... und warum meine aufräum aktion nicht funktioniert hat

in con_files sind die verweise nochmals mit con_area (idarea) verknüpft
in con_frame_files ebenso (idarea)
in con_nav_sub ebenso (idarea)

con_nav_main anscheinend nicht.

das heisst wenn ich die inserts erzeuge muß ich die tabellen con_files con_frame_files und con_nav_sub mit einbeziehen bei der erzeugung...

frage: hab ich was vergessen ?

warum news_send jetzt ne eigene id hat ist mir jetzt auch klar...

ich halte es aber dennoch für ne schlechte idee newsletter als plugin zu konzipieren. die änderungen in der db sind sicher auch nicht ohne...

[timo]

in con_files sind die verweise nochmals mit con_area (idarea) verknüpft
in con_frame_files ebenso (idarea)
in con_nav_sub ebenso (idarea)

con_nav_main anscheinend nicht.

Vollkommen korrekt .

das heisst wenn ich die inserts erzeuge muß ich die tabellen con_files con_frame_files und con_nav_sub mit einbeziehen bei der erzeugung...

frage: hab ich was vergessen ?

Soweit ich das deinem Beitrag entnehme, hast du keine vergessen.

ich halte es aber dennoch für ne schlechte idee newsletter als plugin zu konzipieren. die änderungen in der db sind sicher auch nicht ohne...

Wieso? Das einzige Problem ist, das Plugin auch wirklich zu installieren - und daran wird bereits gearbeitet. Bei einem unserer Kunden haben wir bereits über 10 Plugins laufen - und es läuft ohne Probleme (es gibt allerdings auch keinen Grund dafür, warum es nicht laufen sollte).

Grüße,
Timo

[emergence]

soweit so gut das script funktioniert jetzt an sich reibungslos...
einspielen in db klappt eigentlich auch ohne probleme...

was sich nicht mehr hintricksen läßt ist die reihenfolge bei der subnavigation aufrechtzuerhalten. net schlecht (sortierungsschlüssel wär eine möglichkeit)
anscheinend werden diese genauso angezeigt wie in der db eingetragen.

ebenso macht der eintrag news_send bei der bereiche anzeige probleme,
die reihenfolge ist jetzt bei mir zwar anders aber das stört nicht
scheint fast so als ob dort ebenfalls schon etwas gedreht wurde

wie auch immer wenn ihr das script mal zum aufräumen haben wollt sagt einfach nur bescheit.